无需令牌或隐藏表单字段的CSRF保护
内容提要
几个月前，我为Microdot框架添加了CSRF保护，最初计划使用传统的反CSRF令牌，但发现基于Sec-Fetch-Site头的方法更简单有效。虽然旧浏览器兼容性存在问题，我选择使用Origin头作为备选方案。最终实现符合Microdot的简约理念，并期待OWASP将此方法推广为主流解决方案。
关键要点
-
几个月前，作者为Microdot框架添加CSRF保护，最初计划使用传统的反CSRF令牌。
-
作者发现基于Sec-Fetch-Site头的方法更简单有效，决定采用这种新方法。
-
作为Microdot的唯一维护者，作者选择自己编写CSRF保护代码，因为没有现成的解决方案可用。
-
OWASP的CSRF预防备忘单仍然推荐使用反CSRF令牌，作者开始实现这一方案。
-
在研究过程中，作者发现了基于Sec-Fetch-Site头的现代CSRF保护方法，该方法在2023年后得到大多数现代浏览器的支持。
-
Sec-Fetch-Site头的值可以指示请求的来源，服务器可以拒绝cross-site的请求以防止CSRF攻击。
-
作者在Microdot中添加了allow_subdomains参数，以处理同一注册域下的子域请求。
-
考虑到旧浏览器的兼容性，作者决定在Sec-Fetch-Site头不可用时使用Origin头作为备选方案。
-
使用Origin头时，作者选择让用户显式配置预期的来源名称，以简化实现。
-
OWASP在12月更新了CSRF预防备忘单，包含Sec-Fetch-Site头作为防御机制，但仍未被视为完整解决方案。
-
作者认为Microdot从没有CSRF支持到实现现代保护方法是一个重要进步，并将关注OWASP的进一步更新。
延伸问答
Microdot框架是如何实现CSRF保护的？
Microdot框架通过使用Sec-Fetch-Site头来实现CSRF保护，服务器可以根据该头的值拒绝跨站请求。
Sec-Fetch-Site头的作用是什么？
Sec-Fetch-Site头指示请求的来源，服务器可以根据其值判断请求是否来自同一来源，从而防止CSRF攻击。
为什么选择Sec-Fetch-Site头而不是传统的反CSRF令牌？
Sec-Fetch-Site头的方法更简单有效，且在现代浏览器中得到广泛支持，减少了实现复杂性。
Microdot如何处理子域请求的CSRF保护？
Microdot添加了allow_subdomains参数，默认情况下拒绝来自子域的请求，以增强安全性。
如果用户使用旧浏览器，Microdot会如何处理CSRF保护？
如果Sec-Fetch-Site头不可用，Microdot会使用Origin头作为备选方案来处理请求。
OWASP对CSRF保护的建议是什么？
OWASP建议使用反CSRF令牌作为最佳保护方法，但最近更新中也提到了Sec-Fetch-Site头作为防御机制。
