Re: ASP Session ID Reuse

[Ozzie Paez <ozpaez () SPRYNET COM>]

Neil,

ALL of your concerns are well taken - as a systems designer/programmer, I
have stayed away from Session Cookies as much as possible, precisely because
they open all kinds of questions that I could not get good and consistent
answers for.  Sometimes I would get an explanation and it would seem
reasonable, until I saw a behavior that contradicted what was explained.  A
major problem that I faced was with third party tools that I integrated into
my applications, such as Crystal Reports, which required the use of cookies,
pop-ups, etc.  With my own software, I used a defense in depth approach to
security:  Use https as opposed to http for the connections, stay away from
cookies and, where some aspect of the state of an application was needed, I
used session variables, which are destroyed when the connection is
terminated (although I minimized their use as much as possible).  I did not
allow the use of shared cookies, session IDs or any other inter-application
method without justification.   In the end, no real justification was every
offered beyond convenience, which was not enough.  If I needed to provide
some status on user log-in, I looked for options such as maintaining a
status in an encrypted database table that could be queried with rules, i.e.
if the status is older than x seconds, assume it is not valid.



One of the major headaches that I ran across has been with testing
applications that do not terminate gracefully, i.e. the browser locked up or
the user simply closed the browser window without logging out.  Those
events, I found, could at times leave information behind or keep it
accessible longer than needed.  The problem here is that some of these
events are not detected as a form of logout, so they may not trigger a
cookie/session id destruction directive or command.  Finally, it is
instructive to consider where cookies are stored because, even if they are
destroyed on logout, they could be examined while the application is active,
thus creating a vulnerability while the session is going.  I wish that I
could offer you a formula, but as with anything Windows, there are always
one or more exceptions.  I think that you are doing the right things
bringing up these questions. My experiences with vendors is that sometimes
security is an add on, in that their core expertise is with the nature of
the software, i.e. accounting, SRM, etc., and their security models suffer
over time, as new OS releases and other changes make them less effective.
It is a pain, but you have to ask and ask again.  If you are a programmer
for a vendor, then you have to dig and dig again to make sure that you are
not creating a problem.  Problem is that many end users don't want to pay
for that, so it can be a vicious circle.  Once again, I think that you are
doing the right things and unfortunately will have to keep at it,


Best of luck - feel free to shoot me an e-mail at any time,



Ozzie Paez

SSE/CISSP

SAIC

303-332-5363



From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Neil Matatall
Sent: Wednesday, February 11, 2009 12:15 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] ASP Session ID Reuse



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  <mailto:nmatatal () uci edu>
<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