Educause Security Discussion mailing list archives
Re: ASP Session ID Reuse
From: Neil Matatall <nmatatal () UCI EDU>
Date: Wed, 11 Feb 2009 11:14:49 -0800
Brian: yes, the ASPSESSIONID is used to keep session state. 1) Ensure the application isn't vulnerable to session fixation. --That's pretty much what this exploit is, a very low-tech session fixation attack. I should have scrolled down on the OWASP page, there is a section devoted to destroying cookies on logout O:-) Ozzie: using non-persistent cookies and remembering to clear them upon logout should be sufficient, right? I'm testing the session timeout as I'm writing this, but I trust IIS will handle this gracefully. When I initially spoke with the vendor about this, their response was that they are calling Session.Abandon upon logout. It seems to me that this should also clear the session ID cookie. If clearing session ID tokens is a best practice and there is little benefit to reusing them, why isn't it the default behavior? Why leave it up to the programmer? It looks like Tomcat (or whatever standard governs it, servlet-api?) acts the same way (although it doesn't share session IDs across same-domain applications like IIS does). I can't think of a good reason to keep the session cookie around once a session has been invalidated. Also, isn't sharing session IDs across multiple applications a bad idea? What if one app is rock solid, while the other is full of XSS or other session compromising vulnerabilities? If they are on the same domain, can't you steal the session ID from one application and use it in the other application? I can't find anything that says "every application should have their own session IDs". Neil Brian Reilly wrote:
Hi Neil, Does the application use ASPSESSIONID to keep session state? If it's merely set by the web server but not actually used to keep state (and other properly-managed cookies are used for state), then the risk is significantly reduced. However, if ASPSESSIONID is used for session management, then I'd agree that what you describe is a very bad idea and is an application vulnerability. The application should re-set a new sessionID value upon successful login, and clear the cookie value in the client and invalidate it at the server upon logout. Additional best practices to protect sessionIDs include: 1) Ensure the application isn't vulnerable to session fixation 2) Ensure that adequate entropy and cookie length is used during sessionID creation (more of an issue when rolling your own than with vetted app platforms) 3) Set the 'Secure' flag on all cookies if the application only uses HTTPS 4) Set the 'HTTPOnly' flag on all cookies if client-side script does not need to access them (if script access to cookies *is* required, that should be fixed as well, then the HTTPOnly flag should be set.) (And just about everything else in the OWASP Session Management guide.) --Brian On Tue, Feb 10, 2009 at 7:40 PM, Neil Matatall <nmatatal () uci edu> wrote:Hello All, While pen testing a vendor ASP application, we found that the session ID cookies are reused by default. I feel that I must be missing something here. Isn't this a bad idea? Under OWASP's "Things To Do" section on session management: "For all applications, session tokens should be regenerated after a change in user privilege." - this applies to a user who is unauthenticated that becomes authenticated and vice versa, correct? Assuming your cookies are safe, the following exploit still exists Login as User1 Copy the ASPSESSIONID* cookie name and value Log out Login as a User2 On a different computer (or browser), create the cookie with the previous information. Visit the application and you will see that you are logged in as User2 http://support.microsoft.com/kb/899918 actually discourages removing the session id cookie values! What are you doing to protect you ASP session IDs? Neil Note: this is not an ASP.Net application, just plain old ASP. This is my first experience with ASP :P
Current thread:
- ASP Session ID Reuse Neil Matatall (Feb 10)
- <Possible follow-ups>
- Re: ASP Session ID Reuse Brian Reilly (Feb 10)
- Re: ASP Session ID Reuse Ozzie Paez (Feb 10)
- Re: ASP Session ID Reuse Neil Matatall (Feb 11)
- Re: ASP Session ID Reuse Brian Reilly (Feb 11)
- Re: ASP Session ID Reuse Ozzie Paez (Feb 11)
- Re: ASP Session ID Reuse Josh Drummond (Feb 11)