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 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <6.0.1.1.2.20031119210615.031245e8@mail.werkopmaat.nl> 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