Add built-in CSRF support

[Niccolum]

Checklist

• There are no similar issues or pull requests for this yet.
• I discussed this idea on the community chat and feedback is positive.

Is your feature related to a problem? Please describe.

Add full description here
tiangolo/fastapi#4419
TL;DR according #1 I want something built-in like https://github.com/frankie567/starlette-csrf

Describe the solution you would like.

No response

Describe alternatives you considered

No response

Additional context

No response

[Kludex]

Right now, we have at least three implementations:

• https://github.com/muicss/starlette-wtf#csrf-protection
• https://github.com/simonw/asgi-csrf
• https://github.com/frankie567/starlette-csrf

@frankie567 @simonw @tomchristie opinions on this?

At least a note in the documentation is worth it.

[tomchristie]

A good first pass would be to make sure we've got these listed in the third party packages... https://www.starlette.io/third-party-packages/

I'd probably suggest that we don't want to add anything to the core project at the moment. (One of it's motivations has been to try to encourage a thriving ASGI ecosystem.) Perhaps further along in it's lifespan we could reconsider.

[JimDabell]

Is this really worth doing? CSRF attacks are stopped by same-site cookies, supported by all mainstream browsers for years and the default in most cases too. Almost everybody should be skipping CSRF solutions like this in favour of securing their cookies.

• Cross-Site Request Forgery is dead!
• CSRF is (really) dead

[simonw]

I still care about CSRF for two reasons:

1. The subdomain issue. SameSite=Lax still allows form submissions from subdomains of your primary domain to carry their cookies. This is concerning because it's very common for subdomains to be used for externally hosted software - pointing blog.x.com at a hosted Wordpress instance for example - and that means that an XSS hole in a third party application hosted on a subdomain could be used to conduct CSRF attacks against the primary domain.
2. Login CSRF. This is an obscure but nasty attack where an attacker can force a user to sign in using an account that they control.

I wrote a bunch of notes about these two issues here: https://simonwillison.net/2021/Aug/3/samesite/

[tomchristie]

Those are all useful resources. I suppose a good outcome would be for us to provide a little more info in the docs to help folks determine a good approach here. I'd certainly not appreciated the ways in which CSRF might not be needed by modern browsers, so that's news to me.

That could either be in the form of some text in our "third party packages" docs. Or it could be in making sure that (say) the asgi-csrf project has some good context in it's README.

Not sure.

[JimDabell]

Thanks for the extra info @simonw. It seems like checking Origin resolves both, right?

[gnat]

Solution to consider: Just have 2 cookies. 1 Lax, 1 Strict.

• If Lax cookie is present, user is "logged in".
• If Strict cookie is present, user can perform state-changing actions.

I think this may completely remove the need for a CSRF token middleware.

Very insightful discussion @simonw @JimDabell @tomchristie

[gnat]

If I'm not mistaken the middleware for the above would simply be this, alongside SessionMiddleware using samesite='lax'

from starlette.middleware.base import BaseHTTPMiddleware

# Check "request.state.strict" if user is performing a state-changing action.
class CSRFMiddleware(BaseHTTPMiddleware):
    request.state.strict = request.cookies.get('strict', None)
    response = await call_next(request)
    if not request.state.strict:
        response.set_cookie('strict', 'hello', (24 * 60 * 60), path='/', samesite='strict')
    return response

No need to add CSRF tokens to request headers or forms or templates. When you need strict security, just check "strict"...