I am the responsible developer for an ASP.NET application that uses the "Membership" (username and password) authentication scheme. I am presented with the following report from a WebInspect scan:
WebInspect has found a session fixation vulnerability on the site. Session fixation allows an attacker to impersonate a user by abusing an authenticated session ID (SID).
I retrieve the login page. When inspecting the cookies with Google Chrome's Developer Tools (F12), I get:
After authentication on the login page, I get an additional
while the session cookie stays the same (as preconditioned for a session fixation attack)
Attack: However, if steal/make up and fix only the
ASP.NET_SessionIdand inject it into another browser, the request is not authenticated. It is authenticated only after also stealing the
.ASPXAUTHcookie, which is only available AFTER login.
I come to the following conclusion:
While the typical precondition for a session fixation attack is met (non-changing session id), an attack will fail because of the missing, required additional
.ASPXAUTH cookie, provided only AFTER successful authentication.
So, should I really change the session cookie after login? Will this only satisfy the WebInspect scan or is there a real value here?
Note: I am very likely having the exact scenario as in Session Fixation: A token and an id, but I am not asking whether it is vulnerable, but what I should do with regards to the report.