Re: Exploiting Session Fixation on ASP

[pentest pentest <pentest108 () gmail com>]

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!

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