防止CSRF的常见模式是让服务器使用随机令牌在表单中生成隐藏输入。然后，服务器希望在表单提交时看到此标记。
另一种常见模式是cookie-to-header模式。在这种情况下，令牌被放入一个cookie（没有HttpOnly），并且该令牌可以从中的两个 cookie和一个标头中获得。预计页面上的Javascript会处理此问题。此方法的一个优点是服务器不必保持状态。另一个是GET也是安全的（当然，GET无论如何都不应该改变状态）。
通常您选择其中一个，具体取决于您的网站是否为SPA。但是为什么不只是总是在cookie中发送令牌，并期望它返回 在标题和cookie中，或在表单中在饼干？前一种情况与上面的cookie-to-header方法完全相同，而后者则希望表单在客户端中填充隐藏字段（即通过javascript）。后者所需要的只是一小段JS，它可以在文档准备就绪时运行。这对于编写框架的人来说要容易得多，因为只有一个系统可以实现（并且没有状态）;使用Web框架的人更容易，因为他们不必记住为每个表单添加隐藏字段。它似乎更安全，因为GET被照顾。
是否有任何缺点（除了要求客户端运行javascript）？我认为我没有在任何地方看到过这个想法。
答案 0 :(得分：1)
首先，您很少想要保护CSRF的GET请求，因为正如您所正确指出的那样，GET不应该改变状态，因此应该是无害的。对GET请求的CSRF攻击可以通过一个简单的链接取出，如果您需要某种形式的保护，这是一个非常特殊的情况（但某些请求可能仍然存在）。
除此之外，你可以混合使用好的解决方案，这样做的风险会增加你的攻击面并增加复杂性 - 你可能愿意或不愿意接受的风险。
您必须小心彼此比较哪些参数以及您的安全基础。由服务器生成和记住并写入表单的令牌的安全性基于服务器端会话安全性，即用户不能直接读取其他用户的会话内容的事实。这是一个相当可靠的假设。 cookie-to-header方法的安全性基于以下事实：浏览器不允许攻击者的网站读取为应用程序域设置的cookie - 这是非常弱的，任意浏览器可能有错误，它可能有恶意插件/已安装扩展等。它仍然可以被接受，但风险概况不同。 实施这两种解决方案意味着从两者中承担风险。
同样在混合解决方案的情况下，存在由于实现错误（增加的复杂性）而比较错误事物的风险。例如，将cookie值与存储在服务器端会话中的值进行比较显然会否定效果，cookie也会随着攻击者网站的请求发送。