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

【问题标题】：How to reliably secure public JSONP requests?如何可靠地保护公共 JSONP 请求？
【发布时间】：2011-08-29 16:31:45
【问题描述】：

我正在尝试寻找是否有防止 CSRF 出现在客户网站上嵌入的 javascript 小部件上的好方法。

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

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

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

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

【问题讨论】：

标签： security jsonp csrf

【解决方案1】：

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

您应该了解如何防止用户被欺骗 (CSRF)。因此，例如，Referer 可以被欺骗这一事实与此问题无关。唯一的问题是浏览器是否存在缺陷，允许第三方诱骗用户创建欺骗性的Referer。因此，您应该根据需要检查Referer，但还不够。也就是说，如果Referer错了，就挂断调用者。但是，Referer 是正确的事实并不意味着您实际上收到了合法的请求。我认为大多数 CSRF 是由于未能检查Referer，而不是浏览器错误。

Wikipedia article on CSRF 对明显的预防技术进行了不错的总结。仅检查Referer是重要的第一步。

【讨论】：

【解决方案2】：

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

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

【讨论】：