Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
remove obsolete CSRF request token approach
AttestationServer prevents CSRF by strictly enforcing the presence of the `Origin` header set to the site's domain. Firefox fixed a long time bug with the `Origin` header a few years ago so we can rely on it being available without falling back to `Referer`. It's dramatically simpler than request tokens and doesn't require stateful sessions so it's easier to correctly protect login/register without resorting to making sessions for every user instead of only having login sessions. Our strict approach to enforcing `Origin` requires entirely avoiding the GET and HEAD methods for the web API since `Origin` isn't usually passed for those methods. For example, we fetch an image from /api/account.png as a blob and set it as the value for an img element in order to avoid depending on a GET request where the `Origin` header wouldn't normally be included. Most services wouldn't be able to rely entirely on this due to serving dynamic HTML and using GET as a RESTful verb for retrieving content. GET should still be protected from CSRF because it still often results in side effects like updating access history and opens up side channels for other web sites. As a secondary layer of protection for the subset of the APIs requiring a login session, our login session cookie has SameSite=Strict to restrict it to same site requests. We also mark the cookie with Secure, HttpOnly and Path=/. It's defined with a __Host- prefix as __Host-session to enforce that Secure and Path=/ are present which results in it being strictly same origin instead of the looser rules for SameSite=Strict where it can cross subdomains. SameSite=Strict for the login session cookie is not a full protection since it doesn't protect login and registration like the strict `Origin` header enforcement. It would be possible to make this into a full protection by adding another kind of session separate from login with another SameSite=Strict cookie but we currently don't want to do this for the same reasons we want to avoid it with request tokens. Defense in depth is no use if it ends up weakening your security by adding attack surface and we're concerned about the implications for privacy and aiding denial of service too. We also use the Fetch Metadata Request Headers feature when available to enforce that `Sec-Fetch-Mode` and `Sec-Fetch-Site` are both set to the `same-origin` value as a redundant check. These headers aren't available in Safari so we can't enforce their presence yet. We also enforce that the `Sec-Fetch-Dest` header is `none` to rule out requests coming from an img element, etc. This is not particularly useful since we only use POST for the API, but it might as well be enforced. We have entirely static HTML, CSS and JavaScript with a strict Content Security Policy enforcing Trusted Types with a `'none'` policy which means custom sanitizers are completely disallowed. Since our HTML is fully static with the enforcement by Trusted Types, we don't need to be very concerned about content injection issues. We also enforce that all of the content used in the page including scripts and styles comes from 'self' without 'unsafe-inline' or 'unsafe-eval'. We have Subresource Integrity for both scripts and styles with the aim of switching to permitting hashes rather than 'self' but this is currently blocked by Firefox and Safari being missing the standard external hash-source support for Content Security Policy and we see no reliable way to deploy it only for Chromium. Overall, we have extremely strong protections in place against CSRF and content injection. Request tokens were adding a lot of complexity and we already depending on `Origin` to fully protect the login API, since the request tokens alone would prevent creating a login session but it would be possible to update the last login time for a logged out user if we didn't have the `Origin` check.
- Loading branch information
1 parent
7c6ab45
commit 1757993
Showing
2 changed files
with
72 additions
and
97 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.