In bobomail (bobomail.sf.net), the author solved this by sending all external links through a redirector, i.e., a link http://destinationhost.com/wherever would be changed to http://thishost.com/redirect/destinationhost.com/wherever I think this provides a sufficient solution -- though once again, for non-cookie sessions you must munge all HTML output. > Interesting message from the Python newsgroup about a potential security > hole when using session IDs encoded into the URL. �This is exactly what > the > Application.config setting "UseAutomaticPathSessions" does. > - Geoff > Mailer: Internet Mail Service (5.5.2653.19) > Date: Thu, 21 Feb 2002 18:51:41 -0500 > From: "Paul Rubin" <[EMAIL PROTECTED]> [Add to address book] > To: [EMAIL PROTECTED] > Subject: Re: HTTP state management without cookies? > Geoffrey Talvola <[EMAIL PROTECTED]> 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_=678268432/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_=678268432/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. > -- > http://mail.python.org/mailman/listinfo/python-list >
_______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
