From: Mike on
Hi,

Getting back to this because all efforts to defer until after we migrate to
..NET were kicked back. We really need to get a new ASPSESSIONID after the
user has been authenticated and need to do so in in Classic ASP.

I just tried the recommendation below to no avail. No proxy, just on the
LAN.

The logon page call Session.Abandon() and then the page opens another that
has <% @EnableSessionState = False %>, then in turn it opens the home page.
All the while the same ASPSESSIONID cookie persists. The Session was
definitely Abandoned

ASPSESSIONIDACBCDCQA=FBPJNMNCJGGBLMJMBOBFFMFL


"Ken Schaefer" <kenREMOVE(a)THISadOpenStatic.com> wrote in message
news:u9H4FPuuKHA.812(a)TK2MSFTNGP06.phx.gbl...
> Call Session.Abandon should be sufficient. When the browser returns the
> "stale" ASPSessionID cookie, IIS shouldn't accept it.
>
> Maybe you could try:
> Call Session.Abandon
> Redirect to a page that has session state disabled
> This new page just redirects to a page that does has session state
> enabled - new cookie value should be generated.
>
> Otherwise, I think we need to see all the various network devices in the
> path between client and server, and also have an understanding of how you
> are using Session.Abandon to get an understanding of the exact
> interactions of client and server, and the timings. ASPSessionID is just a
> cookie value returned by the client, and once you call Abandon, it should
> be invalidated on the server side. However, it may be that a proxy or
> something is messing things up.
>
> Cheers
> Ken
>
> --
> http://adOpenStatic.com/blog
>
>
> "Mike" <m(a)m.com> wrote in message
> news:u41eSBluKHA.6064(a)TK2MSFTNGP02.phx.gbl...
>> I wish I could. But our company has actually hired a security type
>> contact and what he explains that it is a valid request of the auditor.
>> In that it is something else that can be implemented in one's arsenal and
>> that it does successfully foil a percentage of attacker trickery.
>>
>> Thank you for your help. By chance, would you happen to have a sample of
>> abandon session that generates a new value for the ASPSESSIONID cookie?
>>
>> Funny these security dudes never have sample/examples.
>>
>> "Neil Gould" <neil(a)myplaceofwork.com> wrote in message
>> news:ORSiTZguKHA.2436(a)TK2MSFTNGP04.phx.gbl...
>>> Hi Mike,
>>>
>>> I would ask the Auditor for his/her rationalization for thinking such
>>> things. AFAIK, the SessionID is not a validator, other than for tracking
>>> a
>>> particular session. I'm not sure what your goal is, but it would seem to
>>> me
>>> that, in terms of security, you'd be in exactly the same place after
>>> terminating the current session and starting a new one.
>>>
>>> Neil
>>>
>>> Mike wrote:
>>>> Thank you for your help,
>>>>
>>>> Boy we have tried the heck out of Session.Abandon, to no avail. Would
>>>> definitely love to find that it is actually possible. Perhaps when
>>>> you say "giving them a new one" is where we've missed. We've been
>>>> thinking that was done automatically by IIS.
>>>>
>>>> The Auditor points out that a Session should not be the same before
>>>> and after authentication. That an entirely new one should be created
>>>> after signing on.
>>>>
>>>> "Ken Schaefer" <kenREMOVE(a)THISadOpenStatic.com> wrote in message
>>>> news:#9hrRk7tKHA.4624(a)TK2MSFTNGP02.phx.gbl...
>>>>> you can get a new ASPSESSIONID by terminating the user's current ASP
>>>>> session (e.g. Session.Abandon) and then giving them a new session.
>>>>> But if you are storing authentication information in session state,
>>>>> then the user will be "logged out"
>>>>>
>>>>> What is the rationale for requiring a new session ID?
>>>>>
>>>>> Cheers
>>>>> Ken
>>>
>>>