对预防CSRF的质疑
我对 CSRF 预防有一个疑问。许多网站表示可以通过使用每个会话随机生成的“令牌”来防止 CSRF。
现在我的疑问是， 假设我有一个像这样的函数：
$.post("abcd.php",{'fbuid':userid,'code':'<?php echo md5($_SESSION['randcode']); ?>'}
现在这个 md5 哈希显然可以通过源代码对任何黑客可见。他可以简单地打开这个页面，生成一个令牌，并保持页面打开，这样会话就不会被破坏，并使用另一个选项卡或其他任何东西来开始黑客攻击，
不是吗？
或者我对代币的想法不正确？
感谢您的帮助：D
I had one doubt about CSRF prevention. A lot of sites say that CSRF can be prevented by using 'tokens' which are randomly generated per session.
Now my doubt is,
suppose i have a function like :
$.post("abcd.php",{'fbuid':userid,'code':'<?php echo md5($_SESSION['randcode']); ?>'}
now this md5 hash would obviously be visible to any hacker through the source code.He could simply open this page, generate a token, and keep the page open, so that the session doesn't get destroyed, and useanother tab or anything else , to start hacking,
No ?
Or is my idea of tokens incorrect ?
Thanks for your help :D
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为您误解了需要做什么。为了防止 CSRF，您需要创建一个令牌并为该会话保存它。然后，您需要使用该令牌附加所有提交和 AJAX 调用。
为了让其他人将您转到您网站上的页面，他们需要在同一会话中有权访问该请求。确实，人们可以解析 HTML 并查找令牌。但是，当他们尝试在您的网站上请求 http 调用时，他们将创建一个新会话。新会话将有一个新令牌，该令牌与传递的令牌不匹配。
接下来您会问如果您可以复制 cookie 和会话 ID 结果会怎么样。这不是受保护的东西。我可以简单地坐在任何人的计算机上并复制他们所有的cookie，然后我将以他们的身份登录。
I think you are misunderstanding what needs to be done. To protect against CSRF you need to create a token and save it for that session. Then you need to append all your submits and AJAX calls with that token.
For another person to send you to a page on your website they would need to have access to the request with in the same session. It is true that one could parse the HTML and look for the token. But when they try to request a http call on your website they will have a new session created. The new session will have a new token which will not match the token that was passed.
Next you will ask what if you can copy the cookies and the session id as a result. This is not something that is protected. I can simply sit anybody's computer and copy all their cookies and I will then be logged in as them.
正如 kapep 指出的那样，您混淆了输入验证和跨站点表单发布这两个独立的问题。无论如何，您都必须验证您的输入，因此，如果您有健全的输入验证，那么恶意攻击者使用自己的会话令牌的情况就已经得到处理。 CSRF 保护并不是为了保护数据，它只是为了确保只有您自己的应用程序中的表单才能将数据发送回该应用程序。 CSRF 保护只是阻止其他人从他们在自己网站上发布的表单直接将数据发布到您的应用程序中。
需要注意的一个具体点是，该令牌对于页面上运行的任何 JavaScript 都是可见的，因此一旦存在跨站脚本 (XSS) 漏洞，您的 CSRF 保护就会失效。
请参阅跨站脚本和预防备忘单
As kapep points out, you are confusing the two seperate issues of input validation and cross-site form posting. You must validate your inputs anyway, so the case of your malicious attacker using his own session token is already handled if you have sound input validation. CSRF protection is not there to protect the data, it is simply to ensure that only forms from your own application can post data back to that application. the CSRF protection is simply stopping other people being able to post data directly into your app from forms they put up on their own site.
One specific point to be aware of is that the token is visible to any javascript running on your page, so as soon as you have a cross-site scripting (XSS) vulnerability, your CSRF protection is defeated.
See Cross-site scripting and the prevention cheat sheet
您应该使用每个请求令牌。
令牌更安全，不能多次使用。
You should use a per request token.
The token is safer and cannot be used more than one time.
我将被盗令牌定义为由其他人使用的令牌，而不是您将令牌发送到的人。如果您向某人发送令牌，他实际上无法从自己那里窃取它。
如果您担心用户可以使用自己的令牌运行恶意脚本，那么您的设计似乎已被破坏。您无法阻止用户发送您不打算接收的数据。您的工作是验证任何数据，会话令牌只是用于识别同一客户端的多个请求。
如果您通过不安全的 http 发送该令牌，则可能会出现安全问题。然后，通过监控客户端网络，它很容易被盗。
I would define a stolen token as a token that is used by someone else, and not the one you have send the token to. If you send someone a token he can't really steal it from himself.
If you are concerned that a user can run a malicious script with his own token, your design seems to be broken. You can't prevent a user from sending data that you didn't indented to receive. It's your job to validate any data, the session token is just there to identify multiple requests by the same client.
It could be a security issue if you send that token over unsecured http. Then it could easily be stolen by monitoring the clients network.