Go 1.25 引入新型 CSRF 防护机制

https://simonwillison.net/atom/everything 10月15日 15:28

../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

Go 1.25 版本在标准库中新增了 `http.CrossOriginProtection` 中间件，为防止 CSRF 攻击提供了一种无需 token 的新方法。该机制主要依赖 `Sec-Fetch-Site` HTTP 头部，其全球可用性高达94.18%。当请求源与目标源相同时（same-origin 或 none），则认为请求安全。若为跨站（cross-site）或同站（same-site）请求，则会被阻止。对于不支持 `Sec-Fetch-Site` 的浏览器，该中间件会回退至比较 `Origin` 和 `Host` 头部。此外，对于 `localhost`，即使不使用 HTTPS，也被视为安全上下文，同样能得到 `Sec-Fetch-Site` 的保护。

🛡️ Go 1.25 标准库新增 `http.CrossOriginProtection` 中间件，标志着 CSRF 防护进入新阶段。该机制旨在摆脱传统的 token 验证方式，提供更简便的解决方案。其核心是利用 `Sec-Fetch-Site` HTTP 头部来判断请求的来源，从而有效阻止 CSRF 攻击。

🌐 `Sec-Fetch-Site` 头部是该新机制的关键。该头部能够区分请求是来自同源（same-origin）、无源（none）、跨站（cross-site）还是同站（same-site）。当请求被判定为同源或无源时，即认为该请求是安全的，允许通过。反之，若为跨站或同站请求，则会被中间件拦截，从而防止恶意第三方发起未经授权的操作。

🔄 对于不支持 `Sec-Fetch-Site` 头部的老旧浏览器，Go 的新中间件提供了回退机制。它通过比对 `Origin` 和 `Host` 这两个 HTTP 头部的值来判断请求的合法性。尽管此回退方案在处理 HTTP 到 HTTPS 的跨域请求时可能存在一些边缘情况，但通过强制使用 HSTS（HTTP Strict Transport Security）可以进一步增强安全性。

💻 针对 `localhost` 环境，即使未使用 HTTPS，`Sec-Fetch-Site` 头部也能得到有效支持。Firefox 安全工程师已确认，`.localhost` 被视为安全上下文，因此即使在非 HTTPS 连接下，也能获得 `Sec-Fetch-Site` 响应，确保本地开发环境的 CSRF 防护。

A modern approach to preventing CSRF in Go (via) Alex Edwards writes about the new http.CrossOriginProtection middleware that was added to the Go standard library in version 1.25 in August and asks:

Have we finally reached the point where CSRF attacks can be prevented without relying on a token-based check (like double-submit cookies)?

It looks like the answer might be yes, which is extremely exciting. I've been tracking CSRF since I first learned about it 20 years ago in May 2005 and a cleaner solution than those janky hidden form fields would be very welcome.

The code for the new Go middleware lives in src/net/http/csrf.go. It works using the Sec-Fetch-Site HTTP header, which Can I Use shows as having 94.18% global availability - the holdouts are mainly IE11, iOS versions prior to iOS 17 (which came out in 2023 but can be installed on any phone released since 2017) and some other ancient browser versions.

If Sec-Fetch-Site is same-origin or none then the page submitting the form was either on the same origin or was navigated to directly by the user - in both cases safe from CSRF. If it's cross-site or same-site (tools.simonwillison.net and til.simonwillison.net are considered same-site but not same-origin) the submission is denied.

If that header isn't available the middleware falls back on comparing other headers: Origin - a value like https://simonwillison.net - with Host, a value like simonwillison.net. This should cover the tiny fraction of browsers that don't have the new header, though it's not clear to me if there are any weird edge-cases beyond that.

Note that this fallback comparison can't take the scheme into account since Host doesn't list that, so administrators are encouraged to use HSTS to protect against HTTP to HTTPS cross-origin requests.

On Lobste.rs I questioned if this would work for localhost, since that normally isn't served using HTTPS. Firefox security engineer Frederik Braun reassured me that *.localhost is treated as a Secure Context, so gets the Sec-Fetch-Site header despite not being served via HTTPS.

Fish AI Reader

FishAI

联系邮箱 441953276@qq.com

相关标签