NYCPHP Meetup

[Paul Reinheimer]

This sounds neat, but how does my client generate the ID? Javascript?
On each request?

Also, my computer doesn't know what its external IP is, I sit behind a
connection sharing router, it thinks it is 192.168.1.85, while the
server will think it is 64.52.118.25 (or whatever).  Users behind
connection proxies or other similar corporate constructs will run into
similar problems. The seconds since last request thing is also going
to be a bit wonky as a result of pings & lag.


Some type of specially crafted but shifting key might work well for
applications communicating with each other directly, but I don't know
how well it would work for a user browsing a site.



paul




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 
>  
>  
> _______________________________________________
> 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