Actix-web: CSRF tokens

[fafhrd91]

Add generic api for generation and validation csrf tokens.

[Dowwie]

https://scotthelme.co.uk/csrf-is-dead/

[fafhrd91]

i am happy to close this ticket. less code is better :)

[Dowwie]

Unfortunately, it's not to ignore but to go further. :(.

[ZelphirKaltstahl]

How does samesite cookie work for a website with subdomains and various routes? Wouldn't one have to issue a new cookie for each of the routes?

[Beamed]

How should this be implemented and compatible with the current csrf middleware plugin?

Ideally, the state-less solution would be the double submit cookie approach used here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie

.. but that's very much a "batteries not included" solution, as now the developer has to pull the token from the cookie and send it with each request.

Ideally, the middleware could do the following:

1. Be created with a list of "whitelisted" resources - the initial POST request to login, for example.
2. If a request is not a "safe" request(per current guidelines), and not whitelisted, perform the double submit cookie check.

..but that's skipping the big middle step, which is how to parse out the token from the request, requiring minimal effort but complete flexibility from users :)

I'm all ears on feedback or thoughts and am looking to implement a custom version of this for my own project. The same-site cookie setting _will_ make this obsolete, if it ends up being supported more widely.

[fafhrd91]

@Beamed I don't have much experience with csrf, I can't comment much. you are welcome to take on this part of the project :)

[fafhrd91]

open for too long, i guess nobody needs this feature

[westurner]

CSRF tokens are still good practice; and arguably still necessary. I wouldn't confuse inaction on this with innecessity. (CSRF tokens also limit blind XSS exploits against sites that haven't yet implemented SameSite protections on their session cookies)

https://cwe.mitre.org/data/definitions/352.html#Potential_Mitigations

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html :

Samesite Cookie Attribute
[...]
It is important to note that this attribute should be implemented as an additional layer defense in depth concept. This attribute protects the user through the browsers supporting it, and it contains as well 2 ways to bypass it as mentioned in the following section. This attribute should not replace having a CSRF Token. Instead, it should co-exist with that token in order to protect the user in a more robust way.

re: https://scotthelme.co.uk/csrf-is-dead/ ... see https://caniuse.com/#search=SameSite for a summary of how likely it is that a user is using a SameSite-compliant browser.

[westurner]

Also, one comment at https://scotthelme.co.uk/csrf-is-dead/ references these tweets https://twitter.com/brutemorse/status/1051813133935874048 :

Disappointment of a month: browsers decide on sending SameSite cookies to a domain using "registrable domain", not actual domain. As a result, http://app.example.com and http://login.example.com are the SameSite... 1/2

So SameSite cookies is NOT sufficient defence mechanism when you have multiple subdomains with different security / risk level. E.g. an XSS on a marketing subdomain will lead to CSRF against application subdomain.

Crazy solution might be including main domain into PSL.

[fafhrd91]

anyone can contribute csrf. I just don't want to keep dead issues around