CSRF 和 cookie 到表单的方法

Question

防止 CSRF 的常见模式是让服务器生成带有随机标记的表单中的隐藏输入。然后服务器期望在表单提交时看到这个令牌。

另一个常见的模式是cookie-to-header 模式。在这种情况下，令牌被放在一个 cookie 中（没有HttpOnly），并且该令牌预计会出现在 cookie 和标头中的未来请求中。页面上的 Javascript 有望处理此问题。这种方法的一个优点是服务器不必保持状态。另一个是 GET 也是安全的（当然，GET 无论如何都不应该改变状态）。

您通常根据您的网站是否为 SPA 来选择其中一个。但是为什么不只是 always 在 cookie 中发送令牌，并期望它返回 either 在 header 和 cookie 中，or 在表单中在饼干里？前一种情况与上面的 cookie-to-header 方法完全相同，而后者则希望表单在客户端中填充隐藏字段（即通过 javascript）。后者只需要一点 JS 的 sn-p 即可在文档就绪时运行。这对于编写框架的人来说要容易得多，因为只有一个系统可以实现（并且没有状态）；对于使用 Web 框架的人来说，这要容易得多，因为他们不必记住为每个表单添加隐藏字段。而且它似乎更安全，因为 GET 得到了处理。

是否有任何缺点（除了要求客户端运行javascript）？我认为我没有在任何地方看到实施或讨论过这个想法。

Answer 1

首先，您很少希望保护 GET 请求免受 CSRF 的影响，因为正如您正确指出的那样，GET 不应该改变状态，因此应该是无害的。对 GET 请求的 CSRF 攻击可以通过一个简单的链接来消除，这是一种非常特殊的情况，如果您需要某种保护来防止这种情况（但对于某些请求仍然可能）。

除此之外，您可以混合使用好的解决方案，这样做的风险会增加您的攻击面并增加复杂性 - 您可能愿意或可能不愿意接受的风险。

您必须小心相互比较的参数以及安全性的基础。服务器生成和记住并写入表单的令牌的安全性基于服务器端会话安全性，即用户无法直接读取其他用户的会话内容这一事实。这是一个相当可靠的假设。 cookie-to-header 方法的安全性基于这样一个事实，即浏览器不允许攻击者的网站读取为应用程序域设置的 cookie - 这要弱得多，任意浏览器可能有错误，它可能有恶意插件/安装扩展等。它仍然可以被接受，但风险状况不同。 实施这两种解决方案意味着承担两者的风险。

此外，在混合解决方案的情况下，由于实施错误（增加了复杂性），存在比较错误事物的风险。例如，将 cookie 值与存储在服务器端会话中的值进行比较显然会否定效果，cookie 也会与来自攻击者站点的请求一起发送。