GWT - 处理 XSRF/CSRF
我是否正确，如果我在每个 RPC 请求中传递一个自行生成的 sessionID，并且仅检查此 sessionID 而不是 cookie 标头中传递的 sessionID，则会话不会被恶意站点劫持？我知道您还应该在 cookie 中发送此 sessionID，然后将其与每个请求发送的 sessionID 进行比较，以检测 XSRF 攻击，但按照我的方式这样做至少应该可以防止 XSRF 攻击，不是吗？
编辑
我知道 GWT 2.3 通过提供 XSRF 令牌支持来处理 XSRF。遗憾的是我被 GWT 2.2 困住了，所以必须自己处理它。
Am I correct, that if I pass a self-generated sessionID with every RPC request, and only check this sessionID instead of the one passed in the cookie header, the session can't be hijacked by malicious sites? I know that you should also send this sessionID in the cookie and then compare it with the one sent with every request to detect an XSRF attack but doing it my way should at least protect against XSRF attacks, doesn't it?
EDIT
I know that GWT 2.3 takes care of XSRF by providing XSRF Token Support. Sadly I'm stuck with GWT 2.2 and so have to deal with it by myself.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，因为浏览器没有足够的信息来说服您的应用程序它具有正确的凭据。在传统的 XSRF 攻击中，浏览器机制本身就会被利用，如果它不知道如何发送额外信息或发送哪些信息，那么它就无法工作。
然而，通过这种方法，我会意识到恶意攻击者仍然可以破坏您自己生成的 sessionID，并在他们弄清楚该机制后立即使用它。
请参阅此有关加密随机数的 Wiki 页面了解更多想法。在使用随机数时，您正在创建只能在该时刻使用的东西。一旦时间过去，数据要么变得无用（就密码与时间的关系而言），要么不会被服务器接受。传统上，这用于防止重放攻击，因为，请原谅我，随机数已经过去了。
Yes, because the browser doesn't have enough information to convince your application that it has the right credentials. In a traditional XSRF attack the browser mechanism itself is being exploited and if it doesn't know how to send the extra information or what information to send then it just won't work.
However, with this approach, I would be aware that a malicious attacker could still compromise your self-generated sessionID and use it as soon as they figured out the mechanism.
See this wiki page on cryptographic nonce for more ideas. In using the nonce you're creating something that can only be used for that moment. Once the moment passes the data either becomes useless (in terms of a password salted with a time) or won't be accepted by the server. This is traditionally used to prevent replay attacks because, if you'll forgive me, the nonce has passed.
您可能需要查看 OWASP 的 CSRF Guard 项目。他们使用过滤器检查向服务器发出的每个请求是否包含所需的 CRSF 令牌。它是相当可配置的 - 您可以指定防御的各个方面，例如：
生成（登录时）的
它实际上是
一个不需要更改代码的解决方案，其中最新版本还支持对服务器的 AJAX (RPC) 调用。所以我相信这绝对是一个值得尝试的选择（我目前正在为一个相当大的 GWT 应用程序 POCing 这个解决方案）。
最后，我相信您已经建立了针对 XSS 的防御措施。因为如果 XSS 可能的话，XSRF 防御就可以失效（更何况 XSRF 攻击一般都是通过 XSS 发起的）。
You might want to look at OWASP's CSRF Guard Project. They use a filter that checks every request to the server for the required CRSF Token. It's quite configurable - you can specify various aspects of your defense for ex:
is to be generated (upon login)
is picked up (redirect, logging) etc
It's effectively a solution which requires no code change where the latest version also supports AJAX (RPC) calls to the server. So I believe it's definitely an option to try out (I'm currently POCing this solution for a fairly large GWT app).
Lastly I trust that you have already built your defenses against XSS. As XSRF defenses can be nullified if XSS is possible (not to mention that XSRF attacks are generally launched via XSS).