NYCPHP Meetup

[Paul Reinheimer]

If a user has disabled cookies, and the session ID is being propegated
in the URL, this will break whenever the user uses the back button
then clicks on a new link. As links on previous pages will still
reference the old session id. The back button is an essential element
of the user experiance as it provides a safety mechanism for the user,
no matter what they do or click on, they can click back to 'fix it'.
Systems that negativly affect that process shouldn't be undertaken
lightly.

The primary methods for an attacker to obtain a session id would be
session fixation (sending a user to specially crafted url to set their
session id) and man in the middle attacks. Regenerating their session
id once (rather than repeatedly) would be enough to foil  a fixation
attack, but not man in the middle attacks. This constant regeneration
process might have some advantages in a man in the middle attack as
once the attacker started using the session it would be reset, and the
valid user would be asked to log in again, hopefully this process
would destroy any previous sessions associated with the account.
Though personally, I don't think this increase is worth the trade off
of breaking the back button for non-cookie users & increased server
load from constant regeneration & file access.

Also, my understanding of session_regenerate_id() is that it moves the
session from the previous ID to a newly generated one, the old ID
should be invalid at that point.

I'm a big supporter of regenerating the session id everytime the
visitor changes access levels. When they log in, regenerate the id.
When they log out, regenerate the id, etc.


Be carefull with doing IP matching as users behind proxies may change
IPs at seemingly random intervals. :)


paul




On Wed, 22 Dec 2004 08:36:38 -0600, Eric Rank <flakie at gmail.com> wrote:
> After thinking hard about what's involved with session hijacking, one
> thing seemed to be the lynchpin in attacks, the session id. If an
> attacker knows the session id, he can hijack the victim's session.
> 
> So my thought was to change the session id with every request. This
> way, the session is only good for a very short time. It also does a
> very adequate job of protecting against session fixation attacks
> (http://www.acros.si/papers/session_fixation.pdf) because once the
> attackers session is used to gain permissions, it becomes an invalid
> id.
> 
> The php function session_regenerate_id() looked promissing. However,
> it falls a bit short by not deleting the old session id once the new
> session id is generated. So I whipped together a procedure to make it
> work.
> 
> The things that it relies on are 1. the id being hard to catch, and 2.
> the attacker doesn't beat the legit user to the punch. For example,
> let's say an attacker was sniffing the network and sees a session id
> go by. if he goes to a page specifying the stolen session id as his
> own, the legit user will lose all her data in the session because the
> id she specifies on her next page is no longer valid. However, if
> you've got someone sniffing the network, there are probably bigger
> problems to be concerned about.
> 
> To me, the following approach does a fairly adequate job of protecting
> against session hijack attempts. You can use this in addition to other
> validation tests (using cookies with unique id's, using user-agent &
> ip comparisons, etc). I've done some preliminary testing and it seems
> to work ok. I'd love to hear some feedback.
> 
> It goes something like this:
> 
> <?php
> session_start();
> $temp = $_SESSION;  //make a copy of the session
> session_unset(); //clear the session data. probably an unnecessary line
> if (isset($_COOKIE[session_name()])) {   //kill the cookie on the client
>       @setcookie(session_name(), '', time()-42000, '/');
> }
> 
>  //use this instead of session destroy to kill the session file on the server
> unlink(session_save_path().'/'.'sess_'.session_id());
> 
> session_regenerate_id();  //generate a new session id. this sets a new
> cookie on client as well
> $_SESSION = $temp;  //put the temp info back on the session superglobal
> 
> //The rest of your code that uses sessions below...
> ?>
> 
> 
> Eric Rank
> _______________________________________________
> New York PHP Talk
> Supporting AMP Technology (Apache/MySQL/PHP)
> http://lists.nyphp.org/mailman/listinfo/talk
> http://www.newyorkphp.org
> 


-- 
Paul Reinheimer
Zend Certified Engineer