21

Context: Angular site is hosted on S3 behind CloudFront, separate from Express server that is used as API and almost all requests are XMLHttpRequests. All requests are sent without cookies (withCredentials = false by default) and I use JWT Bearer token for authentication by taking it from cookies in angular and placing to Authorization header (This technique is kind of what is described in CSRF Wiki page).

On Express site I do not allow Cookie header in Access-Control-Allow-Headers.

Cookies have secure: true flag, and are NOT httpOnly because I need to manually access them in angular.

Also I've read in this Medium article that JSON-Web-Tokens(JWT )/Bearer Tokens

is without a doubt one of the best methods of preventing CSRF

Question 1: Will I add extra security if I'll add X-XSRF-Token header to each request and for example make the mechanism stateless by checking for that same value in JWT payload? (I'we read about it in this thread)

Question 2: Do I actually need extra security efforts agains CSRF taking all that I described?

13

This is relevant but doesn't necessarily answer 100% of your question:

https://security.stackexchange.com/a/166798/149676

The short of it is that as long as authentication isn't automatic (typically provided by the browser) then you don't have to worry about CSRF protection. If your application is attaching the credentials via an Authorization header then the browser can't automatically authenticate the requests, and CSRF isn't possible. Therefore, I would re-word the quote from your article slightly: it isn't that Bearer Tokens are the best defense against CSRF attacks, but simply that CSRF is an attack vector that specifically attacks requests where the browser automatically provides authentication (typically cookies and basic authentication), and so CSRF doesn't matter if the browser can't authenticate you.

You should probably make sure and verify, server-side, that your application isn't silently falling back to cookie validation if the Bearer token is absent. I could see something like that squeaking into an application on accident, and since the cookies will get sent along whether you want them to or not, it could result in an inadvertent CSRF vulnerability on a page that is was "supposed" to be immune to CSRF.

As a result, I think both your questions one and two can be answered at the same way. If you only use authentication via Bearer tokens and not via cookies, then there is no concern of CSRF vulnerability, and no extra steps are required for security.

  • 1
    It's Incorrect to say that "as long as authentication happens in the header and not by cookies that you don't have to worry about csrf-protection." Basic auth happens by headers and is vulnerable to csrf. Similarly, digest authentication, ntlm, negotiate and certificate auth can all be vulnerable to crsf. CSRF must be mitigated whenever the browser automatically sends the authentication, because then a malicious third-party can simply issue a request to the server from the user's browser and the browser will automatically send the credentials so the server can't distinguish without "help". – Nathan Jan 6 at 18:48
  • @Nathan The answer I linked to mentioned exactly your point and some of those exceptions (in fact I mentioned Basic authentication as an exception in my answer). I didn't mean to imply "header auth = secure" but rather "if you are setting headers to provide auth then you are secure". Yes, there are some header-based authentication systems that a browser (or authentication server) will automatically provide, and then you have to worry about CSRF. – Conor Mancone Jan 6 at 19:01
11

Generally, CSRF happens when a browser automatically adds headers (i.e: Session ID within a Cookie), and then made the session authenticated. Bearer tokens, or other HTTP header based tokens that need to be added manually, would prevent you from CSRF.

Of course, but sort of off-topic, if you have a XSS vulnerability, an attacker could still access these tokens, but then it doesn't become a CSRF bug.

2

Previous answers are rock solid. I'll jump in here to provide a more context and little caveat. There are lots of ways to using JWT; session management is one of them. Although it presents a few drawbacks when dealing with timeouts and advanced requirements like re-authentication.

Also, I've seen JWT placed in Cookies. As other's have stated, CSRF protection doesn't come from using a JWT itself. It comes from submitting it as an Authorization header, using the Bearer [JWT] scheme.

Question 1: Will I add extra security if I'll add X-XSRF-Token header to each request and for example make the mechanism stateless by checking for that same value in JWT payload? (I've read about it in this thread)

If you are submitting it via XHR as an Authorization header, then no the extra X-XSRF-Token header will not add "extra" security.

Question 2: Do I need extra security efforts against CSRF taking all that I described?

Nope, your current setup is okay.

A while back, I compiled a web authentication techniques guide and their security properties (it also has a JWT part). Here is the final cheat sheet describing all methods in a compact form.

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.