NYCPHP Meetup

[corey szopinski]

Hey Eric-

One idea to throw in with this: the idea of using a session id along with a
key. The key is generated by an algorithm on the client and the server, and
³merged² into the session id. I¹m thinking of something like the md5sum of
the useragent+ip address+seconds since last request. All three values are
known entities to both the client and the server, so you can do the md5sum
on both sides without passing the actual value. Instead, you can merge the
php session id with this md5sum in a way that you can subtract the key to
get the session id. I¹m not sure what merging technique to suggest that¹s
reversible, but the general idea is to vary the id passed to the server in a
known and predictable way, without it looking predictable (the md5 will look
random). At the end of all of this you get the original session id issued by
the server, without passing that id in the clear.

It¹s essentially a poor-man¹s SSL. Since the handshake sequence happens on
every request. You won¹t be encrypting anything, but you could be 95% sure
that no one is getting in the middle. For extra security, throw in a random
seed generated by the server on the first request and use that in your md5.

Although I have to ask: why not just set up a self-signed certificate for
this?

-c


On 12/22/04 9:36 AM, "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...
> ?>
> 




Corey Szopinski
Director of Technology

DOMANI STUDIOS
corey at domanistudios.com
55 Washington St. Suite 822
Brooklyn, NY 11201
718-797-4470  x116 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20041222/56e5668d/attachment.html>