Re: [RFC] more secure unserialize()

>> And what about automatic un/serialize() of objects in $_SESSION? >> People don't even see those function calls in their code, so dropping >> the function/ality would be a wildly drastic move. > Nothing about it, the change is for unserialize() function. OK. I thought of this as one core security issue with multiple possible ways of getting a payload to the internal (C) unserialize code. (If not, guess I could draw up an RFC for the other vector.) It is harder to inject arbitrary objects into session storage than to exploit blind-request-variable-unserialization type stuff (though the latter can be a stepping stone to the former). But the potential payoff in $_SESSION is so huge, I think having "secure unserialize" for sessions is fully justified. Otherwise you're saying "I can't guarantee objects with killer wakeups/dtors were not injected via one of the apps on my server, and I have no way to stop them from instantiating magically provided they get through the right way." > We have to get away from mentality of "if we need to modify some > behavior, we just put a variable in global state to control it". > Global state is the last resort, not the first one. I guess it could be another argument to session_start() instead. -- S. P.S. Sure you'll shoot down this idea as well, but I think it would be good if Filters had a corresponding validator, such as: FILTER_VALIDATE_UNSERIALIZED: detect strings in PHP bytestream format. Flags FILTER_ALLOW_SERIALIZED_SCALAR, FILTER_ALLOW_SERIALIZED_NONOBJECT to fine-tune. Otherwise, if you are still expecting bytestream format from the client and want to detect tampering on input, you have to write a best-guess regex to try to differentiate between 'Some:free { text; }"' and 'O:8:"class":0:{}' and 'S:12...' etc. .