Re: Hijacking URL Encoded Session IDs using Referer Logs

["UDP 53" <udp53 () hotmail com>]

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