引用自OWASP 的 CSRF 预防页面：

双重提交 Cookie

双重提交 cookie 被定义为针对每个表单请求以两种不同的方式发送会话 ID cookie。首先作为传统的标头值，然后再次作为隐藏的表单值。当用户访问一个站点时，该站点应该生成一个（加密性强的）伪随机值，并将其设置为用户机器上的 cookie。这通常称为会话 ID。该站点应要求每个表单提交都包含此伪随机值作为隐藏的表单值和 cookie 值。当一个 POST 请求被发送到站点时，只有当表单值和 cookie 值相同时，该请求才被认为是有效的。当攻击者代表用户提交表单时，他只能修改表单的值。根据同源策略，攻击者无法读取从服务器发送的任何数据或修改 cookie 值。这意味着虽然攻击者可以通过表单发送他想要的任何值，但攻击者将无法修改或读取存储在 cookie 中的值。由于 cookie 值和表单值必须相同，攻击者除非能够猜到会话 ID 值，否则将无法成功提交表单。

虽然这种方法可以有效降低跨站点请求伪造的风险，但在 HTTP 参数中包含经过身份验证的会话标识符可能会增加会话劫持的总体风险。架构师和开发人员必须确保没有网络设备或自定义应用程序代码或模块明确记录或以其他方式披露 HTTP POST 参数。能够访问泄露 HTTP POST 参数的存储库或通道的攻击者将能够重放令牌并执行会话劫持攻击。但是请注意，透明地记录所有 HTTP POST 参数在网络系统和 Web 应用程序中很少发生，因为这样做会暴露除会话标识符之外的重要敏感数据，包括密码、信用卡号和/或社会保险号。跨站点脚本攻击也可以利用在 HTML 中包含会话标识符来绕过 HTTPOnly 保护。大多数现代浏览器会阻止客户端脚本访问 HTTPOnly cookie。但是，如果将 HTTPOnly 会话标识符放在 HTML 中，则此保护将丢失，因为客户端脚本可以轻松遍历并从 DOM 中提取标识符。仍然鼓励开发人员实现本文所述的同步器令牌模式。

没有真正的理由不使用内置的 CSRF 预防机制，现在几乎所有严肃的框架都有这个。

不，因为您永远不应该允许脚本能够访问您的 cookie。请参阅OWASP 网站上的HTTPOnly 。

为了防止人们能够窃取会话 ID，如果存在 XSS，您应该始终设置此 cookie 标志。您的机制将不再起作用，因为它无法访问 cookie。

你可以，但对我来说似乎有点笨拙。任何 CSRF 预防机制都是这样工作的：

• 使服务器只接受满足某些条件的请求
• 确保条件是无法伪造的
• 编写您的 HTML 以便它生成的请求遵循服务器设置的条件。

久经考验的方法是<input type=hidden>在包含一些反 CSRF 令牌的 HTML 字段中使用。您的方法也可以¹，但是当整个客户端逻辑可以包含在 HTML 中时，使用 JS 拦截和注入 POST 请求听起来很恶心和不必要。

^{1 正如 TildalWave 所指出的，httponly如果您有 XSS 漏洞，将敏感数据放在非 cookie 中并使客户端 JS 可以访问可能是一个问题。然后坚持使用久经考验的方法。}

正如许多人所提到的 - 双重提交是一种好的 CSRF 保护，前提是您使用单独的随机数。在这种情况下使用 session id 是非常错误的，首先 sessionid 必须是 HTTPOnly 才能保护 XSS。

“如果这个页面/网站上有 XSS 怎么办”的论点是无效的——当你有 XSS 时，CSRF 是你最不担心的。浏览器可以通过注入的脚本完全远程控制，并且不需要 CSRF 来强制浏览器代表用户执行操作。