NYCPHP Meetup

[Eric Rank]

Howdy Corey,

Using some kind of unique key is a good idea. It makes a lot of sense
to combine some sort of unique identifier generated by the client.

There are of course problems with using the ip for people behind
proxies, among other issues getting the unique goods to generate some
sort of key. But regardless, getting some sort of semi-unique value
shouldn't be too hard. However, unless I'm missing something (I feel
like I am), it seems to me that there's a slight shortcoming in using
a session id with a mixed in key.

As you mention, the key+session id value does have to transfer from
client to server, so anyone watching could see that crazy string, copy
it and send some headers to the server matching that. The server then
de-crypts the crazy string, and accepts it as valid. Using a timestamp
in the key is a good idea though. That would certainly help make
things unique.

Self signed certificate ? I completely agree that where real security
is necessary, SSL is a necessity. In some cases, ssl isn't available
(for people running on cheap hosting packages). That's why I'm beating
this horse. Is it dead yet? :-)

Thanks,

Eric




On Wed, 22 Dec 2004 13:19:41 -0500, corey szopinski
<corey at domanistudios.com> wrote:
>  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