我想在 Java EE 中实现 Web 服务，其响应将是 JSON。这是我第一次尝试这样做，但在此之前我只想知道 JSON 是否存在任何安全问题，因为在我读过的许多博客中到处都提到了“与 XML 相比，JSON 不安全”。JSON 有几个优点，例如易于使用、速度更快。
所以任何人都可以向我解释 JSON 是否真的不安全。如果是这样，为什么会这样。请举例说明。
有几篇关于这个主题的旧文章：
JSON 与 XML - 2006
evalArray通过浏览器破解 JavaScript 的劫持解析。这是无稽之谈。两者都是结构json化xml数据的表示方法。它们中的任何一个都不能被视为“更安全”或“更不安全”。
JSON 和 XML 在安全方面没有区别。人们提到的关于 JSON 的“不安全感”与 JSON 可以（但绝不应该）在 Javascript 中解析的方式有关。
JSON 基于用于在 javascript 中编码对象的语法，因此在 javascript 中评估 JSON 结果会返回一个有效对象。
这可能会向各种 javascript 注入漏洞打开 JSON。
解决此问题的方法：不要使用 eval() 在 javascript 中解析 JSON，使用 JSON 解析器并修复服务器中允许在响应中未转义的用户生成内容的任何安全问题。
两者都没有安全优势。这两种格式都旨在为发送数据提供一个简单的协议，并且默认情况下都不使用加密（您可以自己添加一些东西）。JSON通常被认为更快，因为它需要更少的字符来组装。它也很容易在 中使用JavaScript，因为JSON它只是JavaScript Object Notation，并且所有 JavaScript 对象都可以转换为 JSON 表示或从 JSON 表示转换。
许多（尤其是较新的）开发人员更喜欢使用XML它，因为它的可读性。它的结构使得人类更容易阅读它。这当然是它比 JSON 更庞大的原因，但它的安全性丝毫不逊色。
这些传输协议可能导致的漏洞是解析错误的结果。开放网络上的服务解析器不能简单地假设数据是有效的，因为这可能会导致诸如代码注入之类的攻击——但这与 JSON 或 XML 无关。
这两种格式都代表数据，因此安全性没有区别，我多年来一直使用 JSON 并且从未遇到任何安全问题。
JSON 和 XML 都用作服务器客户端通信的媒介。那么，为什么一个安全问题而不是另一个呢？
根本区别在于，顾名思义，JSON（JavaScript 对象表示法）与 JavaScript 非常接近和亲爱，因此在设计一些 JavaScript 方法和功能时，JavaScript 将 JSON 字符串视为一杯茶并尝试直接解释它，这给出了攻击者的变通方法是欺骗 JavaScript 解释器以运行嵌入在字符串中的恶意 JavaScript，从而导致漏洞，而 XML 必须经过解析阶段才能被解析为对象，从而使其更难攻击。2 个这样的 JavaScript 功能是 eval() 方法和标记。
这些如何造成安全漏洞？
虽然 web 遵循同源策略，但历史上也发现了绕过它的漏洞，恶意网站利用它们向经过身份验证的用户网站发送跨站点请求，破坏了同源策略的意图。
示例：尽管有同源策略，但 web 允许一些标签，如<img> <script>发出跨源 GET 请求。
假设您在一个网站上www.authenticatedwebsite.com，但被引诱打开一个www.malicious.com在其 html 中包含标签的
网站<script src="www.authenticatedwebsite.com/get-user-order-history" />
攻击者www.malicious.com使用此脚本标记行为从 www.authenticatedwebsite.com.
现在，调用 src url 的脚本标签如何将 url 响应存储到 javascript 对象[以执行将其发布到恶意站点服务器等操作]？
JSON和 XML 的作用在这里被证明是更安全的。由于 JavaScript 可以很好地理解 JSON，一些 JavaScript 解释器将裸 JSON 字符串解释为有效的 JavaScript 并运行它。
运行 JSON 字符串可能会做什么，因为它仍未分配给变量？
这可以通过另一个花哨的 hack 来实现。如果返回的 JSON 字符串表示一个数组。JavaScript 将尝试运行 Array 类的构造函数。现在可以在 JavaScript 中重写 Array 的构造函数了。您可以执行以下操作：
Array = function(){ yourObject = this };
这基本上是覆盖 JavaScript 数组构造函数，这样每当 JavaScript 调用构造函数时，当前解释的数组就会分配给 yourObject，从而使恶意网站可以访问您的私有数据。
现在，这种攻击可以与 JSON 字符串的变体一起使用，并具有更复杂的黑客攻击。
尽管上面代表了一个有效的场景，其中 JSON 作为 GET API 的返回格式可能很危险。这实际上仅在某些浏览器的某些版本中是可能的，据我所知，所有现代版本的著名浏览器都已缓解它，但是由于您的用户群可以跨浏览器版本划分，因此您需要小心 GET API以裸 JSON 格式提供私人信息。
用来规避这种情况的一种技术是在 JSON 响应字符串前面添加一个 while(true)，这将永远不允许 JavaScript 解释器访问实际的字符串。但它会在您的客户端产生解析开销。
JSON 可能导致的另一个可能的事故eval()是在浏览器客户端使用方法来解析 JSON。由于eval()具有运行脚本的能力，如果您的 JSON 字符串包含一些隐藏的脚本，这些脚本eval()运行并执行攻击者注入的脚本要求它执行的危险操作，则可能证明您的系统存在安全问题。eval()但正如其他人所提到的，通过在客户端代码中的任何地方严格放弃作为 JSON 解析器的方法，可以轻松防止这种攻击。此漏洞插件对于存储用户生成内容的网站非常重要。
这篇文章很好地比较了两种数据共享格式中发现的安全问题。它甚至有代码片段解释了如何攻击常见的漏洞，如 XXE 和 DTD 验证。然后它展示了如何修复/强化这些安全问题，以便可以安全地使用 XML 和 JSON。
https://blog.securityevaluators.com/xml-vs-json-security-risks-22e5320cf529
在安全性方面，默认配置的 XML 解析器对 XXE 注入攻击和 DTD 验证攻击是开放的，因此如果使用 XML 数据交换，则需要加强。
另一方面，JSON 在其默认状态下本身是安全的，但是一旦 JSONP 被用来绕过同源策略限制（CSRF 攻击），它就会变得容易受到攻击，因为：
它允许跨域数据交换。
作者在这里总结了对比：
在安全性方面，处理不受信任的面向 Internet 的请求是 XML 或 JSON 解析器最基本的功能之一。不幸的是，常见的 XML 解析器在其默认配置中不适合此目的。只有通过强化禁用外部实体扩展和外部 DTD 验证，它们才是安全的。相反，JSON 解析几乎总是安全的，只要程序员使用现代技术而不是 JSONP。只要 Web 开发人员意识到这些安全风险并采取措施防范它们，任何一种选择在当前的 Web 环境中都是完全可行的。