Re: Hijacking URL Encoded Session IDs using Referer Logs

[Bob Lee <crazybob () crazybob org>]

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
> > user has disabled cookies. Many users disable cookies as a security
> > precaution. There should be an advisory on this so that application
> > server vendors stop allowing URL encoded session IDs by default.
>
>
>     If the sessions in a particular app are that easy to hijack then the
> security issue is with that and not necessarily with the method used to
> transmit the session id.  That is why the origin of a request must be
> validated when a request is issued against a particular session and it is
> also why sessions must be expired in a timely fashion.  I think we are
> treading old territory here, stuff that was previously covered in past "poor
> session handling" advisories and such.
>
>
> Jeff