我正在构建一个大量使用ajax 的应用程序。大多数反 CSRF 解决方案都围绕将一些信息放入视图状态并在发布时处理该数据。但是，我无权访问 ajax 调用中的视图状态。
我计划生成一个 GUID 以在 cookie 和会话状态中插入令牌，使 cookie 在用户注销时过期，在每个请求时修改 cookie 令牌和会话状态，并使用 httpmodule 通过比较什么来完成工作在访问 Web 服务或页面方法之前，在会话中处理从客户端返回的内容。
这会让我的应用程序获得 CSRF 证明吗？
Thanks.
No.“反 CSRF”和“cookie”不能放在一起。正如 Thilo 简洁指出的那样：
Cookie 是 CSRF 发挥作用的首要因素......
一个好的初步阅读是跨站请求伪造 http://en.wikipedia.org/wiki/Cross-site_request_forgery文章，其中总结了 CSRF 的大部分内容：
如果 Bob 的银行将他的身份验证信息保存在 cookie 中，如果 cookie 尚未过期，则 Bob 的浏览器尝试加载图像将使用他的 cookie 提交提款表格，从而在未经 Bob 批准的情况下授权交易。
问题是浏览器总是有“有效的cookie”。然而，GUID——真的，只是a nonce http://en.wikipedia.org/wiki/Cryptographic_nonce——可以传送back通过其他方式到服务器......这实际上就是它在视图状态中的情况。
CSRF 预防机制#1（根据维基百科）：
在所有表单提交和副作用 URL 中都需要秘密的、用户特定的令牌防止 CSRF；攻击者的站点无法在其提交内容中放入正确的令牌。
重要的是这个秘密（希望是随机数以避免重放攻击）是部分数据（URI 或内容）正在发送，而不是通过 cookie 传输。
快乐编码。
考虑一种可以实现的方法：
让服务器在建立会话时生成随机数（并将其存储在会话数据中）。然后在每个 AJAX 请求上发送回这个随机数——或者作为 URI 的一部分或作为某些 POST 数据*.
服务器服务器应仅根据此随机数以及它是否与会话状态中存储的随机数匹配来接受/拒绝请求。 （会话状态可以通过 cookie 维护：假设随机数是秘密的，则通过不同通道传输的随机数将阻止此 CSRF。）
随机数可以通过多种方式传输到客户端，包括但不限于隐藏字段、JavaScript 变量、直接链接操作，甚至 cookie（只读！不用于验证！）。
*当然，存在许多重叠的安全问题（和预防机制），简单的 XSS 可以绕过最复杂的反 CSFR。可能值得考虑使用经过充分测试的框架......
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
