For a React project, I'm trying to implement some auth solution. The following are what I'm considering.
Session Cookies are random tokens saved in HTTP only cookies sent by
the server. They are vulnerable against CSRF attacks. To protect
against, CSRF attacks, send a unique identifier with every HTTP
request. XSS protection is still required.
Session JWT are random signed tokens sent by the server. They are
vulnerable against XSS attacks. No CSRF protection is necessary.
Based off that, I decided to implement a Session JWT due to it being a random token, only need to focus on XSS protection, and session management abilities. In fact, I don't see the point of http only session cookies since an XSS attack can act via the user's browser. Preventing cookie access is barely counted as protection since an XSS attack can fool the user into providing credentials.
However, the more I research into this topic, the more confused I become. I keep getting conflicted info like JWTs being compared to Sessions instead of Cookies, no Session JWT implementations, and comments that state Session Cookies protect against XSS attacks.
Am I misunderstanding Session, Cookies, and/or JWT based off my prior descriptions?
Related
There are many similar questions here on SO asking about this, but couldn't find one that would address my concerns about using HttpOnly cookies.
There are many answers that suggest using HttpOnly cookies reasoning that an XSS vulnerability on the site would allow an attacker to steal the JWT (or any auth) tokens from the LocalStorage, and this could be prevented by storing the token as a HttpOnly cookie.
I understand that, it kind of makes sense. An attacker with access to a user's auth token can impersonate that user on the targeted website.
However, if a website has an XSS vulnerability then the attacker can already do anything as the user without actually stealing the cookies. It can make requests to the site, steal user data, or perform restricted actions.
Is there anything an attacker can do with a stolen auth token that is not possible on the site as an XSS?
Given the above, is there a reason to prefer using cookies over the LocalStorage to store auth tokens?
(LocalStorage vs SessionStorage is a separate concern, I'm not necessarily interested in that comparison.)
In other words, is it dangerous to have a JWT, which doesn't contain any sensitive info, in a cookie without the httponly flag? I understand the main security concern is XSS attacks. So since Javascript can access the cookie, attackers can potentially access the token. But since there isn't any sensitive info in the JWT, is the only harm session hijacking?
The crux of the issue is that I would like the JWT to be in a Javascript-accessible cookie because I want to be able to access the token claims to limit the functionality of the user within the ui.
So is it a better idea to use a non-httponly cookie for the JWT, or make the JWT in a httponly cookie and just do a separate non-httponly cookie for storing the user's credentials?
Although the JWT does not contain any sensitive information, the token itself is sensitive. JWTs are usually used as bearer tokens, which means they are a (possibly time limited) credential that can be used by anyone in possession of the token to access whatever resources the token is issued for.
An attacker who was able to obtain the token via a successful XSS would therefore be able to impersonate the victim to make requests to your server. This is what you describe as "only" session hijacking. I'm not sure why you say "only". Usually session hijacking is pretty serious ;o)
A more secure approach in my opinion, as you say, to make the JWT cookie HTTP-Only and have a separate cookie containing the information used to limit the functionality in the UI.
As an aside, limiting the UI in this way should not be considered as an effective security measure on it's own, since it would almost certainly be possible to bypass the UI restrictions unless they were also enforced on the server side. It is fine to use it for personalisation of the UI though.
I'm attempting write an authentication system for a node.js api using express. I've noticed that if I am going to use a JWT for authentication tokens, I have two options...
1.) Store the token in a cookie, and add CSRF protection.
2.) Have the client send the token in the Auth Header and add XSS protection.
My question is, is there any benefit to storing the auth token in a cookie, and having the client send it in the Auth Header for authentication? This way if for some reason the CSRF protection fell through, the request would fail if there was no authentication token in the header. Also, if XSS protection fell through, the request would still require the auth token in a cookie. I guess my thought is that this would provide more protection, and the only way it could fail is through a successful XSS attack followed by a successful CSRF attack.
Follow up question: Are CSRF tokens a full proof protection technique against CSRF attacks?
Firstly I recommend that you go through this answer first. I hope I've bern able to address your queries about CSRF and XSS here and why and how we should use cookie.
Secondly, your approach of using localstorage along with cookie is good. The only problem I see is localstorage cannot be used across sub domains. If you use cookie and set the cookie domain as example.com (replace example with your organization domain), it will be valid across all sub domains. Thus a user authenticated by your authorization server can seamlessly login to app1.example.com and app2.example.com. You won't be able to do this with localstorage.
A lot has been written about the secure way of storing tokens in typical single page applications (cookies vs. local storage) and using cookies is often presented as the better option. [1] [2] [3]
The reason is that storing sesssion data in local storage is susceptible to XSS attacks. Cookies have CSRF problem but from the texts it seems it shouldn't be a problem to implement a CSRF protection.
However I can't imagine CSRF protection of REST API for an SPA which would not be vulnerable to XSS (unless we are talking about reauthentication and CAPTCHAs) and even OWASP mentions in CSRF Prevention Cheat Sheet:
...any cross-site scripting vulnerability can be used to defeat all CSRF mitigation techniques available in the market today (except mitigation techniques that involve user interaction...
So if cookies don't have XSS problem but do have CSRF problem but CSRF is useless if XSS is present why are they considered better option ? In the case this is not true, what would be the CSRF protection immune to XSS ?
Saying that storing the auth token in an httpOnly cookie is "immune" to xss only means that the token itself cannot be accessed via xss. In no way does it mean that the application may not be vulnerable.
If the application is vulnerable to XSS (which it still can be ofc), anything can be accessed on the client, including the csrf token, or any data shown or processed in the client. Only the login/auth token in the httpOnly cookie is inaccessible, which means the attacker can't at least steal the session. But that's far from being safe from xss.
I've been reading that "remember me" cookies are stored in "httpOnly" cookies, so they are not accessible by JavaScript/XSS. However, "httpOnly" cookies are vulnerable to CSRF attacks because they are sent with the request automatically.
To mitigate the CSRF attack, it is recommended to use the synchronized tokens pattern (have the server generate csrf tokens and crosscheck with the client) .
My question is, if a "remember me" cookie is available, is it possible for a CSRF attack (malicious JavaScript) to make a request and subsequently obtain the csrf token generated from the server? The concern is, if an attack has the cookie as well the token to send with requests, then the security of the app has been compromised.
If this is indeed possible, how could we prevent this?
No, the token cannot be read by another domain due to the Same Origin Policy.
If the request is made server-side to bypass the SOP, then the server isn't getting the token from the victim's browsing context therefore this cannot attack the logged in user (the server could only attack their own user that they used to get the token with).
Therefore, nothing to worry about (as long as you haven't enabled CORS of course).