反 CSRF cookie？答案

【问题标题】：Anti-CSRF cookie?反 CSRF cookie？
【发布时间】：2012-01-05 09:45:27
【问题描述】：

我正在构建一个使用大量 ajax 的应用程序。大多数反 CSRF 解决方案都围绕着将一些信息放入视图状态并在发布时处理该数据。但是，我无法访问 ajax 调用中的视图状态。

我计划生成一个 GUID 来在 cookie 和会话状态中插入一个令牌，使 cookie 在用户注销时过期，在每次请求时修改 cookie 令牌和会话状态，并使用 httpmodule 来完成这项工作在转到 Web 服务或页面方法之前，将会话中的内容与从客户端返回的内容进行比较。

这将使我的应用程序具有 CSRF 证明吗？

谢谢。

【问题讨论】：

没有。从阅读Cross-site Request Forgery 开始。 "如果 Bob 的银行将他的身份验证信息保存在 cookie 中，并且如果 cookie 没有过期，那么 Bob 的浏览器加载图像的尝试将使用他的 cookie 提交提款表单，从而授权未经 Bob 批准的交易。”问题是浏览器总是有“有效的cookie”。但是，GUID/nonce 可以通过其他方式传输......实际上就是它在视图状态中的内容。
@pst +1。 Cookies 是 CSRF 能够首先工作的原因......
@Thilo：好的，感谢您的澄清：）猜猜这个问题的意外目的是澄清和简化问题。
我会避免使用 GUID。它们不能保证是不可预测的。使用安全的 PRNG。
@CodeInChaos：好的，谢谢你的提示。

【解决方案1】：

不。“anti-CSRF”和“cookie”不能一起使用。正如 Thilo 简洁地指出的那样：

Cookies 是 CSRF 工作的首要条件......

一个很好的初步阅读是Cross-Site Request Forgery 文章，它将大部分 CSRF 总结为：

如果 Bob 的银行将他的身份验证信息保存在 cookie 中，并且如果 cookie 没有过期，那么 Bob 的浏览器尝试加载图像 将提交提款表单和他的cookie，从而在未经 Bob 批准的情况下授权交易。

问题是浏览器总是有“有效的cookie”。然而，GUID——实际上，只是a nonce——可以通过其他方式传回到服务器......这实际上就是它在视图状态下的样子。

CSRF 预防机制 #1（根据维基百科）：

在所有表单提交和副作用 URL 中要求一个秘密的、用户特定的令牌可以防止 CSRF；攻击者的站点无法在其提交的内容中放入正确的令牌。

重要的是这个秘密（希望 nonce 以避免重放攻击）是数据的一部分（URI 或内容）被发送而不是通过 cookie 传输。

编码愉快。

考虑一种可以实现的方法：

让服务器在会话建立时生成一个随机数（并将其存储在会话数据中）。然后在每个 AJAX 请求上将此 nonce 发送回来 - 作为 URI 的一部分或作为一些 POST 数据*。

服务器服务器应仅基于此 nonce 以及是否与会话状态中存储的 nonce 匹配来接受/拒绝请求。（会话状态可以通过 cookie 维护：假设 nonce 是秘密的，通过不同的通道传输的 nonce 将阻止此 CSRF。）

nonce 可以通过多种方式传输到客户端，包括但不限于隐藏字段、JavaScript 变量、直接链接操作，甚至是 cookie（只读！不用于验证！）。

*当然，有许多重叠的安全问题（和预防机制）在起作用，一个简单的 XSS 可以绕过最复杂的反 CSFR。使用经过良好测试的框架可能值得考虑...

【讨论】：

好的，感谢您的反馈！所以cookies是不可以的，谢谢你说清楚。目标是通过另一种方式传输信息。这篇帖子codethinked.com/… 建议使用标头作为传输机制。有人说用户可以/确实删除标题。你对这项技术有什么看法。谢谢。
对标头技术没有意见，只是澄清一下：用户自己可以弄乱自己的请求标头不是问题，如果可以做到这一点就会有问题代表用户的攻击者（在他们不知情的情况下，违背他们的意愿）。这就是“糊涂副手”的普遍问题。
好的，我的问题是似乎没有很多选项可以保护 ajax 请求。