Re: Hijacking URL Encoded Session IDs using Referer Logs

[Bob Lee <crazybob () crazybob org>]

Or..... rather than linking directly to another site, allowing the 
browser to pass the user's session ID in the referer header, you could 
use an intermediate redirector for which a session ID is not needed.

Bob

Jeff Dafoe wrote:
> > 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.
>
>
>     If you are seeing session IDs in your referer logs then presumably the
> users who established those sessions did not get a cookie-based session for
> some reason.  How will those users be serviced if the "fallback" method by
> which their session was maintained is disabled?
>
>
> > 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.
>
>
>     You can make a best-effort attempt based on reverse resolution and
> originating domain.  Feeble, agreed.
>
>
> > 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.
>
>
>     The "safe" timeout value, like the previous item, really depends on the
> type of application you are refering to and the level of security required
> by that application.  You really cannot say that generically, session IDs
> present in the URL represent a security problem, because this assumes that a
> system using session IDs in the URL to maintain state has any information
> worth securing.  I would hate to see web app frameworks suddenly,
> uncategorically, remove support for url-based sessions, particularly when
> the removal of such will clearly affect the ability of some users to access
> web applications utilizing those frameworks.
>
>
> Jeff