Session Fixation in ASP.NET

Question

I'm wondering how to prevent Session fixation attacks in ASP.NET (see http://en.wikipedia.org/wiki/Session_fixation)

My approach would to this would normally be to generate and issue a new session id whenever someone logs in. But is this level of control possible in ASP.NET land?

Stimson

My fix to session fixation is to turn it off! – Unmindful

One of our older ASP.NET applications had this reported as part of a pen test and I found none of the answers here sufficient to address session retention after logout when using session cookies. I believe @display-name's solution at #47335870 is valid regardless of whether the application is using ASP.NET Core up through at least ASP.NET Core 8, or legacy ASP.NET. – Principal

Answer 1

Have been doing more digging on this. The best way to prevent session fixation attacks in any web application is to issue a new session identifier when a user logs in.

In ASP.NET Session.Abandon() is not sufficient for this task. Microsoft state in http://support.microsoft.com/kb/899918 that: ""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.""

A bug fix has been requested for this at https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=143361&wa=wsignin1.0&siteid=210#details

There is a workaround to ensure new session ids' are generated detailed at http://support.microsoft.com/kb/899918 this involves calling Session.Abandon and then clearing the session id cookie.

Would be better if ASP.NET didn't rely on developers to do this.

Stimson

This sounds like a good way to do it, but it sounds like it doesn't generate a new session ID upon login, so an attacker could theoretically set a cookie on a shared computer, then wait for someone to log in using it, and the session ID would not be updated (the attacker would know it). Like you said, developers should definitely not have to worry about this. – Manakin

I am under impression that clearing session ID cookie can only help when an attack occurs after a legitimate user logged off the site. But if the attacker accesses the site simultaneously with the legitimate user, this method will fail. – Haslet

I think this answer should be updated to be clear, the workaround page does not exist anymore. – Kktp

You can use wayback machine for broken link. web.archive.org/web/20170122000918/https://… – Basham

@Rathma, that page will try to automatically redirect you. It's not that helpful anyway. – Dynamotor

Answer 2

Basically just do this in your Login GET method and your Logout method:

Session.Clear();
Session.Abandon();
Session.RemoveAll();
if (Request.Cookies["ASP.NET_SessionId"] != null)
{
   Response.Cookies["ASP.NET_SessionId"].Value = string.Empty;
   Response.Cookies["ASP.NET_SessionId"].Expires = DateTime.Now.AddMonths(-20);
}

Unlive

This is a good answer, but as for the 1st 3 lines of code, only Session.Abandon() is needed; the .Clear() and .RemoveAll() are superfluous. Using all 3 could give the impression to other developers looking at your code that you are trying to achieve something that will never happen, or that you think there is something in .Clear() or .RemoveAll() that is not done in .Abandon(). I might also suggest that the Response.Cookies code you have are placed in Session_OnEnd, so that if session ends for other reasons, you still clear your cookies. .Abandon() triggers session_onend(). – Pectin

Answer 3

If I am assuming right, you are talking about... http://en.wikipedia.org/wiki/Session_fixation. The short answer is yes, you have a lot of ways in which you can secure your cookie as well. You shouldn't be using cookieless session, and while you are using sessions, ensure that you have secured the cookie as well explicitly.

Check this article out... http://blogs.msdn.com/rahulso/archive/2007/06/19/cookies-case-study-with-ssl-and-frames-classic-asp.aspx

Pump

It is unlikely he is using cookieless sessions. Session fixation is much more common, especially in ASP.NET, with cookie sessions. Your link is correct, but does not not relate to this topic, other than they are both about session security. – Manakin

Answer 4

It does generate a new session ID when the user logs in, and kills a session when the timeout occurs, or the user navigates away/close the browser. And you can programmably kill it via Abandon() or remove entries via Remove().

So I'm not sure what the issue is?

Myall

ASP.NET very commonly will reuse the cookie that is already set (enabling session fixation), so no, it does not always generate a new cookie when the user logs in. – Manakin