Re: defense against session hijacking

[flatline <flatline () blackhat nl>]

hi,

there has been some discussion on this topic already, mainly on the 
webappsec list.
i would like to refer you to the 'defense against session id replay 
attacks' thread on webappsec (march 2002), which ended up in people 
suggesting the use of a 'next request token' which is issued by the server 
on every client request made.

the basic idea is that the client echoes back the token generated by the 
server on the next request it makes, so the server can compare the value 
echoed back by the client to the value stored on the server side. this way, 
if a session id was hijacked, an attacker also has to know the token to 
make a successful follow-up request. obviously, if a client (attacker) 
can't echo back the token, something's amiss.

/ flatline

At 02:18 PM 18-11-2003, you wrote:

[ snip ]

> If you record the last page the user was on (with a specific session-id)
> and then check the referrer server variable on their next hit.  Compare
> the referrer to their last known page.  Most of the time (depending on the
> complexity of your site) the referrer and last known page should match.
> If their session is 'hijacked', odds are the 'hijacker' will not be
> following in a valid user's footsteps, more likely they will just be
> coming at the server with rogue data.  The referrer check won't match and
> thus the validity of the session request is also void.

[ snip ] 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html