3

I know how to handle this in ASP.NET, but is there a way to force the Classic ASP Session ID to be cleared? It is a randomly generated ID like ASPSESSIONIDG32423E that does not seem to be available in RESPONSE.COOKIES collection thus I can not clear it. We have a class ASP site still hanging around and recently it was an audit finding that after the user logs out the same session ID is reused.

MORE CLARIFICATION:

First visit to page, I see this in the proxy editor in Response:

Set-Cookie: ASPSESSIONID=PUYQGHUMEAAJPUYL; path=/Webapp

After a logout, I call Session.RemoveAll and Session.Abandon and then redirect user to login page. At which point I should see a new Set-Cookie with a different value for SessionID. Instead, I do not get a new cookie and the new login session reuses the original session cookie. This is an audit finding that we have to resolve in some way but there does not seem to be a way to control this.

Brian Edwards
  • 413
  • 7
  • 15
  • use Session.Abandon should do the trick - http://www.devguru.com/technologies/asp/quickref/session_abandon.html – Sunny May 21 '12 at 20:14

3 Answers3

3

So I did come up with a solution for this as follows. I added two pages called Start.asp and Start2.asp. The original login page was changed to check for a post variable which is now set on Start2.asp, so if login.asp does not see that post variable, it redirects to Start.asp. Start.asp invalidates the ASPSessionID by setting it to 0. The key is using Response.AddHeader "Set-Cookie" in order to do this since Response.Cookies("ASPSESSIONID...") gives an error that you can't access the element:

Code for Start.ASP

<%
If instr(Request.ServerVariables("HTTP_COOKIE"), "ASPSESSIONID") > 0 Then

    Dim Allcookies

    AllCookies = Split(Request.ServerVariables("HTTP_COOKIE"),";")
    For i = 1 to UBound(AllCookies)

        If instr(AllCookies(i), "ASPSESSIONID") > 0 Then
            Response.AddHeader "Set-Cookie", Left(AllCookies(i),instr(AllCookies(i),"=") -1) & "=0; path=/;secure;httponly"
        End if

    Next 
End if

Response.Redirect("start2.asp")
%>

Next, it calls Start2.asp which looks for all ASPSEssionID cookies and appends Secure; httponly (I had to add these for another finding, ASP metabase setting to add secure only works if the SSL cert. is on the web server. In our case the SSL cert is on a load balancer in front of the web server).

Code for Start2.asp

<%
    'CODE for authorization/authentication
   '...

Session.Contents.RemoveAll
Session.Abandon
If instr(Request.ServerVariables("HTTP_COOKIE"), "ASPSESSIONID") > 0 Then
       Dim Allcookies

        AllCookies = Split(Request.ServerVariables("HTTP_COOKIE"),";")

        For i = 1 to UBound(AllCookies)

            if left(Request.ServerVariables("HTTP_HOST"),2) = "65" and instr(AllCookies(i), "ASPSESSIONID") > 0 Then
                Response.AddHeader "Set-Cookie", AllCookies(i) & "; path=/;secure;httponly"
            End if        

        Next 

End if

%>

<html>
<body>
<form action="login.asp" method="post">
<input type="hidden" name="start2" id="start2" value="Yes" />

</form>

<script type="text/javascript">
     document.forms[0].submit();
</script>
</body>
</html>

Really, though, the new ASPSessionID is not generated until within Start2.asp so that Set-Cookie code for secure and httponly has to also be done in login.asp. So the same code above was copied to the top of login.asp just after this code:

If request.form("Start2") = "" Then
    Response.Redirect("start.asp")
End if
Brian Edwards
  • 413
  • 7
  • 15
  • The key is that the ASPSessionID can't be accessed via Response.Cookies so instead you have to do Response.AddHeader to manipulate to cookie as needed – Brian Edwards May 25 '12 at 15:31
1

IMO - you need to end the session rather than just clear out the session ID. In this case, Session.Abandon is the solution. Ref.: https://devguru.com/content/technologies/asp/session-abandon.html

HTH.

s.co.tt
  • 163
  • 9
Sunny
  • 6,286
  • 2
  • 25
  • 27
  • I have session.abandon in the logout page already but the problem is then next time the user logs in, it reuses the same ASPSessionID as I am seeing using burpsuite proxy editor. – Brian Edwards May 21 '12 at 20:24
0

This relates to ASP.NET but describes the behaviour you are seeing in ASP

When you abandon a session, the session ID cookie is not removed from the browser of the user. Therefore, as soon as the session has been abandoned, any new requests to the same application will use the same session ID but will have a new session state instance.

http://support.microsoft.com/?kbid=899918

This behaviour will only occur if using the same browser for the same session, as soon as the browser is closed the session cookie will be lost (providing an explicit expiry date has not been set).

You could try calling Session.Abandon then redirect the user to a page which uses JavaScript to clear all cookies, then redirect to the login page, or whatever page you like.

Clearing all cookies with JavaScript

Community
  • 1
  • 1
