views:

220

answers:

2

I am using ASP.NET MVC to build a web application. In the main screen of logged-in user, I am using User.Current.Name to determine logged-in user identity, this is mapped to ID of a domain model data that is related to the current user. No one else should be able to see or edit this information (say his profile).

I am using membership and roles to ensure that only logged in users in particular role are able to invoke this action (Home action of UserController in this case)

There is going to be no HTTPS for this application when it is deployed.

Is this approach considered a safe approach? Is there any chance for malicious user to fake his identity to ensure that User.Current.Name returns a different name? Is there any additional configuration required to ensure that no one can "steal" the authentication cookie of another user?

EDIT: Standard Forms authentication is used.

A: 

As long as you have set the machineKey property in web.conrfig, the cookie is encrypted on the server side, and no one can fake that information. However, since the standard authentication mechanism in ASP.net MVC is regular Forms authentication, you should enable SSL so that no one can sniff the username and password when logging in.

Another approach is to use a different authentication mechanism. This could be windows authentication, kerberos, use of client certificates etc.

Kristoffer Deinoff
Thank you for your answer.None of the mentioned authenticated mechanisms are not an option for me. So you are basically saying that besides sniffing username/password from the HTTP traffic, there is no option to fake another user's identity in this scenario?
Marek
Not true - the cookie is not encrypted by default.
blowdart
Sorry. I forgot to mention to set the machineKey property in web.config. When this is done, both viewstate and forms ticket are encrypted.
Kristoffer Deinoff
Again no - viewstate is not encrypted by default, you need to turn that on, even if you set a machine key
blowdart
You're right. Seems like I had a bad source for this.
Kristoffer Deinoff
+4  A: 

OK so, setting HTTP sniffing aside because you won't be using SSL, the main problem point is the authentication cookie.

The forms authentication/roles cookie isn't encrypted by default, it is only signed against tampering. You can encrypt it using

<forms protection="All" ... />

This will use the machine key specified in machine.config or web.config to encrypt - so if you want the cookies to live across app recycles you will need to set a specific machine key.

You should also look at not persisting cookies (i.e. no "Remember me" option) and ensure that secure pages that require authenticated access are placed in subdirectories/controllers that separate from the anonymously accessible pages.

You may also want to reduced the cookie lifetime, which can reduce the amount of time a stolen cookie lives for.

<forms 
    timeout="10" 
    slidingExpiration="true"... />

You should also be encoding all your output to web pages to stop Cross Site Scripting, as this is the major way of cookie stealing. The ASP.NET cookie is HTTP-Only, which means it should not be served up via javascript, however not all browsers implement this (Safari doesn't).

blowdart