HTTP state management without cookies?

Fri Feb 22 06:48:23 EST 2002

Paul Rubin wrote:
> 
> Btw, I better point out a not-so-obvious security peril with this
> scheme and any others like it that put the session ID into the URL.
> [..]
> attacker.com server containing an HTTP REFERER header which has
> your page's URL including the session ID.  The attacker can then

One can't repeat this often enough and bang this into the heads of
web application programmers!

Especially web mail applications, web forum software or any other
applications which display untrusted HTML input are probably
vulnerable to this.

There are two things you can do against it:

1. Detect session hijacking by cross-checking CGI-BIN vars you can
assume to be constant throughout the whole session for *each* hit.
If you want to be more secure use SSL on a server properly handling
SSL session renegotiation and exposing the SSL session ID in the
CGI-BIN env vars (e.g. Apache with mod_ssl -> env var
SSL_SESSION_ID). If you want to be really secure or you can't rely
on proper SSL session renegotiation deploy client certificates and
use the subject DN and issuer DN exposed in the env vars.

2. Have a URL redirector in place *within* your application which
outputs HTML with redirect URL in <head> section. In this case the
browser sends the redirector's URL as referer URL. It's not
sufficient to redirect by HTTP status codes 301 or 302 and Location:
header! Off course it's much work to keep track of all links you're
displaying and it's not feasible for inline-displaying of images via
<img> tag.

You're invited to play with the on-line demo of web2ldap at
http://sites.inka.de:8002/web2ldap which implements these kind of
things and places the session ID in PATH_INFO (because personally I
do not like cookies although I see some of their advantages, e.g.
single cross-site sign-on).

Feedback welcome.

Ciao, Michael.