Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

web: Deprecate xsrf_cookies #3226

Closed
wants to merge 4 commits into from

Conversation

bdarnell
Copy link
Member

@bdarnell bdarnell commented Feb 1, 2023

This feature is more invasive than using the samesite cookie attribute
but does not provide additional protection, so it is no longer
something that we should recommend.

This feature is more invasive than using the samesite cookie attribute
but does not provide additional protection, so it is no longer
something that we should recommend.

Now that this feature is deprecated, the open issues related to it
will not be fixed (however, I intend to keep the current code around
indefinitely; there are no plans to remove it).

Closes tornadoweb#865
Closes tornadoweb#2573
Closes tornadoweb#3026
This small new functionality in a deprecated feature may provide
a higher level of security; if this turns out to be useful in practice
we may un-deprecate the xsrf_cookies feature.
@bdarnell
Copy link
Member Author

After consulting with some experts in this area, I've changed my mind about this. SameSite cookies are weaker than the current double-submit cookie implementation, primarily because a "site" as used in SameSite cookies is a broader scope than an "origin" used in the same-origin policy that is used elsewhere in the web security model. (example.com is a site, while foo.example.com and bar.example.com are two different origins within that site). If foo.example.com used only SameSite cookies for XSRF protection, it would be vulnerable to XSRF attacks from bar.example.com, if for example that host included a web application with XSS or other vulnerabilities. And even if there are no other hosts on the same site, a network-level attacker (e.g. an untrusted wifi network) could create one by manipulating DNS.

SameSite cookies might offer enough protection when combined with other techniques such as HSTS, but the combined solution is no longer simple enough that I feel comfortable recommending it as a primary defense against XSRF attacks.

So we'll be keeping xsrf_cookies around, and will in fact be improving it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant