通过跨域 JavaScript 调用防止 CSRF
我希望保护我的网站免遭跨站请求伪造。我正在尝试遵循这些建议，通过发送特定于会话的令牌以及需要保护的所有请求。
问题是我有一些请求被设计为由不同域上的第三方网站调用。他们中的大多数使用 JSONP：他们使用
我的问题是，如何在这些请求中传递令牌？第三方网站似乎需要知道该令牌。我可以提供另一个以 JSON 形式返回令牌的请求，但不受信任的站点可以发出相同的请求，获取令牌，并使用它来伪造对我们服务器的请求。
有更好的方法吗？
I'd like to protect my site against cross-site request forgery. I'm trying to follow these recommendations, by sending a session-specific token along with all requests that need to be protected.
The catch is that I have some requests that are designed to be called by third-party sites, on a different domain. Most of them use JSONP: they make a request to our server using a <script> tag, and the response is JavaScript code that calls a function on their page.
My question is, how to I pass the token in these requests? It seems like the third-party site would need to know the token. I could provide another request that returns the token as JSON, but then untrusted sites could make the same request, get the token, and use it to forge requests to our server.
Is there a better way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
XSRF 令牌通常是您在域中生成的 cookie。您确实不想引入一种机制来允许其他站点设置这些内容。验证消息是否来自受信任方最好将其视为签名验证问题。
您可以让每个合作伙伴站点生成并保留私有/公共签名密钥对。然后他们可以向您发送他们的公钥。
然后他们可以签署发给您的消息。
因此，他们的请求看起来像这样
，然后您可以使用您通过密钥
foobar查找的公钥来签名检查签名的查询字符串是否已正确签名。您现在知道，如果请求具有您的 XSRF 令牌或者使用与您建立关系的合作伙伴的私钥正确签名，则可以信任该请求。
这不会阻止可以观察到正在查看合作伙伴网站的登录用户重播请求的人，因此合作伙伴网站和您的脚本都应该通过安全通道 (
https) 加载，就像您可以多次使用 XSRF 令牌。XSRF tokens are usually cookies on your domain that you generate. You really don't want to introduce a mechanism to allow other sites to set those. Verifying that a message comes from a trusted party is better treated as a signature verification problem.
You can have each partner site generate and keep a private/public signature key pair. Then they can send you their public key.
They can then sign their messages to you.
So their request would look like
and then you can signature check that the signed query string was properly signed using the public key you looked up by the key
foobar.You now know to trust the request if it either has your XSRF token or it is properly signed using the private key of a partner you've established a relationship with.
This won't stop someone who can observe a logged in user viewing the partner site from replaying the request, so the partner site and your script should both be loaded via a secure channel (
https), just as you would with multiple-use XSRF tokens.我正在使用的解决此问题的方法是将 IFRAME 嵌入到我正在创建的外部小部件的 UI 中。这里唯一的缺点是其他人可能在点击劫持攻击中使用此 iframe。您可以在这里阅读相关内容：https://security.stackexchange.com/questions/13341/security -使用 iframe 的问题。
The solution to this problem that I am using is to embed an IFRAME inside the UI of an external widget I am creating. The only drawback here is the possibility of others using this iframe in a clickjacking attack. You could read about that here: https://security.stackexchange.com/questions/13341/security-issues-using-iframes.
我对 JSONP CSRF 问题有最简单的解决方案，添加“While(1);”或“for(,,);”或扔“F*** U”；在 json 响应数据的开头。
现在任何 JSONP 请求都会陷入无限循环。由于您没有使用 JSONP 请求，因此您可以通过此代码修改响应
I have the simplest solution to the JSONP CSRF problem, Add the "While(1);" or "for(,,);" or throw "F*** U"; in start of your json response data.
Now Any JSONP request end up in a infinite loop. Because you aren’t using a JSONP request, you have the ability to modify the response by this code