4 ms·

Close Look at CSRF Tokens

65 points by lobo_tuerto 6y ago

mac-chaffee 6y ago
I've found that a key part of CSRF protection is ensuring it gets added everywhere consistently. When new features need to be done yesterday and you have to review code from 20+ junior developers, it's easy to miss that extra hidden <input> field. That's why I love if it's built into the framework like Django or Phoenix rather than bolted on or home-rolled.
- silviogutierrez 6y ago
  Big Django user. Isn't it still required that you add the {% csrf_token %} tag to your forms? That is, the protection will be on. But the way to be allowed in by the gate is not on by default. You have to remember to add the tag. Which is why I'm so excited to just switch to SameSite once there's enough browser usage...
  - mac-chaffee 6y ago
    My Django is a little rusty but I think now requests will return 403s by default if you forget to include the csrf_token tag: https://docs.djangoproject.com/en/3.0/ref/csrf/#rejected-requests https://docs.djangoproject.com/en/3.0/ref/csrf/#rejected-req... Whereas the hand-rolled CSRF scheme I've inherited will fail silently
    - silviogutierrez 6y ago
      That's what I mean. If you forget to include the token on your app, it will fail. You have to remember to call {% csrf_token %} in every template. Back in the day, the middleware scanned your response and injected it next to each </form> tag. A hack and dirty for sure, but removed that burden.
      - StavrosK 6y ago
        It will fail securely, which is what you want. The alternative is to have it fail insecurely and bypass validation for everything. In the latest versions the framework sets the SameSite header properly, so you don't need the CSRF middleware at all (you can just remove it).
- viraptor 6y ago
  What do you mean by built-into? The choice of whether to include a token in a form or not is not always trivial for static analysis tools. On the other hand, if you use some library to handle forms and validation like deform and colander, the CSRF handling is pretty transparent. Also, but validating CSRF on middleware level, you can't forget about it - features relying on POST requests won't work.
tebruno99 6y ago
What I don't understand is why store it server side? If we make a HTTP Only + secure cookie containing the encrypted and signed csrf value, it can't be obtained by an attacker & the server would require no state or shared cache between instances. It would just compare the HTTP only cookie to the value submitted with the form. On response, expire that cookie. Does anyone know of a downside to that?
- bluepnume 6y ago
  Yup. This is known as 'double submit'. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
  - tebruno99 6y ago
    Ah! Thanks, I've been looking for the exact definition!
technics256 6y ago
I still can't seem to get good informantion if this should be common usage on something like React SPAs for things like signup forms and other forms publicly POSTing data?
- byteshock 6y ago
  The article below seems to suggest that as long as your api is on a subdomain and is using CORS headers, you should be fine. However I’m not so sure about this, as I still implement CSRF tokens in my SPAs. (Bit of a habit from my php days) I store the tokens in local storage and pass them through the request headers. A lot of people have different ideas and methods when it comes to CSRF protection on SPAs. I’d love to hear other people’s opinion and tactics! Feel free to correct me on anything. Article: https://medium.com/tresorit-engineering/modern-csrf-mitigation-in-single-page-applications-695bcb538eec https://medium.com/tresorit-engineering/modern-csrf-mitigati...
Lx1oG-AWb6h_ZG0 6y ago
Is any of this actually needed anymore? Setting the SameSite attribute on the cookie will ensure the browser will not send it for cross-site requests, so... problem solved?
- StavrosK 6y ago
  CSRF protection isn't needed after SameSite, nope.
