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
Why? Making use of one parameter is orders of magnitude easier than
refactoring your whole application to not use serialize() (especially if
you need object support).
exactly replicating the structure. Using the latter format for the
former task is in any case a bad idea. It's not like unserializing
You completely ignore situations where two could mix - i.e. where you
could store data that can potentially be not reproducible by JSON and
still may - due to some or other oversight - be controlled by the user.
That's why security has layers - so that if you make mistake on one
layer, other layer would limit the exposure. That's why you don't run
you webserver as root - even though you could just say "we shouldn't
have remote execution holes, so it doesn't matter under which user the
webserver runs". You seem to be under impression that if particular
technique solves particular problem, there shouldn't be any security
measures protecting you if you do not use that technique. I think it is
plain wrong approach to security.
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 :)
I don't see how this has anything to do with anything. There are tons of
different bugs, and I never claimed this patch protects against all of
them, so if you think somehow finding a scenario that this change does
not protect from invalidates it, then by the same logic we should never
have any security features at all that do not make the application
perfectly secure in the hands of most ignorant user.
The point is not to make perfect protection, the point is to make common
scenario safer and more resistant to common attacks that happen to
existing applications all the time now.