什么使跨域ajax不安全？

我不确定我是否了解这会导致什么类型的漏洞

当我需要从API访问数据时，我必须使用ajax在我自己的服务器上请求一个PHP文件，并且该PHP文件访问API。是什么让它比简单地允许我直接使用ajax访问API更安全

就这点而言，看起来使用JSONP您可以完成跨域ajax允许您完成的所有事情

---

有人能告诉我吗？

通过跨站点脚本，您将拥有一个能够从任何地方提取数据的网页，然后能够在与页面上其他数据相同的上下文中运行，理论上可以访问cookie和其他您不希望访问的安全信息。跨站点脚本在这方面是非常不安全的，因为您可以访问任何页面，如果允许的话，该页面上的脚本可能只是从任何地方加载数据，然后开始执行错误代码，因此不允许这样做

---

另一方面，JSONP允许您以JSON格式获取数据，因为您提供了数据传递到的必要回调，因此它提供了控制措施，即浏览器不会执行数据，除非回调函数执行并执行或尝试执行它。数据将采用JSON格式，您可以使用它做任何您想做的事情，但是它不会被执行，因此它更安全，这也是它被允许的原因。

许多web服务不是为了抵抗，因此，如果一个网站可以通过一个带有跨域cookie的请求以编程方式加载用户数据，那么只要用户访问了该网站，任何能够运行javascript的人都可以窃取用户数据

CORS是XHR计划中的一种安全替代方案，它通过以下方式解决了这个问题。CORS规范解释了该问题：

用户代理通常对网络请求应用相同的来源限制。这些限制防止从一个源运行的客户端Web应用程序获取从另一个源检索的数据，并且还限制可以自动向与运行的应用程序的源不同的目标启动的不安全HTTP请求

在遵循此模式的用户代理中，网络请求通常使用环境身份验证和会话管理信息，包括HTTP身份验证和cookie信息

编辑：

让XHR跨域工作的问题是许多web服务都会暴露。通常，该权限仅适用于来自同一来源的代码

这意味着信任网站的用户信任该网站的所有代码及其私有数据。用户信任他们将数据发送到的服务器，以及由该服务器提供服务的页面加载的任何代码。当网站背后的人和它加载的库是可信的时，用户的信任就很好了

如果XHR跨源工作，并携带cookies，那么任何可以向用户提供代码的人都可以使用该环境权限来编写代码。用户以前做出的信任决定可能不再合适

---

CORS不会继承这些问题，因为现有的服务不会向CORS公开环境权限。

API的模式使得它不仅是最好的，而且是必要的实践，可以在通过服务器时检查您得到的信息。除此之外，像稳定的本地解析器（又称DNS蠕虫）等在服务器上的可能性要比在一些随机客户端上的可能性小得多

至于JSONP：这不是拐杖，而是拐杖。依我看，这可能被视为是针对HTML/JS组合的一个错误特性的攻击，在不破坏现有代码的情况下无法删除。其他人可能对此有不同的看法

---

虽然JSONP允许您在恶劣的广域环境中从somwhere无反射地执行代码，但没有人强迫您这样做。JSONP的合理实现总是使用某种散列等方法来验证代码的提供者是否可靠。同样，其他人可能会有不同的想法。

我认为你误解了同一原产地政策试图解决的问题

假设我登录到Gmail，Gmail有一个JSON资源，http://mail.google.com/information-about-current-user.js，其中包含有关登录用户的信息。这个资源大概是为了供Gmail用户界面使用，但是，如果不是为了同一来源策略，我访问的任何网站，以及怀疑我可能是Gmail用户的网站，都可以运行AJAX请求以我的身份获取该资源，并检索关于我的信息，Gmail对此无能为力

因此，同源策略是不保护您的PHP页面免受第三方网站的攻击；这并不是为了保护访问PHP页面的人不受第三方网站的攻击；相反，它是为了保护访问您的PHP页面的人，以及他们有特殊访问权限的任何第三方站点，不受您的PHP页面的影响。（这种“特殊访问”可能是因为Cookie、HTTP认证、IP地址白名单，或者仅仅是在正确的网络上——可能有人在NSA工作并访问您的站点，但这并不意味着您应该能够从NSA内部页面触发数据转储。）

JSONP通过引入一个不同的限制以一种安全的方式绕过了这一点：它只在资源是JSONP的情况下工作。因此，如果Gmail希望给定的JSON资源可供第三方使用，它可以为该资源支持JSONP，但如果它只希望该资源可供自己的用户界面使用，它只能支持纯JSON。

该服务从未设计为允许跨源请求。原因是一个有形的安全漏洞，这主要是众所周知的

在此攻击场景中，第三方站点可以强制受害者的用户代理向源服务器发送伪造但有效且合法的请求