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