Re: post to bugtraq about "session fixation"

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).
wrote:
> >I don't know if anyone else has seen this yet:
Received on Wed Dec 18 16:33:25 2002