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
