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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: tim-security at (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.


Powered by blists - more mailing lists