chrismorgan 6y ago
Related: • Cross-Site Request Forgery is dead! (2017): https://scotthelme.co.uk/csrf-is-dead/ https://scotthelme.co.uk/csrf-is-dead/ • CSRF is (really) dead (2019): https://scotthelme.co.uk/csrf-is-really-dead/ https://scotthelme.co.uk/csrf-is-really-dead/ If your use of CSRF tokens is purely for preventing cross-site request forgery (and not things like form expiry or double-submit protection, which are commonly paired with it, for better or for worse) then CSRF tokens are genuinely obsolete and unnecessary, and you should set your SameSite attribute on your cookies to ensure you’re protected against CSRF in the most browsers (meaning all browsers from at least the last couple of years—including IE11 updated within that time, by the way—rather than probably just Chrome at present).
- sdepablos 6y ago
  Unfortunately there's still iframes, that don't play well with SameSite
- nmadden 6y ago
  This isn't true. Although SameSite is a good defence in depth, it provides no protection against CSRF from sub-domains (subdomain hijacking is fairly common), or in older browsers. It also is incompatible with some site features - e.g. OIDC form_post response mode, SAML SLO with HTTP POST binding, etc.
  - chrismorgan 6y ago
    Subdomain hijacking is only possible if you’ve allowed subdomains to be used for such other things, which I strongly assert is rare. Older browsers: all browser releases from the last couple of years support it (including IE11); browsers from before then should not be being used on the public internet under any circumstances. It should be a negligible fraction of your user base that uses such browsers, and so long as you’re also happy to break IE11, a safe path (from a security perspective) is to actively break the site for old browsers by blacklisting them or checking for support of a comparatively recent feature. (Just don’t do a whitelist by user agent string, that approach is unmitigatably bad.) You’re correct about some auth systems not playing nicely with strict same-site cookies, because they’ve been designed with certain assumptions in mind. I’m not particularly conversant with that space, never having had to interact with such a system.
globular-toast 6y ago
Reverse engineering seems an odd way to learn about this when good documentation is available, e.g. https://docs.djangoproject.com/en/3.0/ref/csrf/ https://docs.djangoproject.com/en/3.0/ref/csrf/
- tebruno99 6y ago
  Docs are a great way to overview. You never know what the actual implementation is doing and I find that having actual hands on experience helps me solidify the knowledge into relatable experience. If you don't care why, read the docs. If you want to understand HOW, read the code.

65 points by lobo_tuerto 6y ago

I've found that a key part of CSRF protection is ensuring it gets added everywhere consistently. When new features need to be done yesterday and you have to review code from 20+ junior developers, it's easy to miss that extra hidden <input> field. That's why I love if it's built into the framework like Django or Phoenix rather than bolted on or home-rolled.

silviogutierrez 6y ago
Big Django user. Isn't it still required that you add the {% csrf_token %} tag to your forms? That is, the protection will be on. But the way to be allowed in by the gate is not on by default. You have to remember to add the tag. Which is why I'm so excited to just switch to SameSite once there's enough browser usage...
- mac-chaffee 6y ago
  My Django is a little rusty but I think now requests will return 403s by default if you forget to include the csrf_token tag: https://docs.djangoproject.com/en/3.0/ref/csrf/#rejected-requests https://docs.djangoproject.com/en/3.0/ref/csrf/#rejected-req... Whereas the hand-rolled CSRF scheme I've inherited will fail silently
  - silviogutierrez 6y ago
    That's what I mean. If you forget to include the token on your app, it will fail. You have to remember to call {% csrf_token %} in every template. Back in the day, the middleware scanned your response and injected it next to each </form> tag. A hack and dirty for sure, but removed that burden.
    - StavrosK 6y ago
      It will fail securely, which is what you want. The alternative is to have it fail insecurely and bypass validation for everything. In the latest versions the framework sets the SameSite header properly, so you don't need the CSRF middleware at all (you can just remove it).
viraptor 6y ago
What do you mean by built-into? The choice of whether to include a token in a form or not is not always trivial for static analysis tools. On the other hand, if you use some library to handle forms and validation like deform and colander, the CSRF handling is pretty transparent. Also, but validating CSRF on middleware level, you can't forget about it - features relying on POST requests won't work.

tebruno99 6y ago

