客户端生成双重提交cookie，防止跨站请求伪造
在双重提交cookie csrf防范方案中，服务器是否需要提供cookie？
看来我可以让客户端页面上的javascript生成并设置一个cookie“anti_csrf”，然后双重提交（一次作为cookie，由浏览器完成，一次在请求正文中）。
外部域将无法读取或写入“anti_csrf”cookie 以将其包含在请求正文中。
这是安全的，还是我忽略了一些东西？
in a double-submitted cookie csrf prevention scheme, is it necessary for the server to provide the cookie?
it seems i could have javascript on the clients page generate and set a cookie "anti_csrf", then double submit that (once as a cookie, done by the browser, and once in the body of the request).
a foreign domain would not be able to read or write the "anti_csrf" cookie to include it in the body of a request.
is this secure, or am i overlooking something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Tgr，请阅读以下内容：
http://jazzy.id.au/default/ 2010/09/20/cracking_random_number_generators_part_1.html
攻击者所需要的只是从随机数生成器中获取一两个令牌，然后他们可以预测每个后续和每个先前的随机数（如果它不是加密安全的）。如果随机数生成是在 Javascript 客户端完成的，我不知道有哪个浏览器使用加密安全随机数生成器，因此他们只需调用 Math.random() 几次，就可以计算出什么已为您的 cookie 生成令牌。
Tgr, read this:
http://jazzy.id.au/default/2010/09/20/cracking_random_number_generators_part_1.html
All the attacker needs is to get a token or two out of the random number generator, and then they can predict every subsequent and every previous random number if it's not cryptographically secure. If the random number generation is done client side in Javascript, I don't know of a single browser that uses a cryptographically secure random number generator, so they simply have to call Math.random() a few times and they can work out what token was generated for your cookie.
如果用户已经为您的域设置了“anti_csrf”cookie，那么 CSRF 攻击者就可以逍遥法外了！ HTTP 请求将带着 cookie 发出，当然，如果您知道参数值是什么，那么在 POST 中包含参数当然很容易。
Cookie 名称 不必是秘密，但 Cookie 值 必须是难以猜测的秘密，只有用户会话知道。这样，攻击者就不知道（也无法猜测）要在攻击性 HTTP 事务中放入什么内容。
如果您将代码放在构成 cookie 值的页面上，那么您必须假设攻击者可以在您的站点获得他/她自己的会话（即有效的“真实”登录）并直接检查代码。如果很容易弄清楚 cookie 值是如何在客户端生成的（并且，对于人类已知的几乎任何客户端解决方案来说，都会如此），那么攻击者再次可以让他们的攻击页面在其中包含正确的参数值攻击 POST。
If the user already has the "anti_csrf" cookie set for your domain, then the CSRF attacker is home free! The HTTP request will go out with the cookie, and of course it's easy to include the parameter in the POST if you know what the value is.
The cookie name doesn't have to be a secret, but the cookie value has to be a hard-to-guess secret known only to the user session. That way, the attacker does not know (and cannot guess) what to put in an attacking HTTP transaction.
If you put the code on the page that makes up the cookie value, then you have to assume that the attacker can get his/her own session at your site (that is, a valid "real" login) and examine the code directly. If it's easy to figure out how the cookie value is generated client-side (and, for just about any client-side solution known to man, it will be), then again the attacker can have their attacking page include the right parameter value in an attack POST.
乍一看这似乎很安全，但这意味着没有 JavaScript 的用户无法使用您的表单。
On the first glance it seems safe, but it will mean users without javascript cannot use your forms.