Chris Shiflett wrote:
It would raise the bar, but that's about it.
But isn't that what increasing application security is all about? Wouldn't that be an example(albeit an arguably small one) of defense in depth?
An attacker visits your site (to initiate the session), determines the assigned session identifier, and then uses that session identifier (which now references an initiated session) for the session fixation attack.
But if you forced the attacker to come to the site to obtain a valid session ID before sending it to the victim. You would now have a time frame that the ID is good for. As opposed to being able to set any arbitrary session ID to begin with, simply by passing it to PHP.
I'm not saying this will *stop* attacks all together, but it would require a more technically competent attacker than is currently required for some known exploits.
I'm only hoping to enhance the tools available, so that more complex
session handling is available to those who choose to do so. Not to change PHP to do this on the users behalf.
--
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
