Re: Hijacking URL Encoded Session IDs using Referer Logs

You may be able to resolve the problem whilst only using URL-based tokens as follows:

Include two tokens in the URL - one that is continuous across the session (to maintain state), and another that changes with each new page (only accepted once by the server). Links within each page contain the "next" page token, which will appear within the browser location after the link has been clicked. When the user browses elsewhere, their Referer: header will contain an "old" token which the server will no longer accept.

UDP 53

-----Original Message-----
From: Bob Lee [mailto:crazybob@crazybob.org] Sent: 25 November 2002 15:41
To: Jeff Dafoe
Cc: webappsec@securityfocus.com
Subject: Re: Hijacking URL Encoded Session IDs using Referer Logs

One, I could have missed it, but I don't see anything in the owasp security guide advising application developers to disable URL encoded session IDs.
Two, you can't tie the origin of the the request (the IP address) to the session for reasons that have been discussed here time and time again. Three, expiring sessions in a "timely" manner accomplishes nothing. 0 seconds is the only safe timeout. A cracker could write a program that monitors the HTTP referrer headers and e-mails her (hell, pages her) as soon as it sees something that looks like a session ID. Four, most people worry about XSS attacks. Many sites (and web mail clients) allow links, and they also support URL-based session IDs. The *only* reason I bring this up is that I've seen examples of issue in my referer logs.
Bob
Jeff Dafoe wrote:
>>Many (most?) application servers use URL encoded session IDs when the
"poor
> session handling" advisories and such.
Received on Thu Dec 5 10:35:33 2002