[<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 ]
Powered by blists - more mailing lists