>> 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.
.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
