I think this RFC would worsen the problem of misusing the serialize round-trip.
Even if we make the docs clearer, we'd still be sending the message that there's a new
"safer" unserialize and some would certainly use that new feature to be more lax about
guarding serialized structures.
It also sets up a situation where altering either the whitelist or one of the classes in
the whitelist could open a vulnerability that's not obvious.
I'm also not convinced that this feature would spur developers to fix insecure
code.
But setting my arguments against, if the goal is to make unserialize() secure, then it
should behave like a tripwire: fail loudly if a non-whitelisted class object is found. I
think returning partially-usable values would gives devs more rope to hang themselves with.
Re the 2nd arg, I'd make only two cases:
* null is given: default behavior
* non-null given: cast to array and that's the class whitelist.
If the overall goal is to make the serialize/unserialize round-trip tamper-proof, we could
build HMAC right into the API: add secret key args to both functions. No doubt the Suoshin
patch already uses HMAC during encryption of the session data.
Steve Clay
--
http://www.mrclay.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
