On Sun, Mar 31, 2013 at 5:27 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> > I think Stas proposes a solution to the problem and I think Anthony > > proposes a viable alternative. I would say that Anthony has found the > > shortest distance between the two points (the problem and the solution), > > however. > > The fact is that people do use serialize() for data that may be > accessible by the user Yeah, well, the people who do that are also the ones that are unlikely to make use of the new parameters to secure themselves. In order to make them use of the new feature they have to be explicitly educated about it and in that case we can just as well educate them to use json_encode. In that regard, I don't think this proposal is particularly useful. JSON and serialize() are (inherently) different serialization formats with different use-cases. The former is rather restricted and as such safe to be provided by the user. The latter on the other hand aims at exactly replicating the structure. Using the latter format for the former task is in any case a bad idea. It's not like unserializing objects with dtors is the only issue that can turn up. serialize() also supports references and object-references, so one could probably use it quite easily to trigger some kind of infinite loop/recursion in the application. So, I personally don't see much value in this addition. Rather it could provide people an excuse to use the function on user-provided data, which is, as already mentioned, a bad idea. Even with this additional protection. Also I'd like to point out that unserialize() in the past had a relatively large number of different security vulnerabilities, so one should really, really not trust it with data of unknown origin. Internal classes can quite commonly be made to segfault with specially crafted serialization input. E.g. the user might think that, hey, DateTime is a safe class, let's allow unserializing that. Sounds legit doesn't it? Then let's remember those various serialization bugs that were recently fixed in DateTime (or the related classes, didn't really look at it). And then we would have a potentially exploitable segmentation fault :) Nikita
