Some platforms make it easy to protect against Session Fixation,while others make it a lot more difficult. In most cases, simplydiscarding any existing session is sufficient to force the framework toissue a new sessionid cookie, with a new value. Unfortunately, someplatforms, notably Microsoft ASP, do not generate new values forsessionid cookies, but rather just associate the existing value with anew session. This guarantees that almost all ASP apps will be vulnerableto session fixation, unless they have taken specific measures toprotect against it.
Here is some sample code to illustrate an approach to preventingsession fixation attacks in ASP. The idea is that, since ASP prohibitswrite access to the ASPSESSIONIDxxxxx cookie, and will not allow us tochange it in any way, we have to use an additional cookie that we dohave control over to detect any tampering. So, we set a cookie in theuser's browser to a random value, and set a session variable to the samevalue. If the session variable and the cookie value ever don't match,then we have a potential fixation attack, and should invalidate thesession, and force the user to log on again.
Here is a sample implementation:
AntiFixation.asp:
<%' This routine is intended to provide a degree of protection' against Session Fixation attacks in classic ASP' Session fixation attacks are a problem in ASP, since ASP does not' allow you any access to the ASPSESSIONIDxxx cookie. Even invalidating' the session does not alter the value of this cookie, preventing' implementation of best practice recommendations, such as' issuing new session cookies when the session is authenticated, or' invalidated.' The basic premise of this routine is that we create a cookie that' we CAN control, e.g. ASPFIXATION, and assign a random value to this' cookie when the session is authenticated. On subsequent pages, we' check the value of this cookie against the same variable stored in' the user's session. If they do not match, access is denied.' When the user logs out, the session should be invalidated, and so' by default, the cookie no longer matches the value in the session.Private Function RandomString(l)Dim value, i, rRandomizeFor i = 0 To lr = Int(Rnd * 62)If r<10 Thenr = r + 48ElseIf r<36 Thenr = (r - 10) + 65Elser = (r - 10 - 26) + 97End Ifvalue = value & Chr(r)NextRandomString = valueEnd Function' This routine should be called after the user has been authenticated.' It is expected that the session has been invalidated prior to this call.Public Sub AntiFixationInit()Dim valuevalue = RandomString(10)Response.Cookies("ASPFIXATION") = valueSession("ASPFIXATION") = valueEnd SubPublic Sub AntiFixationVerify(LoginPage)Dim cookie_value, session_valuecookie_value = Request.Cookies("ASPFIXATION")session_value = Session("ASPFIXATION")If cookie_value <> session_value ThenResponse.redirect(LoginPage)End IfEnd Sub%>Include the following lines in your login page:
<!--#include virtual="/AntiFixation.asp" -->
and, when your user is successfully authenticated:
AntiFixationInit()
All other private pages (i.e. only accessible by an authenticateduser) should include the following lines (preferably as the first coupleof lines in the file):
<!--#include virtual="/AntiFixation.asp" --><% AntiFixationVerify("login.asp") %>In this case, any requests that do not contain a valid ASPFIXATIONcookie will be redirected to the page indicated, in this case"login.asp". Note that we do not automatically invalidate the session,since that would allow a denial of service attack against the legitimateuser. If one were concerned about brute force attacks against thefixation cookie, one could either make the random value longer, and/oruse a counter in the session to detect repeated attacks, and invalidatethe session if a threshold is exceeded.