Chris Diver
  • 19,362
  • 4
  • 47
  • 58
  • 1
    Thanks I saw this article and this may add some clarification. First visit to page, I see this in the proxy editor in Response: Set-Cookie: ASPSESSIONID=PUYQGHUMEAAJPUYL; path=/Webapp After a logout, I call Session.RemoveAll and Session.Abandon and then redirect user to login page. At which point I should see a new Set-Cookie with a different value for SessionID. Instead, I do not get a new cookie and the new login session reuses the original cookie. This is an audit finding that we have to resolve in some way but there does not seem to be a way to control this. – Brian Edwards May 21 '12 at 20:33
  • I believe that there is the possibilty that session id's can be repeated, but not really in the scenario you describe. This article might also be interesting. http://support.microsoft.com/kb/q184574/ Every request ASP page is given a session id by default unless buffering is turned on. Have you tried logging out. Clear your cookies. Then re-login. I suspect the session cookie is being re-used but the server side session data is abandoned. – Chris Diver May 21 '12 at 20:46
  • Chris that does not appear to be the case because if the server was generating a new Session ID, I should be seeing it the next time I go to login.asp in the response of the proxy session. – Brian Edwards May 21 '12 at 21:03
  • The first time you hit any page on a ASP site, you get a session cookie, even before you log in. So when you log in, the site doesn't need to set another cookie it has already identified you. What i suspect is happening is that when you log out, that session cookie is not cleared. But the server side data in the session is cleared. So when you re-login you already have the old session cookie that you had previously and there is no need to give you a new one. Try clearing your cookies after logging out and see if you get a new ASPSessionId. – Chris Diver May 21 '12 at 21:12
  • But that issue won't be related to the problems identified in your audit, the worry is when you get the same session id across different machines or users. Once you've abandoned the server side data, the session id doesn't relate to anything, so there is no harm in re-using it for that user / browser that I can see. – Chris Diver May 21 '12 at 21:13
  • Chris I agree 110% with you on reusing it. In fact I think this out of box behavior prevents the possibility of a Session DOS attack, however the auditors are not very reasonable like you and I. Their take is if the session id is reused, I can find out what ID you are using and then come over to my workstation and pass the same token across to get your rights into the application. They made it a moderate finding that we have to now remediate. – Brian Edwards May 21 '12 at 21:33
  • I'm not sure how you find out my session id. You could say the same for any cookie. If you have access to my pc you can do anything, install key loggers etc... Good luck, I think your stuck though if you can't find the name of the session cookie to clear it yourself. You'd have to go down the route of writing something custom and persist session data in a database. – Chris Diver May 21 '12 at 21:46
  • In fact I have an idea. Do Session.Abandon, then redirect to a page with some javascript which clears all the cookies then redirects to whatever page you redirect to after log out. http://stackoverflow.com/questions/179355/clearing-all-cookies-with-javascript – Chris Diver May 21 '12 at 21:49
  • Thanks, I'll have to play with that a little bit. I noticed the example just removes the value from the client-side cookie so it still passes the session ID but with an empty value, thus invalidating the session and making it not able to login but I have some other ideas where maybe I can set the logout link to pass a delimitted string of ASPSessionIDs to the logout page and remove using Response.Cookies from server side. Not sure if this will work yet though. – Brian Edwards May 21 '12 at 22:59
  • Just wanted to update that it did not work, when I remove the cookie from the browser using that code, it fails to establish the session with the next login. I think I may be stuck. – Brian Edwards May 22 '12 at 13:17
  • From the reading in those articles, it sets a session id for every page unless buffering is turned on, if you turn buffering on it may delay creating the session cookie until you use the session details and POST to the login form so might work. `response.buffer = true` - but that is just a guess. – Chris Diver May 22 '12 at 13:22
  • Thanks again Chris, I did have response.buffer = true. I added another step to pass the list of cookies to another page to remove from Response.Cookies collection, still no luck. By the way, here is the auditor's lovely example: You login to the application, then you logout and walk away, I run a tool (like BurpSuite) and login on your workstation, capture the session token ID and then logout, wait for you to come back and login, then from my PC I can run BurpSuite and use your token to receive your rights in the application. And this is a moderate finding, really? – Brian Edwards May 22 '12 at 14:07
  • Sounds unreasonable to me. How can he log into your workstation? is he claiming that he knows the password of the user and that assumes that the browser is still open (as the cookie will expire on the browser closing)? If he knows that then there are worse things he can do. If he logs into your pc using his credentials then he shouldn't have the same browser session and his point is wrong. If he knows your password then he doesn't need the session id anyway, he can just log in as you. As another suggestion, add the IP address to the session variables on login, verify it on each request? – Chris Diver May 22 '12 at 16:08
  • That's a real good suggestion. I should clarify the scenario I gave a little. User A logs in does work and logs out and leaves browser open and computer unlocked. User B goes over runs BurpSuite or a like tool, logs in with their own User ID obtains the SessionID then logs out. User B then waits for User A to log in again and uses the token now on their own machine to obtain User B's rights. – Brian Edwards May 22 '12 at 17:18
  • I think the IP address verification could cover you, then UserB will get denied when they try on their own machine. Although i'm sure they could do worse things to the machine if left unlocked, install key loggers, install fake ssl certificates, set their machine as a proxy for all requests and intercept the traffic etc... – Chris Diver May 22 '12 at 17:24
  • The IP address addition will take the risk of something happening from extremely low to very extremely low :). However, it will not work in sites where the users go through a proxy server and I see the proxy server IP instead of a workstation IP. :( This will likely give the auditors ammunition to leave the finding opening. – Brian Edwards May 22 '12 at 17:47
  • Chriss - believe it or not, I found a solution to this one. I'll post below, not expecting too many others to need it though. – Brian Edwards May 25 '12 at 13:53
  • Great, please do post the answer, i'm interested at least. – Chris Diver May 25 '12 at 13:55
  • I posted it, my solutions was to meet 2 audit findings. The other was the aspsessionid cookie was not being generated with "secure" flag set. There is an IIS metabase setting to make it do this but found out that only works if the SSL Cert is on the IIS server. In our case, the SSL Cert is on a load balancer with an IPS device in between so traffic to and from the web server is http. – Brian Edwards May 25 '12 at 14:39