Closed MatthiasKuehneEllerhold closed 6 years ago
to combat code-injection.
I fully agree with this, but changing the interface would make this serializer unusable with most applications, as subclassing and customising components is (sadly) very common.
How about we add a setter (and a getter) and use the current (unsafe) whitelist as default? Example:
$serializer = new PhpSerialize();
// disallow all classes:
$serialize->setUnserializeWhitelist(null);
// OR: only allow the Zend-I18n-Textdomain:
$serialize->setUnserializeWhitelist([\Zend\I18n\Translator\TextDomain::class]);
$serialize->unserialize(...)
Instead of a setter, a ctor argument.
should be close-able in favor of merged #37
Yes. PR #37 was merged! Thanks!
The
PhpSerialize
adapter usesunserialize()
(see PhpSerialize.php#L88) to convert a string into a PHP Object (array, string, class-instance. ...).PHP 7.0 added an option to only allow the deserialization of whitelisted classes via the "options['allowed_classes']" parameter to combat code-injection.
I'm proposing adding an options to
PhpSerialize
class to uses this whitelist.Practical application: this could be used in "zend-i18n" (using "zend-cache" and "zend-serializer") for the translation-cache. It should only allow the deserialization of objects that are instance of
Zend\I18n\Translator\TextDomain
(or plain arrays).