ASP.NET MVC 4 and session security leak

Question

Instead of using ASP.NET MVC User's system, I'm simply using session, as the following:

When he logs in (username + password), I fetch the corresponding user from the Database and set:

Session["UserId"] = fetchedUser.UserId;

Then, I'm always checking if he is logged in:

if (Session["UserId"] != null && ...)

The problem is that if someone copies the value of ASP.NET_SessionId from a logged in user (eg: user goes to bathroom and coworker who is sitten next to him checks his cookies with chrome inspector), then he will be able to create a cookie in his computer and act as that user.

My questions are:

1. Why are sessions safer than cookies if the session id is saved in a cookie?
2. Can I make this safer (and continue using session)?
3. How does internally ASP.NET User authetication system do it?

Answer 1

A primary reason for not using Session as an authentication mechanism is that it could render your application vulnerable to Session Fixation. For example, a problem could be if a user arrived on your site using the HTTP protocol and receives a session ID that is stored in the ASP.NET_SessionId cookie. The user may later log in, and even though your login pages might be secured under HTTPS the session token has already been generated under HTTP which means it has already been transported using cleartext.

To answer your other points:

Why are sessions safer than cookies if the session id is saved in a cookie?

The data stored in session is stored server side, so it is more difficult for an attacker to tamper with this data. All the cookie stores is a token for this data, rather than the data itself. Having said that, it is still safer to use the FormsAuthenticationProvider as this creates a new authentication token once login is complete rather than on session start for the reasons of avoiding session fixation as above.

Can I make this safer (and continue using session)? How does internally ASP.NET User authetication system do it?

The built in provider is already fit for purpose, so it would be desirable to use that rather than fudge another mechanism to meet your requirements. It is also easily extensible so you can customise it to your needs. The ASP.NET User Authentication creates an encrypted ticket and stores it in the cookie rather than storing a reference to a server side variable: http://support.microsoft.com/kb/910443

I would also draw your attention to the signout mechanism and how to secure it. Particularly

Calling the SignOut method only removes the forms authentication cookie. The Web server does not store valid and expired authentication tickets for later comparison. This makes your site vulnerable to a replay attack if a malicious user obtains a valid forms authentication cookie.

Details here: http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.signout.aspx

In addition you may want to set the "secure" flag on your ASP auth cookie to prevent it being leaked over HTTP by a MITM attacker.