Here's how the new functionality might be applied after discovering a session hijacking attempt. My code uses a DB for storage so I have a user land $this->id_exists($id) in place already.
if(session_is_started()) { // Instead of using isset($_SESSION)
session_regenerate_id($this->newID); // Added ability to set SID
unset($_SESSION);
} else {
session_id($this->newID); // Existing ability to set SID
session_start();
}For helping prevent session fixation a built in session_id_exists($SID) would be useful as well. That way, if the end user is so inclined they can prevent session fixation. Those changes would be a little more in depth than the simpler ones I've put up so far. Someone more experienced with writing extensions may want to tackle that one if they think it would be useful as well. Otherwise I may get adventurous and tackle it as an exercise to learn more extension writing/modifying in the future.
I'm not trying to present a silver bullet solution, just hoping to provide enhanced functionality for those who seek it.
:)
-dan
Peter Brodersen wrote:
But as long as stuff like print_r(glob("{.,/tmp}/*",GLOB_BRACE)); .. are possible even in safe_mode/open_basedir-restrictions, these new functions will have pretty small effect unless one works his way entirely around the session functionality in the first place...
E.g.: http://basedir.ter.dk/globall.php
-- 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
