0

I have done quite a lot of reading in the past week over how to build a secure auth architecture. Based on my reading:

I am running a React app (SPA, non server rendered) with authentication using JWT generated on a node.js server. I place the JWT in an httpOnly cookie, secure over https, sameSite, short-ish life span for both JWT and the cookie and I have cors configured on my server to only allow my frontend domain. I also generate a csrf token server side upon loading my React app - client calls an endpoint, csrf token is sent back in the json and I set a X-CSRF-Token header with it. Since cors only allows my domain requests, and I understand that CSRF attacks originate from another domain, I understand that I can protect my CSRF token endpoint.

On a scale from 0 to 5, 0 being absolutely unsafe and 5 very safe, how safe is my architecture above to protect from a CSRF attack? If less than 5, what would you recommend I do more? Thanks,

Pere
  • 850
  • 3
  • 14
  • 34
  • 1
    How are you maintaining the CSRF value (in the JWT? Server side?). Is your JWT encrypted? If encrypted, which of the various mechanisms are you using to encrypt it? How strictly does your server enforce strong SSL/TLS? Are you regularly scanning for/testing for XSS vulnerabilities in your application? From a theoretical standpoint, what you have is sound, but often there are other factors in the implementation that affect how strong it actually is in practice. – rfestag Aug 08 '20 at 23:35
  • @rfestag Thanks! I use https://www.npmjs.com/package/csurf for the CSRF token. JWT not encryoted, good idea, I would probably use bcrypt. Server on Heroku, should research how strict they are on SSL/TLS. I am not scanning for XSS vulnerabilities, I should research on how to do that. – Pere Aug 08 '20 at 23:40
  • 1
    In that case, are you using the double-submit cookie pattern in `csurf`? If so, check this out: https://owasp.org/www-chapter-london/assets/slides/David_Johansson-Double_Defeat_of_Double-Submit_Cookie.pdf. For JWT, which npm library are you using? – rfestag Aug 08 '20 at 23:49
  • @rfestag I do not use the double-submit pattern. Is my understanding from the document you shared that it's best not to do it? Jsonwebtokens. – Pere Aug 08 '20 at 23:57
  • 1
    Like anything else, it depends. This particular attack against double-submit cookies assumes the attacker can control the cookie (via cookie fixation or XSS). If your CSRF is just sent on its own in a cookie, you'd be vulnerable. If the CSRF is a property in the JWT, that's less of a concern (since you're validating that the token came from you in the first place by checking it's signature...if they can beat that, they either can beat a common signing/encryption algorithm, or they stole the secret you use). – rfestag Aug 09 '20 at 00:04
  • @rfestag 'If the CSRF is a property in the JWT, that's less of a concern' < I think this is the way to go then! In my case, since the csrf token is sent upon loading my react app (before user logs in), I suppose I should add the token inside a jwt which, in turn, is sent via an httpOnly cookie. Upon getting the cookie server side, I then check the jwt and the csrf token inside it. Am I horribly wrong? – Pere Aug 09 '20 at 00:10
  • 1
    You can always generate a jwt token even for anonymous (guest) users. It doesn't have to be only for logged-in users. Yep, you would continue with all of the cookie protections you mentioned above. You would also send back the CSRF in your response (outside of the jwt). That is how double-submit works...the CSRF token still needs to be sent back in a header, and compared to the CSRF in the jwt. The jwt just lets you be stateless (no need to store the token server side somehow for validation) – rfestag Aug 09 '20 at 01:41
  • massive thanks to you, @rfestag, you put me on the right track! – Pere Aug 10 '20 at 22:42

0 Answers0