I think that these functions could be helpful. Is there any reason we
shouldn't have this kind of functionality?
What do others think of these changes?
-Tom
On 4/22/05, Daniel J Cain Jr. <[EMAIL PROTECTED]> wrote:
>
> These changes in and of themselves will offer zero increased protection
> against session fixation/hijacking. But they do prove useful when used
> together for building a custom session handler trying to prevent session
> fixation/hijacking.
>
> 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
>
>
--
Tom O'Neill
[EMAIL PROTECTED]
