CSRF protection

[simonw]

This is surprisingly missing from Starlette.

[simonw]

CSRF is mentioned in the first Starlette issue about middleware but I don't think anyone has built it yet: encode/starlette#1

The WTForms library has CSRF protection and can be used with Starlette: https://wtforms.readthedocs.io/en/stable/csrf.html

[simonw]

It looks to me like the ASGI ecosystem as a whole is missing CSRF protection. I'm going to experiment with ASGI middleware and see if I can come up with something reusable.

[simonw]

https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet is useful here. Looks like token-based is still the most recommended mitigation.

[simonw]

This section is particularly interesting:

https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet#double-submit-cookie

It points out that if an attacker can hijack a subdomain (with XSS or by intercepting insecure traffic) they could force-set a cookie, which means they could control the csrftoken cookie to be something that they already know.

While it’s true that hellokitty.marketing.example.com cannot read cookies or access the DOM from secure.example.com because of the same origin policy, hellokitty.marketing.example.com can write cookies to the parent domain (example.com), and these cookies are then consumed by secure.example.com (secure.example.com has no good way to distinguish which site set the cookie).

HTTPS-only cookies seems like a good mitigation for this one.

[simonw]

Urgh, HTTPS-only cookies don't protect against this case though:

b) If an attacker is in the middle, they can usually force a request to the same domain over HTTP. If an application is hosted at https://secure.example.com, even if the cookies are set with the secure flag, a man in the middle can force connections to http://secure.example.com and set (overwrite) any arbitrary cookies (even though the secure flag prevents the attacker from reading those cookies). Even if the HSTS header is set on the server and the browser visiting the site supports HSTS (this would prevent a man in the middle from forcing plaintext HTTP requests) unless the HSTS header is set in a way that includes all subdomains, a man in the middle can simply force a request to a separate subdomain and overwrite cookies similar to 1. In other words, as long as http://hellokitty.marketing.example.com doesn’t force https, then an attacker can overwrite cookies on any example.com subdomain.”

[simonw]

Using itsdangerous and setting a signed cookie against a secret can address this problem.

[simonw]

This is happening in https://github.com/simonw/asgi-csrf now.