[wp-trac] [WordPress Trac] #37757: Add `allowed_classes` to `maybe_unserialize` When WordPress is running on PHP 7+

WordPress Trac noreply at wordpress.org
Tue Sep 12 01:19:20 UTC 2017


#37757: Add `allowed_classes` to `maybe_unserialize` When WordPress is running on
PHP 7+
--------------------------------------+------------------------------
 Reporter:  chrisguitarguy            |       Owner:
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Security                  |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by iandunn):

 > This would allow an arbitrary plugin or theme to basically 'reset' the
 allowed classes to accept all classes.

 I'm not really tracking with that line of thinking. A plugin could also
 also `add_filter( 'has_cap', '__return_true' )` or `add_filter(
 'authenticate', function() { return get_user_by( 'id', 1 ); } )`, but that
 doesn't mean we shouldn't have those filters. Is there something about
 this particular case that makes it more likely to be misused than those?

 I don't think of installed plugins and themes as being arbitrary, since
 they were intentionally chosen and installed, and by their nature have
 root access to WP and the database. A site owner has the responsibility to
 only install plugins that they trust with that access. The owner could
 also `add_filter( 'unserialization_options',
 'whitelist_unserialize_classes', 100000000 )`, if they wanted to override
 unwanted behavior from a plugin.

 There are 16 calls to `maybe_unserialize()` across the codebase, so, if I
 understand it correctly, an approach like
 `unserialization_options_{$option}` would require a different variation of
 the filter to be added and maintained for each of them, as opposed to just
 a single filter inside `maybe_unserialize()` itself. Is that right? So far
 I'm not personally seeing a benefit to the approach that would outweigh
 that added complexity.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37757#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list