反 CSRF cookie？
我正在构建一个大量使用ajax 的应用程序。大多数反 CSRF 解决方案都围绕将一些信息放入视图状态并在发布时处理该数据。但是，我无权访问 ajax 调用中的视图状态。
我计划生成一个 GUID 以在 cookie 和会话状态中插入令牌，使 cookie 在用户注销时过期，在每个请求时修改 cookie 令牌和会话状态，并使用 httpmodule 通过比较什么来完成工作在访问 Web 服务或页面方法之前，在会话中处理从客户端返回的内容。
这会让我的应用程序获得 CSRF 证明吗？
谢谢。
I'm building an application that uses a lot of ajax. Most anti-CSRF solutions revolve around putting some info in the viewstate and working with that data on post. However, I don't have access to the viewstate in an ajax call.
I plan to generate a GUID to insert a token in the cookie and the session state, make the cookie expire when the user logs out, modify the cookie token and session state at each request, and use an httpmodule to do the work by comparing what in the session with what's coming back from the client, before going to the web service or page method.
Will this make my app CSRF proof?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不。“反 CSRF”和“cookie”不能放在一起。正如 Thilo 简洁地指出的那样：
一个很好的初步阅读是 跨站点请求Forgery 文章，其中总结了大部分 CSRF：
问题是浏览器总是有“有效的cookie”。然而，GUID——实际上，只是随机数——可以传回< /em> 通过其他方式发送到服务器...这实际上就是视图状态中的内容。
CSRF 预防机制#1（根据维基百科）：
重要的是这个秘密（希望是随机数以避免重放攻击）是发送的数据（URI 或内容）的一部分，而不是通过 cookie 传输。
快乐编码。
考虑实现这一点的一种方法：
让服务器在建立会话时生成一个随机数（并将其存储在会话数据中）。然后，在每个 AJAX 请求中发送回此随机数 - 作为 URI 的一部分或作为某些 POST 数据*。
服务器服务器应仅根据此随机数以及它是否与会话状态中存储的随机数匹配来接受/拒绝请求。 （会话状态可以通过 cookie 维护：假设随机数是秘密的，则通过不同通道传输的随机数将阻止此 CSRF。）
随机数可以通过多种方式传输到客户端，包括但不限于：隐藏字段、JavaScript 变量、直接链接操作，甚至 cookie（只读！不用于验证！）。
*当然，存在许多重叠的安全问题（和预防机制），简单的 XSS 可以绕过最复杂的反 CSFR。可能值得考虑使用经过充分测试的框架......
No. "anti-CSRF" and "cookie" do not go together. As Thilo so concisely points out:
A good initial read is Cross-Site Request Forgery article, which sums most of CSRF up with:
The problem is the browser always has the "valid cookie". However, the GUID -- really, just a nonce -- could be transmitted back to the server via other means... which is effectively what it is in the view-state.
CSRF Prevention mechanism #1 (per Wikipedia):
The important thing is this secret (hopefully nonce to avoid replay attacks) is part of the data (URI or content) being sent and not transmitted via a cookie.
Happy coding.
Consider that one way this could be implemented:
Have the server generate a nonce when a session is established (and store it in session data). Then on each AJAX request send this nonce back -- either as part of the URI or as some POST data*.
The server server should accept/reject the request based only on this nonce and if it matched the nonce stored in the session state. (The session state can be maintained via cookies: it is the nonce transmitted via a different channel that will prevent this CSRF, assuming the nonce is secret.)
The nonce can be transmitted to the client in several ways including, but not limited to, a hidden field, a JavaScript variable, direct link manipulation, or even a cookie (read only! not for validation!).
*Of course, there are many overlapping security issues (and prevention mechanisms) at play and a simple XSS could bypass the most elaborate anti-CSFR. It may be worth considering using a well-tested framework...