Prev: IIS 7.5 on Windows 7: no ".Net Users" and ".Net Role" functionalities in the ASP.NET zone...
Next: Getting IIS to work in Win XP (SP3) with ASP etc
From: Mike on 29 Apr 2010 16:10 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 >>> >>> |