0

Lets suppose I have a web application that uses JWT tokens and CSRF Tokens in its authentication scheme. As I understand it, it works like this:

  1. When a user logs in, the client sends a login request.
  2. Server sets a signed JWT token as a cookie with Set-Cookie ... ;Secure ;httpOnly in its response header. This prevents XSS attacks since the cookie cannot be accessed by Javascript.
  3. Server also sends a CSRF token without httpOnly set so that it can be read by JavaScript code.
  4. When the client makes any future requests, the JWT cookie will automatically be sent and the CSRF will have to be set in the request header. This should prevent CSRF attacks since the CSRF cookie will have to be read.

So in short we have:

  • Setting the JWT token with ;Secure;HttpOnly will prevent XSS attacks.

  • Making the client set the CSRF cookie in the request header will prevent CSRF attacks.

But what if an attacker gets your CSRF token using XSS and sets it as a header for requests sent by a malicious website with a CSRF exploit. Is this attack possible? If so, how could I improve my authentication scheme?

Thanks in advance.

  • The CSRF value is normally in a hidden field and the token set to HTTPOnly – McMatty Nov 29 '18 at 23:38
2

CSRF will have to be set in the request header.

The anti-CSRF-token will be submitted in the request message body. If there is a XSS-vulnerability and an attacker manages to exploit it, the last thing he will probably care about is the anti-CSRF-token. XSS is a much more powerful attack, and an attacker can manipulate almost anything with XSS.

Also, the anti-CSRF-token is stored in a hidden form field in the html-code.

It exists so that each request is bound to a specific user-session. It literally exists to make CSRF impossible, even if the token somehow leaks. An attacker would only be able to manipulate the current, active session of that particular user whom he stole the anti-CSRF token from.

But what if an attacker gets your CSRF token using XSS and sets it as a header for requests sent by a malicious website with a CSRF exploit. Is this attack possible?

The JWT would still be protected. I suggest you should read up on how CSRF works: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

  • Ideally, the anti-CSRF-token should not be stored in cookies at all. Only in the html-form. – Martin Fürholz Nov 30 '18 at 10:43
  • "An attacker would only be able to manipulate the current, active session of that particular user whom he stole the anti-CSRF token from". Yes I understand it would have to be that particular user's session whos anti-csrf token was stolen, however, that means the attacker could potentially hijack that particular session right? I know the chances of this happening is very low, but it is still a vulnerability. – EJC Nov 30 '18 at 15:23
  • Also, what's the difference between putting the anti-csrf in the hidden form field vs cookie and then copying to header on every request? I ask because the application I'm building is an SPA and it seems easier just to do the cookie -> request header way. – EJC Nov 30 '18 at 15:26
  • @EJC Your application should not put the anti-CSRF token into the cookies. The way CSRF tokens work is: the server outputs it directly into the html (hidden form field) in every response which has a form. How would an attacker hijack a session if he doesn't have access to the JWT? The JWT is for authentication. The anti-CSRF-token is only for CSRF-protection. – Martin Fürholz Nov 30 '18 at 16:25
  • Well with a CSRF attack you don't need access to the JWT, it is stored in the browser and its automatically sent with the request. This, in combination with getting the anti-csrf token with XSS, should be enough to hijack the session. – EJC Nov 30 '18 at 22:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.