Re: post to bugtraq about "session fixation"

["Kevin Spett" <kspett () spidynamics com>]

If the session management implementations of web application servers (JRun
and PHP are mentioned) allow users to specify session IDs, I would consider
it a legitimate problem.  Lots of people rely on the vendor-supplied APIs
for session management.  If they had framed it more as a potential weakness
in web app design more than a revolutionary new attack technique it would've
been better.  I agree that the severity and practicality of the attacks
described in the paper have been exaggerated, but saying it's marketting and
nothing more is a little harsh.  Sure, they took liberties saying that it's
a widespread new type of attack, but if they were going for pure marketting,
they'd end up with something like this:
http://www.forescout.com/e-tourinteractive10.html  Calling honest research
efforts marketting BS and nothing more has the potential to hurt people's
feelings, which is forbidden under OWASP charter regulations title VI,
section 3, paragraph 4.


Kevin Spett
SPI Labs
http://www.spidynamics.com/

----- Original Message -----
From: <securityarchitect () hush com>
To: <webappsec () securityfocus com>; <alex () netWindows org>
Sent: Wednesday, December 18, 2002 2:28 PM
Subject: Re: post to bugtraq about "session fixation"


> With respect I think its a great marketing paper but nothing more. You
should never allow the same token to be used over HTTP that is then valid
over SSL. At least one variant of this attack relies on that assumption.
> Correct way if for the user to enter username and password over SSL and
session cookie is set to that browser session over SSL. A pre-fixed cookie
would get you to the public site (which maybe customized for a user
experience but not show logged in details) but shouldn't get you to anywhere
other than a login screen.
> This paper also assumes that application session management is closely
tied to web server session management. IMHO its not and this is a good
reason why not. People think it is cause IIS and others still sends
ASPSession IDs by default but just because the cookie protcol says they get
returned if the domain path matches, doesn't mean to say they get processed
by an app.
> This is nothing new (although a good write-up).
>
> On Wed, 18 Dec 2002 12:13:26 -0800 Alex Russell <alex () netWindows org>
wrote:
> > I don't know if anyone else has seen this yet:
> >
> > http://online.securityfocus.com/archive/1/303838/2002-12-15/2002-
> > 12-21/0
> >
> > but I thought it would be on topic here. I realize that it's something
> > of a
> > rehash of the session authentication discussions we've had before,
> > but I'd
> > like to point out that it does expose a weak property of the "one
> > sessionID
> > for everything" model that's been proposed thust far, which is that
> > it does
> > not allow a interaction with the client to re-instate whatever security
> > may
> > have been previously broken.
> >
> > I think that in earlier discussions, I wasn't able to adequately
> > articulate
> > why I felt that issuing a new nonce for ever privledged operation
> > made more
> > sense (and why, correspondingly, you should never send the "real"
> > session
> > ID along with said nonce), but this article confirms what my gut
> > was
> > telling me: if you guard each action individually and require that
> > there is
> > a continuious line of known good iteractions, you'll be safer in
> > the long
> > run.
> >
> > The paper also points out the folly of assuming that client input
> > is somehow
> > "right" without validating it. Why in the world would an app server
> > ever
> > allow the end user to present to it the session ID that it will
> > use for
> > that client's continued interactions?
> >
> > --
> > Alex Russell
> > alex () netWindows org
> > alex () SecurePipe com
>
>
>
> Concerned about your privacy? Follow this link to get
> FREE encrypted email: https://www.hushmail.com/?l=2
>
> Big $$$ to be made with the HushMail Affiliate Program:
> https://www.hushmail.com/about.php?subloc=affiliate&l=427