WebApp Sec mailing list archives
Re: post to bugtraq about "session fixation"
From: securityarchitect () hush com
Date: Wed, 18 Dec 2002 11:28:34 -0800
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
Current thread:
- post to bugtraq about "session fixation" Alex Russell (Dec 18)
- <Possible follow-ups>
- Re: post to bugtraq about "session fixation" securityarchitect (Dec 18)
- Re: post to bugtraq about "session fixation" Kevin Spett (Dec 18)
- Re: post to bugtraq about "session fixation" Alex Russell (Dec 18)
- Re: post to bugtraq about "session fixation" Kevin Spett (Dec 18)
- Re: post to bugtraq about "session fixation" Panayiotis A. Thermos (Dec 18)
- Re: post to bugtraq about "session fixation" Steven M. Christey (Dec 19)
- Re: post to bugtraq about "session fixation" Cesar (Dec 20)
- Re: post to bugtraq about "session fixation" H D Moore (Dec 20)
- Re: post to bugtraq about "session fixation" Cesar (Dec 20)