Stefan Esser wrote:
beeing able to detect if a session was already started has nothing todo with session fixation attacks.
It does have *something* to do with session fixation attacks. In that
if you are given a session ID that doesn't exist it's most likely an expired session ID (make a new one) or a possible fixation attack (make a new one).
Session fixation means that you supply the user with a session id you know about. It doesn't make any difference if this session id was obtained by visiting the target site once, or by simply putting in a random one (that is then accepted by PHP).
That's a very good point! It's often overlooked that a fixation attack may use a *valid* session ID, instead of just generating a random one.
I would prefer to make the attacker grab a valid session ID from me rather than simply allowing them to generate their own random one. It would simply mean the attacker would need a slightly more complex script to automate attacks. As well as applying a possible time frame the attack is valid for. Which isn't a bad thing IMO.
(And any argument that one obtained by visiting the site would be bound to the attackers creds is invalid, because the same technique would catch new invalid sessions (because of no assigned creds))
And the behaviour of PHP is not flawed. For several systems it is vital, that the outside is able to set the session id. There is no reason to change that behaviour, because it doesn't stop any attack.
I agree, PHP is certainly not flawed. Some of our production servers
depend on being able to set the session ID externally. I wouldn't propose changing PHP's behavior to not accept a remote session ID. But I would propose (if possible) providing the user a tool that they could implement it if they so desire(i.e., session_id_exists()).
--
D a n i e l J C a i n J r .
Zend Certified Engineer
http://zend.com/zce.php?c=ZEND001685&r=210869656-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
