CSRF和不断变化的代币 [英] CSRF and ever changing tokens

问题描述

我刚刚在CSRF上看到了 Doctype的集。

他们说，CSRF的最佳预防方法是从某些用户唯一数据创建令牌（例如，对会话ID进行哈希处理），然后将其与您的请求一起发布。

生成难以猜测的值（例如GUID）并将其存储为会话变量并将其作为隐藏字段放入页面中，会不太安全吗？

每次加载页面时，值都会更改，但在此之前将对POST数据进行测试。

在我看来，这同样安全。我错了吗？

解决方案

令牌的来源可能并不那么有趣，只要它在任何情况下都不可猜测或无法确定办法。但是请注意在每个请求上生成新令牌，因为这将意味着您的网站对打开了两个或更多浏览器标签的用户不起作用。通过在用户会话期间保持一个令牌值，您可以避免此问题。

更改每个请求的令牌可以说更安全。但是罚款可能被认为过高。就像几乎所有涉及安全性的问题一样，您经常会发现必须权衡用户体验的便捷性-找到一个喜欢验证码的用户！为您的应用程序和用户找到合适的平衡对您的安全和可用性至关重要。

Open Web Application Security Project

还请记住，如果在受令牌保护的页面上只有一个跨站点脚本漏洞，那么CSRF令牌现在就没有用了。另请参见 OWASP XSS（跨站点脚本）预防速查表。 / p>

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?

解决方案

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.

这篇关于CSRF和不断变化的代币的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！