Re: Exploiting Session Fixation on ASP

[Rogan Dawes <lists () dawes za net>]

pentest pentest wrote:
> Hi Rogan,
>
> Thank you very much for taking the time to respond to my question.
> I wasn't aware about these details so I've read the paper you've recommended.
> I only knew about session fixation using "Session ID in an URL
> argument" (as named in the paper).
> However, this paper doesn't provide specific information about ASP.
>
> What I want to know if how do you fix the session for ASP applications.
> My guess is that you cannot do it through an URL argument as in PHP
> and you need to set the "Session ID in a cookie" using one the
> following techniques:
> A. using a client-side script that sets a cookie on the browser;
> B. using the HTML <META> tag with Set-Cookie attribute;
> C. using the Set-Cookie HTTP response header.
>
> Please confirm if I'm correct or not.
> Thanks and have a nice day!

The link that you originally quoted
<http://www.owasp.org/index.php/Session_Fixation_Protection> contains my
suggested approach to dealing with session fixation in ASP.

Basically, since you cannot influence the actual ASPSESSIONID cookie
value in the browser, you have to set another cookie in the client that
you CAN rotate when the authenticates and logs off. Store the expected
value of this cookie in the user's session. If a request is made with
the ASPSESSIONID cookie, but without the custom cookie matching the
value in the session, take the appropriate action, such as redirecting
the user to a "attempted hack detected" page, or to the login page.

Rogan

> On Thu, Feb 5, 2009 at 9:26 PM, Rogan Dawes <lists () dawes za net> wrote:
> > pentest pentest wrote:
>
> > There are a number of different "flavours" of session fixation.
> >
> > One is the ability to specify any session ID you like, and have it be
> > used by the framework, kind of an "auto-vivification", if you like.
> >
> > One is the failure to change the session ids when changing privilege
> > levels. For example, I go to an internet cafe, load a banking site, note
> > the session id issued. Offer the machine to my victim, and wait for them
> > to authenticate to the server. Go to another PC, and use that known
> > session id to hijack their session.
> >
> > Most frameworks support session invalidation (including ASP). When
> > authenticating, and when logging out, any existing session should be
> > invalidated, and a new one created.
> >
> > However, in ASP, when invalidating the session, only the server side
> > session is invalidated. No new ASPSESSIONID is issued to the client,
> > rather the old cookie is just associated with a new (empty) session.
> > This means that even if the server DOES follow the advice, and
> > invalidate the session, that ASPSESSIONID noted in the above example is
> > STILL valid, and can still be used to hijack that user's session.
> >
> > Hope this helps. If not, you should read the original paper at acros.si,
> > IIRC. Google is your friend. :-)
> >
> > Rogan