> 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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
