HTTP state management without cookies?

Fri Feb 22 08:36:53 EST 2002

Paul Rubin wrote:
> 
> 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.

> Any particular cgi vars you recommend?

See the list in
http://www.stroeder.com/pylib/PyWebLib/pydoc/pyweblib.session.html

You can configure the env vars you want to include in cross-checking
by setting parameter crossCheckVars of WebSession.__init__(). The
vars actually cross-checked are determined when
WebSession.newSession() is called and might be a subset of the
crossCheckVars.

My standard disclaimer regarding PyWebLib:
I don't promote PyWebLib to be used by others. It's just published
for informational purpose. If you decide to use it be warned that
documentation will stay very sparse and the API might be still
subject to incompatible changes without prior announcement and
discussion.

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

Yes, it depends on the server *and* the browser whether SSL session
renegotiation is properly done or not. My experiences with Apache
and mod_ssl and various mainstream browsers are fairly good. I
stated that you can't always rely on this - somewhat implicit
though.

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

I mentioned client certificates for describing the high-end of
security mechanism available.

> (no offense intended).

No offense taken.

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

IMHO it does not work with redirecting <img> links as already stated
in my prior posting. I think the image won't get loaded at all. Feel
free to test that.

> And
> that's true in general, not an implementation kink of some particular
> browser?  I didn't know that--thanks!

I tested it with some mainstream browsers. Feel free to contribute
more test results.

Ciao, Michael.