web: New XSRF/CSRF protection: `Sec-Fetch-Site`

[bdarnell]

Since 2023, major browsers have offered a new protection from XSRF: the Sec-Fetch-Site header. This is much simpler to use than the invasive xsrf_cookies feature currently offered by tornado, while simultaneously offering stronger protection. See golang/go#73626 for an in-depth discussion of this feature. Also see #3226, in which we previously considered (and rejected) XSRF protection based on the SameSite cookie feature instead.

It is possible for applications to use this header today, such as by checking it in the prepare method:

    def prepare(self):
        if (self.request.method not in ("GET", "HEAD", "OPTIONS") and
            "Sec-Fetch-Site" in self.request.headers and
            self.request.headers["Sec-Fetch-Site"] not in ("same-origin", "none")):
            raise HTTPError(403)

We should make this available in Tornado itself so it is more easily usable and can potentially be turned on by default.

Open questions:

• Should it be the default? Probably not immediately but perhaps in Tornado 7.0
• How is it enabled or disabled? A new flag in Application like xsrf_cookies or something else? (Consider that it may need to be overridden on a per handler basis)
• Where does the check live? In web.py like the current one, or somewhere deeper in the HTTP stack? (perhaps a middleware at the HTTPMessageDelegate level?)
• Do we want a fallback like the Origin==Host check proposed in net/http: add CrossOriginForgeryHandler golang/go#73626?

[takluyver]

I have had a go at this in #3576.

[bdarnell]

Thanks for the PR, @takluyver. Let's work out the design issues on this thread. Filippo Valsorda has an extensive post on this topic and I'd like to follow the algorithm at the end of the post, which is implemented in the go standard library (but not turned on by default at this time). Briefly restating the algorithm here:

1. GET, HEAD, and OPTIONS are always allowed
2. The Origin header is compared to a configurable allow-list, and the request is accepted on a match.
3. Sec-fetch-site header with value same-origin or none is allowed. Any other value in sec-fetch-site is rejected. If sec-fetch-site header is not present, continue to the next step
4. Requests with neither sec-fetch-site nor Origin headers are always allowed (these are either non-browser clients or very old browsers)
5. If Origin and Host match (including the port), allow it. Otherwise reject.

So we need an enable/disable flag for this behavior, as well as an optional way to specify a set of allowed Origins (is this just a separate option or is there some way to combine it with the hosts that appear in the routing layer, or to use it as a restriction on valid Host headers when the routing layer just has the default .*?). There should be some way to change these options on a per-handler basis. I think I'd use the same pattern as get_login_url here (This also implies that the implementation work similarly to the current xsrf checks, rather than being an HTTPMessageDelegate or something like that).