2

Situation

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).

Reproduction

I tried to reproduce the typical session fixation attack, using the guide on OWASP:

  1. I retrieve the login page. When inspecting the cookies with Google Chrome's Developer Tools (F12), I get:

    • ASP.NET_SessionId w4bce3a0e5j4fmxj3b0lqkw2

  2. After authentication on the login page, I get an additional

    • .ASPXAUTH F0B9C00FC624E3F2C0CD2EC9E5EF7D10D91A6D62A26BAEE67A38D0608198750A2428E1F5D7278DCE6312C32EE2788D6C79E8112EA35B2397DB84FBB2BE1DBDA815A304B12505D2B786B00038B1EB0BE854DBDAF13072AFEDB3A21E36A7BCD7CD0032A0BCE8E90ECEAFA5FF487D6D2E2C

    • while the session cookie stays the same (as preconditioned for a session fixation attack)

  3. Attack: However, if steal/make up and fix only the ASP.NET_SessionId and inject it into another browser, the request is not authenticated. It is authenticated only after also stealing the .ASPXAUTH cookie, which is only available AFTER login.

Conclusion

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.

Question

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.

Marcel
  • 3,494
  • 1
  • 18
  • 35

1 Answers1

1

I think you could ignore the report. Tools automate tasks so you should always review the findings, as in this case.

The tool maybe just checks if the value of the cookieA is equals to the value of cookieA after the authentication and then tells you if your app is vulnerable or not. Probably it doesn't consider how the new secret the server is giving to the user protects it from the session fixation attack.

The prerequisite of the session fixation attack is that the attacker should be able to know a session id value which doesn't change after the authentication (this would occur using only ASP.NET_SessionId).

In your scenario the attacker can't hijack the session because the handling of the session is not based only on one secret but involves 2 strictly coupled tokens and he can't know the secret set after authentication.

Maicake
  • 497
  • 1
  • 3
  • 13