我想在Java EE中实现Web服务，其响应将是一个JSON。这是我第一次尝试这样做但在此之前我只是想知道JSON是否存在任何安全问题，因为在我阅读的许多博客中都提到了类似“JSON与XML相比不安全”。 JSON具有易用，速度快等优点。
所以任何人都可以向我解释JSON是否真的不安全。如果是这样的话。请举例说明。
关于这个主题有几篇旧文章：
JSON vs XML - 2006
eval JSON is not as safe as people think it is
Array黑客通过浏览器解析JavaScript解析。答案 0 :(得分：23)
这是胡说八道。 json和xml都只是表示结构化数据的方法。它们都不能被视为“更安全”或“安全性更低”。
答案 1 :(得分：10)
JSON和XML之间的安全性没有区别。人们提到的关于JSON的“不安全感”与JSON可以（但绝不应该）在Javascript中解析的方式有关。
JSON基于javascript中编码对象的语法，因此在javascript中评估JSON结果会返回一个有效的对象。
这可能会为各种javascript注入攻击打开JSON。
解决此问题的方法：不要使用eval（）来解析javascript中的JSON，使用JSON解析器并修复服务器中允许在响应中使用未转义的用户生成内容的任何安全问题。
答案 2 :(得分：4)
没有更安全的版本。还有其他功能需要考虑：
使用java，php还是perl并不重要。他们都可以解析json和xml。 json是轻量级的，但xml可以处理更多。我会说，从json开始，除非您确实需要xml的功能。
答案 3 :(得分：2)
这两种格式都代表数据，因此安全性没有区别，我多年来一直使用JSON，从未遇到任何安全问题。
答案 4 :(得分：2)
与其中一个或另一个没有任何安全优势。这两种格式都是为了提供一个简单的数据发送协议，默认情况下都不使用加密（你可以自己添加一些东西）。 JSON通常被认为更快，因为它需要较少的字符来组装。它也很容易在JavaScript中使用，因为JSON只是 JavaScript Object Notation ，并且所有JavaScript对象都可以转换为JSON表示或从JSON表示转换。
由于其可读性，许多（尤其是较新的）开发人员更喜欢使用XML。它的结构使得人们更容易阅读它。这当然是使它比JSON更庞大的原因，但它绝不是那么安全。
这些传输协议可能导致的漏洞是解析错误的结果。在开放网络上进行服务的解析器不能简单地假设数据是有效的，因为这可能导致诸如代码注入之类的攻击 - 但这与JSON或XML无关。
答案 5 :(得分：0)
这篇文章很好地比较了两种数据共享格式中的安全问题。它甚至还有代码片段，解释了如何在诸如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验证才是安全的。相反，只要程序员使用现代技术而不是JSONP，JSON解析几乎总是安全的。只要Web开发人员意识到这些安全风险并采取措施来抵御它们，任何一种选择在当前的Web环境中都是完全可行的。
答案 6 :(得分：0)
JSON和XML都可以作为服务器客户端通信的媒介。那么，为什么安全问题只涉及一个而不是其他？
根本区别在于JSON（JavaScript Object Notation）顾名思义非常接近JavaScript，因此在设计一些JavaScript方法和功能时，JavaScript将JSON字符串视为一杯茶，并试图直接解释它，它为攻击者提供了解决方法来欺骗JavaScript解释器来运行嵌入在字符串中的恶意JavaScript，从而导致漏洞，而XML必须通过解析阶段才能被解析为一个对象，使其更难攻击。 2这样的JavaScript功能是eval（）方法和标记。
这些如何造成安全漏洞？
虽然网络遵循同源政策，但历史上已发现漏洞绕过它并且恶意网站使用它们向经过身份验证的用户网站发送跨站点请求，打破了同源的意图政策。
示例：
尽管存在同源策略，但Web允许某些标签（如<img> <script>）进行跨源GET请求。
让我们说你在一个网站www.authenticatedwebsite.com上，但是被诱骗打开一个{h}中有标签的www.malicious.com
<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字符串的可能做什么，因为它仍未分配给变量？
这可以通过另一个花哨的黑客来实现。 如果返回的JSON字符串表示数组。 JavaScript将尝试运行Array类的构造函数。现在可以在JavaScript中覆盖Array的构造函数。你可以这样做：
Array = function(){ yourObject = this };
这基本上覆盖了JavaScript Array构造函数，这样每当JavaScript调用构造函数时，当前解释的数组都会分配给yourObject，从而使恶意网站可以访问您的私有数据。
现在，这种攻击可以与JSON字符串的变体一起使用，具有更复杂的黑客攻击。
尽管上面代表了一个有效的场景，但JSON作为GET API的返回格式可能会很危险。这实际上只适用于某些浏览器的某些版本，据我所知，所有现代版本的着名浏览器都可以缓解它，但由于您的用户群可以跨浏览器版本划分，因此您需要小心使用GET API以裸JSON格式发布私人信息。
用于规避此问题的技巧之一是在JSON响应字符串前添加一段时间（true），这将永远不允许JavaScript解释器到达实际字符串。但它会在您的客户端创建解析开销。
JSON可能导致的另一个可能的错误是在浏览器客户端使用eval()方法来解析JSON。由于eval()具有运行脚本的能力，如果您的JSON字符串包含一些eval()运行并执行危险操作的隐藏脚本，攻击者注入脚本要求它执行操作，可以证明您的系统存在安全问题。但正如其他人所提到的，通过严格放弃eval()方法作为客户端代码中的JSON解析器，可以轻松防止此攻击。此漏洞插件对于存储用户生成内容的网站非常重要。