Re: ASP Session ID Reuse

[Neil Matatall <nmatatal () UCI EDU>]

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