HTTP state management without cookies?

Fri Feb 22 07:32:57 EST 2002

Michael Ströder <michael at stroeder.com> writes:
> 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.

Any particular cgi vars you recommend?  You can't count on the SSL
session ID staying constant.  Some browsers seem to like re-opening
the SSL connection every now and then.  And the idea of making people
enroll client certificates in order to spare them the indignity of
accepting browser cookies sounds like something from another planet
(no offense intended).

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

Interesting!  You're saying if I have a page called abc.html,
containing an html meta redirection tag to xyz.html in the head
section, then the browser will immediately navigate to xyz.html before
trying to get any inline images, and also, even after the redirection,
abc.html will show up as the referer on any new links or images?  And
that's true in general, not an implementation kink of some particular
browser?  I didn't know that--thanks!

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

I'll take a look at it!  

Paul