CSRF 和不断变化的代币
我刚刚在 CSRF 上看过 Doctype 剧集。
他们在其中表示，CSRF 的最佳预防方法是从一些用户唯一数据（例如散列会话 ID）创建令牌，然后将其与您的请求一起 POST。
生成一个难以猜测的值（例如 GUID）并将其存储为会话变量并将其作为隐藏字段放入页面中是否会不太安全？
每次加载页面时，该值都会改变，但 POST 数据的测试将在此之前进行。
在我看来，这同样安全。我错了吗？
I've just seen Doctype's episode on CSRF.
In it they say that the best prevention for CSRF is to create a token from some user unique data (e.g. hash a session ID) and then POST that along with your request.
Would it be less secure to generate a difficult to guess value (e.g. GUID) and store that as a session variable and put it into the page as a hidden field?
Each time the page is loaded the value would change, but the test of the POSTed data would come before that.
This seems to me to be just as secure. Am I wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
只要令牌无法以任何方式猜测或确定，令牌的来源可能就不那么有趣了。但请注意在每个请求上生成新令牌，因为这意味着您的网站将无法供打开两个或更多浏览器选项卡到您网站的用户使用。通过在用户会话期间坚持使用一个令牌值，您可以避免这一问题。
每个请求都更改令牌可以说更安全。但处罚很可能被认为太高了。就像涉及安全性的几乎所有事情一样，您经常发现必须在用户体验的便捷性之间进行权衡 - 给我找一个喜欢验证码的用户！为您的应用程序和用户找到适当的平衡对于您的安全性和可用性都很重要。
在 Open Web Application 上有一些关于 CSRF（以及更多内容）的好读物安全项目
另请记住，如果受令牌保护的页面上只有一个跨站脚本漏洞，那么您的 CSRF 令牌现在就没用了。另请参阅OWASP XSS（跨站脚本）预防备忘单。
Where the token comes from is probably not that interesting as long as it is not guessable or determinable in any way. But watch out on generating a new token on each request as this will mean that your site will not work for a user who opens two or more browser tabs to your site. By sticking to one token value for the duration of a user's session, you can circumvent this problem.
Changing the token every request is arguably more secure. But the penalty could well be considered too high. Like almost anything when it comes to security, you often find you have to make trade-offs against the ease of the user's experience -- find me one user that enjoys CAPTCHAs!. Finding the right balance for your application and your users is important- to both your security and your usability.
There's some good reading on CSRF (and much more) over at the Open Web Application Security Project
Also bear in mind that if you have just one cross-site scripting vulnerability on a token-protected page, then your CSRF token is now useless. See also the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet.