C# – Forms authentication security risk

asp.netciis-7net

I am using VSTS 2008 + C# + .Net 3.5 + IIS 7.0 + ASP.Net. In my understanding of Forms authentication, a session variable (used for authentication identifier — i.e. when a user passed authentication, the user will have such a session variable, and the session variable is implemneted as a cookie) is established for authenticated user.

My concern of this mode is, each time user access a page in the web site, the session variable will be transferred to server side. It may be sniffered by hacker, and hacker could use such session variable to pretend to be the end user? Is that a security risk?

If it is a security risk, then we have to use https all the time with Forms authentication?

thanks in advance,
George

Best Answer

I've had similar concerns in connection to a request from one of our partners... ( See in details here: https://stackoverflow.com/questions/1367574/rewriting-urls-using-reverse-proxy )

As it turns out this "legitimate" process is actually using a hacking method called the "middle man". It technically pretends to be the user by keeping the cookie ID in its own session context while dealing with the server and keep a sparate one for the client computer.

So, in theory it could be done and it is a threat. Using SSL is the right way to go in my opinion if the data is in any way sensitive.


Funny enough in this Microsoft Support article http://support.microsoft.com/kb/910443 the phrasing makes you believe that it is actually the same for each request...

Forms authentication cookie is nothing but the container for forms authentication ticket. The ticket is passed as the value of the forms authentication cookie with each request and is used by forms authentication, on the server, to identify an authenticated user.

The cookie could be encrypted, using 3DES encryption. This could be enabled by setting the protection attribute to Validation of the authentication section of the web.config file. Using this setting the server verifies the data on the cookie for each transaction. This adds a little overhead though...