在我们的Web应用程序中，我们遇到了这样一种情况：我们需要从一个完全控制的域控制到我们完全控制的另一个域的跨域AJAX调用。我一直在寻找最佳解决方案，我想到的两个是本地文件代理（使用php :: fopen的本地文件）或jquery / JSONP。
当我在网上查询时，我看到人们经常谈论使用JSONP是多么危险，因为有人可能会用它注入恶意数据。令人困惑的是，大多数反对它的论据似乎没有多少水，所以我来这里要求Stack澄清。
跨域JSONP会打开哪些特定的攻击媒介？
根据我的理解，JSONP的唯一向量是通过在您的网站上包含<script>标记而打开的完全相同的向量，该标记的src是任何不受你：他们可以变成恶意并开始耕种用户会话/ cookie /数据。如果这是真的，那么似乎关注的不是协议（JSONP），而是收集数据的源。
因为它是服务器端代理，<script>标记还是ajax / JSONP，风险在于我将其他人的内容放在我的页面上，如果他们觉得他们可以开始耕种用户会话有必要（在某种程度上，这正是Google分析通过脚本标记所做的事情）。
我在网上听到的很多向量都取决于用户提交的表单和数据的不正确验证。在示例中，JSONP用于提取某个文件，该文件将数据放入表单中，然后提交表单以进行数据库插入。如果来自该表单的数据是可信的，因为它来自被认为是安全的源（JSONP数据），并且在没有验证的情况下放入，那么同样不是JSONP出错，而是未正确验证的用户输入。用户可以使用Firebug对该表单进行完全相同的修改，但最后我检查没有人将Firebug称为安全向量。
最后一个要素是服务器端代理有一个更强大的功能，可以在将结果传递给客户端之前对结果进行过滤。然而，无论是PHP还是Javascript，我都可以过滤结果以删除onclick或iframe等内容。当然，有人客户端可以改变我的javascript函数来删除过滤，但过滤只会影响他们的特定客户端体验，并且不会被其他用户更改，从而防止永久的多客户端XSS攻击。
显然，服务器端代理有一些好处，因为它可以使记录潜在的XSS攻击更容易，但就防止攻击而言，PHP和Javascript似乎都有足够的实用程序。在某些方面，似乎JSONP实际上比简单的<script>标签更安全，因为至少使用JSONP，结果通过一个函数，这意味着它有点过滤，而不仅仅是一致的信任，就像{{1 }}
我有遗失或忽视的风险吗？如果我正确理解了问题，那么使用JSONP从我们信任的来源包含我们信任的文件的内容就没有安全风险。这是一个准确的评估吗？
解
如果两端都是可信的，那么JSONP就没有危险（它基本上只是一个<script>标签）。
Script / JSONP都存在相同的安全漏洞，因为它们是自动执行的，而不是简单地作为数据传输。使用服务器端代理意味着跨域返回作为数据传递，并且可以针对恶意内容进行过滤。如果跨域完全受信任，则JSONP / SCRIPT是安全的，如果存在任何风险怀疑，则将其传递给过滤器代理。
答案 0 :(得分：6)
server-side-proxy和<script>/JSONP之间存在巨大差异。在第一种情况下，您下载数据，在后者下载并自动执行 代码
当您构建服务器端代理时，javascript代码可以使用XmlHttpRequest下载数据。此数据不会自动执行;你必须明确做一些愚蠢的事情，比如eval()，才能让它执行。即使数据格式是JSON而另一台服务器已被泄露，并且您自己的服务器端代理没有发现妥协，您仍然可以使用客户端代码进行防御。例如，您可以使用safe JSON parser解析JSON，并拒绝恶意脚本。
但是当您使用JSONP或<script>标记时，您直接包含其他人的代码。因为它的代码（而不是数据），浏览器会自动执行它，而不会给你机会检查或修改它。
总而言之，服务器端代理为您提供了两条额外的防线 -
答案 1 :(得分：1)
当您控制请求的两端时，大多数传统的安全担心JSONP都不是问题。
您将遇到的另一个问题是某些用户阻止第三方脚本作为安全措施。这也会阻止你的JSONP请求。服务器端代理方法没有这个问题。