full-disclosure - defense against session hijacking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: flatline at blackhat.nl (flatline)
Subject: defense against session hijacking

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 ]