Re: [PEN-TEST] HTTP Secure Session State Management

[Mark Curphey <mark () CURPHEY COM>]

The thread started as a discussion on state management once authentication
had taken place; i.e. maintaining that authenticated state securely without
asking a user to re-authenticate each time he requested a page.

-----Original Message-----
From: Penetration Testers [mailto:PEN-TEST () SECURITYFOCUS COM]On Behalf
Of Bill Reamy
Sent: Sunday, December 24, 2000 10:15 AM
To: PEN-TEST () SECURITYFOCUS COM
Subject: Re: [PEN-TEST] HTTP Secure Session State Management


> > > Apart from RFC 2965 (cookies) what other methods are available to
> > > developers to manage sessions securely; i.e. authenticate each session
> > > in a transaction ?
> > >
> > > Is a decorated URL  a better option ?
... snip ...
> Decorated URLs, containing session ID's, are almost always worse.
... snip ...
> If you go to a different (off-site)
> page, from a page containing 'decorated urls', the URL you came from
> (referrer) can get logged.
... snip ...
> This problem is still visible in a lot of web-based systems today.
> (urls with session IDs are a potential security leak for me - so it's not
> that offtopic :) )
... snip ...

  The latest version of iMail, from Ipswitch solves this problem
 (somewhat) by associating identity with both a session id in the url,
 _and_ the user's IP address. Both must match before the next page
 loads.

  This won't help if the attacker and victim are both on the same NAT
 device (they'd have the same IP). It won't help if the victim is using
 a web proxy. And it does not allow AOL users to use the webmail system
 because they rotate through multiple web proxies with different IP
 addresses (AFAIK).

  If you are designing a web system that requires authentication, why
 not use HTTP Authentication? It's not perfect, but at least the browser
 was designed to not give this info up easily.