如何可靠地保护公共JSONP请求？

Question

我正试图找出一种在客户网站上嵌入的javascript小部件上防止CSRF的好方法。

该小部件将使最终用户能够通过JSONP向我们客户的帐户发出请求，并将这些请求代理到我们的（非公开）API。

到目前为止，我还没有想出一个确定的方法来确保所有请求都来自我们客户的网站。我有过一些想法：

• 在服务器端生成令牌并与每个后续JSONP请求一起传回（不知道如何验证初始请求，因为第一个令牌在JS中是可读的，任何人都可以请求'下一个'令牌）
• 检查Referer标头（不可靠，可能被欺骗或根本没有被浏览器传递）
• 使用SSL（当然有助于解决CSRF的问题）

这一切都可能吗？我遇到Fotomoto's widget似乎允许我们正在寻找的相同类型的功能，但我不确定他们是如何做的。

Answer 1

根据定义，这是“跨站点请求”。值得注意的是，CSRF请求是否是漏洞在很大程度上取决于请求的作用。例如，如果攻击者可以强制客户端发出搜索请求，那么这可能对攻击者没有任何帮助。如果攻击者可以更改管理员的密码，那么您就会遇到非常严重的问题。

因此，如果不知道这些请求是做什么的，就不可能说它应该如何保护。话虽如此，我认为reCapthca是一个很好的例子，说明如何使用非对称加密来确保服务器授权客户端与第三方进行翻译。但是没有更多的信息，我不知道这对你有什么帮助。

Answer 2

您永远不会找到一种解决方案，确保来自随机第三方（用户）的请求实际上是通过访问您客户的网站来启动的。如果您的安全性依赖于此，那么您必须删除该假设。 （如果你的意思是“确保请求仅来自我们客户的网站”服务器那么这是微不足道的：带有客户端证书的SSL。但我认为你的意思是“来自随机用户机器意图使用我们客户的网站。“）

您应该关注如何防止用户被欺骗（CSRF）。因此，例如，Referer可以被欺骗的事实与此问题无关。唯一的问题是是否有一个浏览器有一个漏洞，允许第三方欺骗用户创建一个欺骗的Referer。因此，您应该根据需要检查Referer，但还不够。也就是说，如果Referer错误，请挂断呼叫者。但Referer是对的这一事实并不意味着你实际上是在收到合法的请求。我认为大多数CSRF都是由于未能检查Referer，而不是浏览器错误。

Wikipedia article on CSRF对明显的预防技术有一个很好的总结。只需检查Referer就是第一步。