I am trying to adhere to the recommended settings for cookies for my MVC web application. My intention is to set HttpOnly = true, Secure = true and SameSite = Strict settings to cookies wherever appropriate.
I have two questions in this regard.
I am a bit confused on the settings for .AspNet.Cookies and __RequestVerificationToken cookies. Can someone please help me understand the purpose of these cookies. I roughly understand .AspNet.Cookies is Owin cookie and __RequestVerificationToken is used to prevent anti- forgery attack. But this is not enough make an informed decision on what is the recommended settings for these cookies. I believe setting HttpOnly and Secure attributes to these cookies would not hurt, but not sure on the SameSite setting, especially that I have got intentions to use a third party identity provider in near future.
As a trial attempt, I set the cookie settings to Strict, HttpOnly and Secure for "__requestverificationtoken" and .aspnet.cookies in Application_PreSendRequestHeaders in Global.asax.cs. This seems to have worked in setting these cookie attributes, but I am not sure whether this is the right way to do it. Is there a better way to setting the attributes for these cookies?
Related
I'm working with a website system in which session and remember cookies are flagged with Secure and HttpOnly. Now because of various reasons I need to access session and remember cookies in JavaScript (WebSocket Authentication with subdomain). Is it a reasonable thing to turn off the "HttpOnly" flag of both cookies regarding security?
I am aware that this opens the door for XSS attacks to get those cookies. But if I assure there is not XSS possible, do you think it is ok?
Greetings
Marvin
While the primary reason for httpOnly is XSS, there is a risk in having cookies without this flag.
The most obvious risk is that the statement that your application is not vulnerable to XSS sounds a little overly optimistic. If you have a very good reason to assume that, fine, but one reason I would think that is if the page is just all static (but why would it set cookies then). Another reason to accept this could be if XSS is an accepted risk, like for example the app is on an origin where it doesn't matter for some good reason. But these should be thought through and probably covered in a fairly detailed threat model. Any testing or scanning would (for me) be insufficient, any mitigation in the application's code I could also not accept for various reasons, if XSS really concerns me. Like for now it might really not have exploitable XSS. What about tomorrow? In 5 years, after 30 different people changed it..?
Also httpOnly is not only against XSS in its classic sense. For example you are probably using 3rd party components, javascript not controlled by you, but loaded by your application. By having httpOnly cookies, those client-side components will also not have access to cookies, but without httpOnly they will. Do you trust them that much? Maybe you should not - or maybe it's ok, it all depends on how you model threats and what you are willing to accept.
I was wondering if the SameSite flag on the session cookie was enough of a protection against CSRF attacks.
I see CSRF token solution everywhere, but I am not sure about the need to use a CSRF token if the cookie used for authentication is already protected by the SameSite flag (in Strict mode).
On top of that, if I understood it well, tho cookie would still be sent along with subdomain URLs like api.myapp.com which would be perfect for my needs.
This is somewhat opinionated, or at least depends on your target audience and risk appetite.
SameSite=strict is supported in almost all fairly recent browsers as seen here, but note the exception of IE11. Not many people use IE11 anymore, but for them it will not be good enough. Only you can answer whether that's good enough for your usecase, as of writing this, a significant amount of users would not be protected.
Also the general consensus seems to be that SameSite should only be used as defense in depth (eg. here or here in a similar question), but most of the concern is around Lax, and less about Strict. However, Strict is very user-unfriendly, in a real-world application you probably can't really use Strict, because that's very bad UX.
The usual arguments are around browser support (as above), GET requests changing state (only relevant to Lax), and some special cases still revolving around GET changing state.
So my take currently is that the reason SameSite=Strict is not good enough in general is the lack of full browser support (IE11), and a strong point against it is bad user experience. I can imagine circumstances where it is good enough. SameSite=Lax I think is only a defense in depth measure, because of the issues above, which probably don't affect your application now, but might in the future, and nobody will remember to think about SameSite settings.
Excellent answer from Gabor which explains the problem well. There is a way to solve this though, if you set up your code like an SPA, to work like this:
Requests for web content (such as navigation) do not require a cookie
The SameSite=strict cookie is only used in Ajax requests to get data
HOW IT WORKS
If your web app runs at https://mywebapp.com
Then issue the secure cookie as the result of calling an API at https://api.mywebapp.com
The cookie has a domain of .mywebapp.com and is SameSite + Cross Origin
OAUTH
For an OAuth back end for front end solution you would do this:
Host the API at https://api.mywebapp.com
When the web app receives an OAuth response, it sends the Authorization Code to the API
The API processes it, then issues a strongly encrypted cookie containing tokens
For example, I want to use a cookie with clear text username to remember the user name. For security reasons, I will also add session-id and session-token for server-side verification.
I heard that cookie has some security issues. Is it ok to use it like this? What might be potential issues?
Securing cookies is important, and this link should get you started in the right direction: Securing Cookies with HttpOnly and secure Flags
One of our clients made a penetration test on our application and reported missing flags when working with cookies.
We should always use httpOnly and secure flags when setting cookies.
After some testing I realized that cookies were actually using this flags when set, but with one exception: Log out.
When logging out some cookies were set with a past expiration date, as to delete that cookie, secure and httpOnly were not used.
Does this represent a security risk? Does it make sense to set these flags when setting an expired cookie?
No, assuming there are no holes in your app, the flag doesn't matter on the log out.
However, you should do what the pen tester says because there may be other security flaws in your app that can be exploited using this cookie if the flags aren't set. In other words, if your app were otherwise secure then the cookie wouldn't matter, however it probably does matter because there are no guarantees that your app is secure.
One example is an app that doesn't properly terminate or close sessions. A logout cookie is sent to the client without the flags, and is therefore compromised in some way such as MitM or Wire Sniffing. The attacker submits the cookie back to the app, along with any other arbitrary data designed to exploit a hole, thus triggering a vulnerability and getting a live session either by resurrecting the previous one or receiving a new one (like the famous NULL session attack).
This is a classic case of one security hole that is useless by itself, but adds a link to a chain that can be used to obtain a compromise.
Reading this blog post about HttpOnly cookies made me start thinking, is it possible for an HttpOnly cookie to be obtained through any form of XSS? Jeff mentions that it "raises the bar considerably" but makes it sound like it doesn't completely protect against XSS.
Aside from the fact that not all browser support this feature properly, how could a hacker obtain a user's cookies if they are HttpOnly?
I can't think of any way to make an HttpOnly cookie send itself to another site or be read by script, so it seems like this is a safe security feature, but I'm always amazed at how easily some people can work around many security layers.
In the environment I work in, we use IE exclusively so other browsers aren't a concern. I'm looking specifically for other ways that this could become an issue that don't rely on browser specific flaws.
First, as some others mentioned, XSS can allow other payloads, not just cookie stealing.
But, is there anyway to steal httpOnly cookies, with XSS? (ignoring the question of httpOnly support?)....
The answer is: Yes.
A subset of XSS is known as Cross-Site Tracing (XST) (or go to the original research paper). This attack has the XSS payload send an HTTP TRACE request to the web server (or proxy, forward OR reverse), which will echo back to the client the full request - INCLUDING YOUR COOKIES, httpOnly or not. The XSS payload can then parse the returned info, and retrieve those delicious cookies...
Btw, yet another "subset" (kinda) of XSS, involves injecting payload into response headers. Though similar, this isnt exactly XSS, and Header Injection can even lead to HTTP Response Splitting (HRS) - which is much more powerful, allows near complete control of other clients, cache poisoning, and of course access to cookies, if so wished.
Using HttpOnly cookies will prevent XSS attacks from getting those cookies.
Unless:
your browser does not support HttpOnly
there is a hitherto unknown vulnerability in the browser which breaks HttpOnly
the server has been compromised (but then you're probably hosed anyway).
As another poster has noted: XSS is not the only threat out there, and grabbing cookies is not the only threat from XSS. I'm sure you knew this - I'm just being complete!
Good luck!
If the browser doesn't understand HttpOnly, the attack succeeds. Edit: okay, you are not concerned. That's fine, but I will leave this notice just for reference. It is useful to state it explicitly.
Another way of stealing besides sniffing the network would be direct control of user's computer. Then the cookies can be read from a file. If it's a session cookie, it will be of course removed after browser is closed.
By the way, stealing session cookie is not the only possible "payload" of XSS attack. For example it may make your CSRF protection useless. It may alter contents of your site to deceive the user. And many other malicious things.
So better protect yourself in a good way (escape output), and think about HttpOnly as additional layer of protection.
Packet sniffing can read the cookies transmitted over http. But it may not fall under the XSS.
JavaScript can modify the HTML on the page, therefore, httpOnly does not mean you are safe against XSS.