[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