JSONP使用安全吗？

使用JSONP时是否应考虑任何安全性问题？

更新：JSONP是执行跨域请求的常见技巧。现在，现代浏览器具有跨源资源共享，而IE8 +具有类似的XDomainRequest。有关更多信息，请参见http://enable-cors.org/。

JSONP只是一个脚本包含，允许您使用回调。但是，您应该注意跨站点请求伪造（CSRF）。

只要您控制脚本和服务器，JSONP就不会比脚本所包含的不安全。除非您有一个JSONP服务将敏感数据返回给登录用户。恶意站点可以向服务发送请求（希望用户登录到您的站点），并获取数据。该服务可以检查请求的引荐来源，但是可以使用Flash欺骗引荐来源（感谢Chris Moschini）。

想象一下这种情况：-用户登录到他的网上银行帐户。在用户浏览器中存储会话cookie。该站点具有jsonp服务，其中包含有关用户及其帐户的敏感信息。-其他站点将不知道用户已登录，但是他们可能会做出疯狂的猜测并尝试访问jsonp服务。由于用户具有会话cookie，因此浏览器将获得响应，并且没有任何阻止站点进行ajax发布以将敏感数据保存在其服务器上的事情。

2012年6月28日更新：如果您想防御CSRF攻击，您应该阅读安全专家的深入博客文章：http : //erlend.oftedal.no/blog/?blogid=130

是的，您需要小心，但是当与受信任的服务正确使用时，它是相对安全的。

据我了解，这是JSONP的安全性问题的摘要：

从消费者的角度来看：

• 您必须信任提供者不要返回恶意JavaScript，而不是返回的JSON（包装在您指定的JSONP回调中）。
• 任何第三方JavaScript嵌入式加载项（例如Google Analytics（分析））也是如此。
• 它仅与XSS攻击相似，它允许第三者在您的应用程序中执行任意JavaScript，但是，您必须首先通过首先发出请求来选择信任该第三者。

从提供者的角度来看：

• 即使请求中存在客户的cookie，也不能假定使用者是您控制的网页。根据授权URL的白名单检查Referer标头，和/或不依赖基于cookie的身份验证。
• 类似于CSRF /混淆的副攻击。

双方都有安全问题。最严重的一个是针对包含JSONP的网站。

如果要包含来自另一个域的（您无法控制），则该域可以随时更改脚本。他们可以使javascript在您的网页上下文中执行您自己的javascript可以执行的任何操作。如果使用JSONP，则无法解决此问题。您应该研究使用iframe的跨域通信，最好由出色的EasyDXM库完成。

如果要提供处理JSONP的Web服务，则必须防止跨站点请求伪造（CSRF）。这是您的Web服务将敏感信息返回给登录用户的地方。如果用户已登录到您的站点，则任何其他站点都可以生成对JSONP服务的GET请求，并且您的域的cookie随请求一起提交-本质上是对登录用户进行身份验证-除了现在，远程域获得响应并能够读取敏感数据！

防止CSRF的最佳方法是生成一个随机数（难以猜测的随机生成的数字）并将其存储在会话中。在您的网页上以所有形式输出此随机数，并将其包含在您的页面上的所有JSONP请求中。在服务器上，请确保随机数存在并且在请求中正确无误（无论是GET，POST等）。尽管存在Cookie，其他域也将无法猜测该随机数，因此无法获取敏感信息。正在发送。

最后，还有另一种安全问题：JSONP根本不支持浏览器中的用户身份验证，这是OAuth可以实现的。当然，您可以让服务器获取某种访问令牌（例如使用OAuth）并使用它。但是，如果您想完全在浏览器中进行身份验证，则必须与iFrame一起使用跨域通信。我认为这就是OAuth 2.0的工作方式。设置方法如下：网站上托管的页面对服务器具有完全访问权限。有一个JavaScript库，可加载EasyDXM并使用它来将隐藏的iframe设置到您的网站，并使用它与之对话。

JSONP绝对不安全，因为它只是运行跨域的任何JavaScript代码。

解！解！

创建一个iframe，最好是一个沙盒，然后在其中加载JSONP。捕获结果并将其传递给window.postMessage

是的，像往常一样，首先有人想到了这个主意:)

博客文章不再存在，但我在此处保留此链接以获得信誉：http : //beebole.com/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup-security/
编辑：Wayback机器链接

它使用window.name hack进行iframe通信，但这是针对IE6和7的。