We recently updated our solution to MVC 2, and this has updated the way that the AntiForgeryToken works. Unfortunately this does not fit with our AJAX framework any more.
The problem is that MVC 2 now uses symmetric encryption to encode some properties about the user, including the user's Name property (from IPrincipal). We are able to securely register a new user using AJAX, after which subsequent AJAX calls will be invalid as the anti forgery token will change when the user has been granted a new principal. There are also other cases when this may happen, such as a user updating their name etc.
My main question is why does MVC 2 even bother using symmetric encryption? And then why does it care about the user name property on the principal?
If my understanding is correct then any random shared secret will do. The basic principle is that the user will be sent a cookie with some specific data (HttpOnly!). This cookie is then required to match a form variable sent back with each request that may have side effects (POST's usually). Since this is only meant to protect from cross site attacks it is easy to craft up a response that would easily pass the test, but only if you had full access to the cookie. Since a cross site attacker is not going to have access to your user cookies you are protected.
By using symmetric encryption, what is the advantage in checking the contents of the cookie? That is, if I already have sent an HttpOnly cookie the attacker cannot override it (unless a browser has a major security issue), so why do I then need to check it again?
After having a think about it it appears to be one of those 'added layer of security' cases - but if your first line of defence has fallen (HttpOnly) then the attacker is going to get past the second layer anyway as they have full access to the users cookie collection, and could just impersonate them directly, instead of using an indirect XSS/CSRF attack.
Of course I could be missing a major issue, but I haven't found it yet. If there are some obvious or subtle issues at play here then I would like to be aware of them.
It was added to offer greater protection in the case where you have one subdomain trying to attack another - bad.example.com trying to attack good.example.com. Adding the username makes it more difficult for bad.example.com to contact good.example.com behind the scenes and try to get it to generate a token on your behalf.
Going forward, it's possible that the cookie will be removed as it's not strictly necessary for the proper functioning of the system. (For example, if you're using Forms Authentication, that cookie could serve as the anti-XSRF cookie instead of requiring the system to generate a second cookie.) The cookie might only be issued in the case of anonymous users, for example.
Besides the "evil subdomain"-scenario outlined by Levi, consider an attacker that has an account on the targeted site. If the CSRF-token does not encode user-specific information, the server can not verify that the token has been generated exclusively for the logged-in user. The attacker could then use one of his own legitimately acquired CSRF-tokens when building a forged request.
That being said, anonymous tokens are during certain circumstances accepted by ASP.NET MVC. See Why does ValidateAntiForgeryTokenAttribute allow anonymous tokens?
Related
I want to create a authorization mechanism for an application based on WebAPI and AngularJs.
I've seen some articles, which use BasicHttpAuthentication, but i really don't like the whole idea of sending username, and password on every request. The more it doesn't fit for me is because i want to use OpenId authentication, where you don't have username/password pair.
I'm thinking about a solution, but I don't really know how to implement it. The concept is that user is authenticated as in an usual Web application - posts a form with user / password or selects an OpenId provider. If the user is authenticated succesfully, it is placed in a static object, which stores the User object for a certain ammount of time. Next a usertoken is generated and passed to the Client Application. The client passes the token on each request to the server, if the user exists in the above mentioned static object with the appropriate authentication token it is authorized to get the data.
Firstly - Do you think this is a good approach to the problem?
Secondly - How should I pass the authentication token, WITHOUT using cookies? I guess it should sit in the request headers, like in BasicHttpAuthentication but, I really dont' know how to handle it.
BasicHttpAuthentication
I'm with you on feeling dirty about caching the username and password on the client and forever transferring it with every request. Another aspect of Basic authentication that might work against you is the lack of sign-off. Other than changing the password, you can't "invalidate" a basic authentication session. Tokens on the other hand, will typically offer an expiration date, and if you want server-side invalidation you can check the issue date and say "any tokens older than issue date xyz are invalid".
Server State
You mention "If the user is authenticated successfully, it is placed in a static object". But this is independent of the token? This sounds like you're wanting to implement server state management of authentication sessions, but this isn't strictly necessary. The token itself should be sufficient for user authentication, managing server state is another potential obstacle. Server state can become difficult to manage when you factor app-pool recycles or web-farm environments (what if you want two services to share the same authentication token, but not require communication with a central "authentication server" for storing the state / session?)
Passing Authentication Token
Headers is definitely a good place for it. Really, where else is there? Cookies, Headers, Message. Other than a browser client, cookies don't make a lot of sense, and including it in the message can muddy your message formatting a bit, so headers is the only remaining option that makes much sense in my view.
Client Implementation
You've not specified, but I suspect you're interested in calling the service from .NET? In which case System.Net.Http.HttpClient could be your friend. In particular, the DefaultRequestHeaders collection. You can use this to add a custom header to store your authentication token.
Server Implementation
When researching ASP.NET authentication recently, I learned a lot about customisation by examining the Mixed Authentication Disposition ASP.NET Module (MADAM). I wasn't interested in using MADAM as-is, but learning about it from that article and examining the source code gave me a lot of ideas of how I could insert my own authentication module into the web stack.
I'm using a login form to authenticate users.
FormsAuthentication is right out as it stores sensitive user/role membership in either client-side in a cookie or within the URL. Within the URL is a huge security risk, so I won't even get into that. With the
FormsAuthentication cookie, this creates problems with a) security where the client is in the position of dictating it's own roles; and b) way too much data stored in cookies. Since I'm gaining nothing through security and loosing out big time on the size of user data storage, I'd rather just work with Sessions.
I'd like to reuse something like FormsAuthentication for all its basic login form-handling features. But i would rather have it store user data server-side in perhaps Session rather than client-side all stuffed into a single cookie. I'd rather just authenticate against a Session token of some sort.
I have no database and local disk storage of user data is forbidden. I rely on a 3rd party authentication service provider, and a requirement is that I must reduce chatter with this service. Thus, sessions for temporary storage of user info. Sucks, but that's not necessarily the problem I'm asking about. Also, a requirement is that I must set/use HttpContext.user and likely Thread.CurrentPrincipal for use later on in such things as AuthorizeAttribute, for displaying user info in views, etc.
So FormsAuthentication stores all user data client-side in a cookie. Whereas Session stores all data server-side and just relies on a simple client-side token cookie. However, Session is not available anywhere during the asp.net startup and authentication steps. Is there an equivalent forms "membership" provider that stores all data in Session server-side instead of client-side?
If there is no Session equivalent...
Where do I set HttpContext.user and Thread.CurrentPrincipal to make both values available throughout the rest of both MVC apps without interfering or messing up other MVC components?
Hinging on #1, is Session available at that entry point? If not, how do I make it available so I can create the Principle/Identity object using the data stored in Session?
This can't possibly be a unique requirement. Are there libraries already available which handle this?
Session stores information in a client-side cookie too! (or in the URL if cookieless).
If you want to authenticate a client, he'll have to provide some kind of credentials - usually an encrypted token in a cookie once he has logged on. If not a cookie, then what do you propose?
You should use FormsAuthentication. The sensitive information stored in a client-side cookie is encrypted using a key that should only be known to the web server. "the encryption methods being public knowledge" doesn't mean that you can decrypt the data without access to the appropriate cryptographic key.
You mention "roles" and a "third-party authentication provider". If your third party is also providing roles (i.e. an "authorization provider" as well as an "authentication provider"), then it would be reasonable to cache roles obtained from the provider on the server. Session is not available when a request is being authorized, so the best solution is to use the Cache (System.Web.Caching.Cache).
Personally I would encapsulate this in a custom RoleProvider. The custom RoleProvider would implement GetRolesForUser by getting roles from the third party on the first call, then caching them in Cache.
Not sure if I like what I'm about to suggest, but you could do the following:
Leverage the Application State or System.Cache as a global storage for user credentials.
Use an InMemory database (like RavenDb) which can also have encryption (in memory, I believe).
Using the Application state as a place to storage relatively common / frequent stuff I think is not a great place because of
Scaling / locking issues? <-- just a gut feeling.
Permenant data? so you have users in the website's memory .. then the website crashes or recycles, etc... what happens now to that data?
RavenDb is awesomeballs - go.use.it.now.
I understand that you are not storing anything locally, so whenever a user hits your system, you need to refresh your inmemory cache, etc. Fine. A pain in the f'ing butt , but fine none-the-less. (EDIT: unless the data has been cached in memory .. that is)
Anywys, two suggestions.
ProTip:
Oh! move away from role based shiz and start using Claims based identity stuff. Yes, it still works with IPrincipal and HttpContext.User, etc. So all previous code is NOT busted. But now it's baked into .NET 4.5
Awesome Video on this for you, me, everyone!
Finally - bonus suggestion
A nice package that auth's with either Facebook/Google/Twitter. You said you're keeping the user cred's on another site (good move!). If you're using other providers, then stick with DNOA or SS.
GL!
I wish to secure individual (dynamic) pages in an ASP.NET MVC application.
I do not want to use a full blown authentication system - we are already using forms authentication for the administrators of the site. Instead, this is so that we can send out links to a page with a password for specific users.
The way I am handling this currently is when a valid password is submitted we create an encrypted cookie containing the page id (Guid) and their session id and redirect them to the page. In our "Page" controller action we then validate this cookie.
So first question, is this the best (most secure) approach (aside from using forms authentication)?
Second question, can I read the machine key used by Forms Authentication to perform the encryption, or better yet use the FormsAuthentication to encrypt the cookie (the only overload I can see is one that requires a FormsAuthenticationTicket)?
Since we always generate a new machine key before deploying it would be better if all our encryption used the same key.
[Update]
Regarding how to access the machine key I found my answer at http://rich-rogers.com/archive/asp.net-c-sharp-encrypt-hash-using-machinekey-values
[Update 2]
I realize after asking this question that since I will need to maintain a list of pages that they do have access to, I would probably be better off just storing these in the current session. I can store a list of security tokens with an expiry date. Since I already have a wrapper around session, this should be easy to unit test too.
To make really secure your cookie-key, you need to make it available only on SSL pages, or else some one can get it, and even if its encrypted he can use it.
Request.Cookies[cookieName].HttpOnly = true;
Request.Cookies[cookieName].Secure = true;
Also to read: Can some hacker steal the cookie from a user and login with that name on a web site?
I'm developing an ASP.NET web site for some small business. The site needs a password-protected area where the site owner will manage the site content. For the rest of the world, the site is completely read-only.
I've designed and implemented the following scheme:
A user wants to access some protected page.
Every protected page inherits "AdminIface" master page, that alters the UI so that user knows he's on a protected page, and checks the security cookie. If no cookie or wrong cookie: redirect to auth.aspx.
Auth.aspx generates a big random number using RNGCryptoServiceProvider, then sends it to the client + password form.
User enters the password.
Client-side JavaScript combines random seed + password, calculates MD5 of the resulting string, posts MD5 to the server.
Server compares the random seed with the value hold by Session, if OK it combines random seed + password, calculates the MD5, compares MD5.
If the checksum matched – the server generates one more big random number to be used as a security cookie.
Server stores the security cookie in Session object, and sends the cookie to the client who's now considered authorized.
The correct password is stored as a string constant in the auth.aspx source.
Is this scheme OK?
P.S. I know AD+Kerberos is much better, however on the godaddy's shared hosting I've got no privileges even to create one more application.
I would just hard code the user authentication into the web.config. This means you can still use the Membership controls. A really good example can be seen here. No database required, nor Membership provider. If you have one user (or very few users) then this is a pretty good option.
If you are worried about the authentication details sitting in the web.config, then you can encrypt specific sections of the web.config.
This would appear to be a much simpler solution than you have implemented.
It sound ok. Standard HMAC stuff. However your weaknesses:
Application: relying on javascript and sessions
Security: using a new codebase
Depending on your requirements you might be ok. having said that I strongly suggest using forms authentication, which overcomes these issues and much more.. and it is fairly easy to use.
Ummm, why not http://en.wikipedia.org/wiki/Basic_access_authentication with https (or even without)?
-- What's the real scenario of a threat?
Your method seems a bit hand-rolled. The usual rule is to try to use an existing security system rather than inventing your own. Inventing a new authentication mechanism that is really secure is known to be a very hard problem.
Many intelligent people (namely the Software Engineers who created WEP) have tried and failed at creating their own security authentication mechanisms and failed. The possibilities for screwing up your own "custom" security authentication are endless (no offense, but it is an extremely difficult problem to handle even for security experts).
I think it's best to use something that is proven to work such as an SSL certificate based authentication method.
What is wrong with TLS/SSL? It would provide many benefits here, the least of which is some thread of site->user authentication.
As kind of already mentioned, why not just use forms authentication with an SSL cert - dead easy to set up (particularly for one user) and you know that it's been tested... You don't know what you've potentially missed.
Does using cookies pose a threat to application security in asp.net ? Or do we only use as a medium of saving user stats and non-vital information ? Got a little details of using cookies in asp.net from my own blog
IMO cookie is one of the best choice for some situations. For instance, storing the user's selected language. Also you can cache some sensitive information in the cookie as users' roles as ASP.NET Roles manager. But you should encrypt it without doubt and also you should set HttpCookie.HttpOnly = true to prevent javascript from accessing to cookie. Don't worry about supporting cookie in different browsers, size is premier (Browsers support only 4096bytes per cookie). Cookie is bandwidth killer, cause sends and receives within each request and response. Thus, you should use it in avarage. You can check if the client browser supports cookie as follows.
if (Request.Browser.Cookies) { // The browser supports cookie }
To learn more information about cookies, visit here.
Using cookies doesn't pose any threat to an application. It is the way you use them and the information you store that could be problematic. For example, you have to avoid storing sensitive information in cookies. If used for authentication, they should always be transmitted over a secure channel.
It depends on how you use them. Cookies should be treated as un-trusted input at all times, because they can be faked, edited or deleted. I've seen applications where a cookie contains something like admin=true which is obviously a very bad thing to do. If you're just dropping some guid and using that to track someone, but not caring if your results are accurate then that's fine.
If you want to make sure the cookie is semi-valid then you must add something like an HMAC to the cookie itself, which is what ASP.NET does with the forms authentication cookie (and the ViewState field). Of course this doesn't stop the user deleting the cookie, or copying a valid one from another user.
As long as you don't store critical information in the cookie (like the user's password) you should be fine.
Be careful with scenarios like that :
You store the user's ID in a cookie
You test against this ID to see if he's logged in
The user changes the ID manually in the cookie (easy to do)
The user gets access to another account
My point is that you have to keep in mind that the user can access a cookie and change it, so don't store anything you wouldn't want him to see.
Last thing, cookies often have a limited size so be careful: don't store too many information. If you store too much stuff (like a large object), you might end up breaking things.