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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

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

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

From: tim-security at sentinelchicken.org (Tim)
Subject: defense against session hijacking

> 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.

1. The referrer header is an optional header in HTTP.  Most current
   browsers send it, but some allow you to turn it off entirely for
   privacy reasons.

2. The referrer header is trivial to spoof, since it comes from the
   client, and HTTP is more or less a stateless protocol between requests.

Conclusion:  Your suggestion is in no way more secure, and it requires
users to turn on the referrer header, which they may not feel
comfortable doing, generally.

As for a constructive suggestion:  Fix your cross site scripting holes.
Doing so is the best way to avoid session hijacking.  Design your apps
from the ground up to be secure.  Quote anything remotely resembling
HTML that comes from an untrusted source and is displayed on your
dynamic pages.

cheers,
tim