这个CSRF对策有效吗？
请告诉我以下防范 CSRF 的方法是否有效。
- 生成令牌并保存在服务器上
- 通过 cookie 将令牌发送到客户端
- 客户端上的 JavaScript 读取 cookie 并将令牌添加到表单中，然后 POSTing
- 服务器将表单中的令牌与保存的令牌进行比较。
任何人都可以看到通过 cookie 发送令牌并使用 JavaScript 读取它而不是将其放入 HTML 中的任何漏洞吗？
Please let me know if the following approach to protecting against CSRF is effective.
- Generate token and save on server
- Send token to client via cookie
- Javascript on client reads cookie and adds token to form before POSTing
- Server compares token in form to saved token.
Can anyone see any vulnerabilities with sending the token via a cookie and reading it with JavaScript instead of putting it in the HTML?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果一个人的流量受到监控，黑客也可能会获得令牌。但这听起来是一个很棒的计划。我会尝试添加一个蜜罐。尝试将令牌伪装成其他东西，这样它就不明显了。如果它被触发，请将不良用户发送到蜜罐中，这样他们就不会知道自己已经被欺骗了。
我的安全理念很简单，最好用一个故事来说明。
两个男人正穿过树林。他们看到一只熊，吓坏了，开始逃跑。当熊追上他们并抓住其中一只时，告诉另一只熊：“我们永远跑不过这只熊”。另一个人回答说：“我不需要跑过熊，我只要跑过你就行了！”
您可以添加到您的网站以使其更安全、您的处境更好的任何内容。使用框架，验证所有输入（包括任何公共方法中的所有输入），你应该没问题。
如果您存储敏感数据，我会设置第二个无法访问互联网的 SQL 服务器。让您的后端服务器不断访问您的前端服务器，提取敏感数据并将其替换为虚假数据。如果您的前端服务器需要敏感数据（这很可能），请使用一种特殊方法，该方法使用不同的数据库用户（具有访问权限）从后端服务器中提取数据。有人必须完全拥有你的机器才能解决这个问题……而且你仍然需要足够的时间才能拔掉插头。最有可能的是，他们会在意识到它是伪造的之前提取您的所有数据......哈哈。
我希望我有一个好的解决方案来更好地保护您的客户以避免 CSRF。但你所拥有的看起来是一个很好的威慑力。
If a persons traffic is being monitored the hacker will likely get the token also. But it sounds like a great plan. I would try to add a honeypot. Try to disguise the token as something else so It's not obvious. If it's triggered, send the bad user into the honeypot so they don't know they've been had.
My philosophy with security is simple and best illustrated with a story.
Two men are walking through the woods. They see a bear, freak out and start running. As the bear catches up to them and gaining one of them tells the other, "we'll never outrun this bear". the other guy responses, "I don't have to outrun the bear, I only have to outrun you!"
Anything you can add to your site to make it more secure the better off you'll be. Use a framework, validate all inputs (including all those in any public method) and you should be ok.
If your storing sensitive data I would setup a second sql server with no internet access. Have your back-end server constantly access your front-end server, pull and replace the sensitive data with bogus data. If your front-end server needs that sensitive data, which is likely, use a special method that uses a different database user (that has access) to pull it from the back-end server. Someone would have to completely own your machine to figure this out... and it would still take enough time that you should be able to pull the plug. Most likely, they'll pull all your data before realizing it's bogus... ha ha.
I wish I had a good solution on how to protect your customers better to avoid CSRF. But what you have looks like a pretty good deterrent.
这个问题在 Security Stack Exchange< /a> 关于这个主题有一些有用的讨论。
我特别喜欢@AviD的回答：
This question over on Security Stack Exchange has some useful discussion on the subject.
I especially like @AviD's answer:
同步器令牌模式依赖于将客户端已知的随机数据与表单中发布的数据进行比较。虽然您通常会在页面渲染时从填充有令牌的隐藏表单中获取后者，但通过使用 JavaScript 填充它，我看不到任何明显的攻击向量。攻击站点需要能够读取 cookie 来重建 post 请求，但由于跨域 cookie 的限制，攻击站点显然无法做到这一点。
您可能会发现OWASP Top 10 .NET 开发人员第 5 部分：跨站点请求伪造 (CSRF) 很有用（很多常规 CSRF 信息），特别是有关跨源资源共享的部分。
The synchroniser token pattern relies on comparing random data known on the client with that posted in the form. Whilst you'd normally get the latter from a hidden form populated with the token at page render time, I can't see any obvious attack vectors by using JavaScript to populate it. The attacking site would need to be able to read the cookie to reconstruct the post request which it obviously can't do due to cross-domain cookie limitations.
You might find OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF) useful (lot's of general CSRF info), particularly the section on cross-origin resource sharing.