On Mon, Nov 3, 2014 at 10:10 PM, Stas Malyshev <smalys...@sugarcrm.com>
wrote:

> Hi!
>
> I'd like to put to vote my proposal about the filtered unserialize():
>
> https://wiki.php.net/rfc/secure_unserialize
>
> It was discussed a number of times before and I think it is time to have
> a decision on it. If you need any clarifications on the proposal, please
> do not hesitate to ask.


I'm -1 on this RFC, because I think this only further encourages
ill-advised usages of unserialize() on user-provided strings. I don't think
adding an allowed classes lists makes unserialize() safe, because it also
supports some other weird things. For example, our serialization format
allows you to create references. I'd imagine that you can easily use this
to cause a DOS condition if the code processing the unserialize output uses
any kind of recursion.

Furthermore I dislike some details of the particular implementation: The
ability to use false as a synonym for [] seems unnecessary. Directly using
an extra argument will be inconvenient for future additions, e.g. if you
really wanted to more this secure, you'd probably also want to have options
to disable references and to limit the cumulative number of array elements
(hashdos). I'd prefer using an options array for this.

Nikita

Reply via email to