What I don't understand is why store it server side? If we make a HTTP Only + secure cookie containing the encrypted and signed csrf value, it can't be obtained by an attacker & the server would require no state or shared cache between instances. It would just compare the HTTP only cookie to the value submitted with the form. On response, expire that cookie. Does anyone know of a downside to that?

bluepnume 6y ago
Yup. This is known as 'double submit'. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
- tebruno99 6y ago
  Ah! Thanks, I've been looking for the exact definition!

technics256 6y ago

I still can't seem to get good informantion if this should be common usage on something like React SPAs for things like signup forms and other forms publicly POSTing data?

byteshock 6y ago
The article below seems to suggest that as long as your api is on a subdomain and is using CORS headers, you should be fine. However I’m not so sure about this, as I still implement CSRF tokens in my SPAs. (Bit of a habit from my php days) I store the tokens in local storage and pass them through the request headers. A lot of people have different ideas and methods when it comes to CSRF protection on SPAs. I’d love to hear other people’s opinion and tactics! Feel free to correct me on anything. Article: https://medium.com/tresorit-engineering/modern-csrf-mitigation-in-single-page-applications-695bcb538eec https://medium.com/tresorit-engineering/modern-csrf-mitigati...

Lx1oG-AWb6h_ZG0 6y ago

Is any of this actually needed anymore? Setting the SameSite attribute on the cookie will ensure the browser will not send it for cross-site requests, so... problem solved?

StavrosK 6y ago
CSRF protection isn't needed after SameSite, nope.

chrismorgan 6y ago

Related: • Cross-Site Request Forgery is dead! (2017): https://scotthelme.co.uk/csrf-is-dead/ https://scotthelme.co.uk/csrf-is-dead/ • CSRF is (really) dead (2019): https://scotthelme.co.uk/csrf-is-really-dead/ https://scotthelme.co.uk/csrf-is-really-dead/ If your use of CSRF tokens is purely for preventing cross-site request forgery (and not things like form expiry or double-submit protection, which are commonly paired with it, for better or for worse) then CSRF tokens are genuinely obsolete and unnecessary, and you should set your SameSite attribute on your cookies to ensure you’re protected against CSRF in the most browsers (meaning all browsers from at least the last couple of years—including IE11 updated within that time, by the way—rather than probably just Chrome at present).

sdepablos 6y ago
Unfortunately there's still iframes, that don't play well with SameSite
nmadden 6y ago
This isn't true. Although SameSite is a good defence in depth, it provides no protection against CSRF from sub-domains (subdomain hijacking is fairly common), or in older browsers. It also is incompatible with some site features - e.g. OIDC form_post response mode, SAML SLO with HTTP POST binding, etc.
- chrismorgan 6y ago
  Subdomain hijacking is only possible if you’ve allowed subdomains to be used for such other things, which I strongly assert is rare. Older browsers: all browser releases from the last couple of years support it (including IE11); browsers from before then should not be being used on the public internet under any circumstances. It should be a negligible fraction of your user base that uses such browsers, and so long as you’re also happy to break IE11, a safe path (from a security perspective) is to actively break the site for old browsers by blacklisting them or checking for support of a comparatively recent feature. (Just don’t do a whitelist by user agent string, that approach is unmitigatably bad.) You’re correct about some auth systems not playing nicely with strict same-site cookies, because they’ve been designed with certain assumptions in mind. I’m not particularly conversant with that space, never having had to interact with such a system.

globular-toast 6y ago

Reverse engineering seems an odd way to learn about this when good documentation is available, e.g. https://docs.djangoproject.com/en/3.0/ref/csrf/ https://docs.djangoproject.com/en/3.0/ref/csrf/

tebruno99 6y ago
Docs are a great way to overview. You never know what the actual implementation is doing and I find that having actual hands on experience helps me solidify the knowledge into relatable experience. If you don't care why, read the docs. If you want to understand HOW, read the code.