在研究JSON vs XML的问题时，我遇到了this question。现在，偏好JSON的原因之一被列为Javascript中的转换易用性，即使用eval()。从安全角度来看，这立刻让我感到有些问题。
所以我开始对JSON的安全方面进行一些研究，并在这篇关于如何JSON is not as safe as people think it is的博客文章中进行了研究。这部分突出了：
更新：如果你正在做JSON 100％ 正确的，那么你将只有 顶层的物体。阵列， 字符串，数字等都将是 包裹。然后JSON对象将失败 到eval（）因为JavaScript 口译员会认为它在看 块而不是对象。这个 在很长的路要走 这些攻击，但它仍然是最好的 保护您的安全数据 不可预测的网址。
好的，这是一个很好的规则：顶层的JSON对象应该始终是对象，而不是数组，数字或字符串。听起来对我来说是一个很好的规则。
在涉及JSON和AJAX相关的安全性方面还有什么可做或避免的吗？
上面引用的最后一部分提到了不可预测的URL。有没有人有更多的信息，特别是你如何在PHP中做到这一点？我在Java方面比PHP更有经验，在Java中它很容易（因为你可以将一系列URL映射到单个servlet），而我所做的所有PHP都已经将一个URL映射到PHP脚本。 / p>
另外，您如何使用不可预测的URL来提高安全性？
答案 0 :(得分：53)
有许多针对JSON的安全攻击，尤其是XSRF。
当Web服务使用Cookie进行身份验证时，会发生此漏洞，并使用包含敏感数据的JSON数组进行响应以响应GET请求。
如果攻击者可以欺骗登录服务的用户naive-webapp.com访问他们的网站（或嵌入他们控制的IFRAME的任何网站，例如通过嵌入式广告），那么他们可以插入{{ 1}}使用SRC标记到naive-webapp.com，并可能窃取用户的数据。
这取决于使用JavaScript <script>构造函数的javascript怪癖，如下所示：
Array EcmaScript 5修复了导致 <script>
// Overload the Array constructor so we can intercept data
var stolenArrays = [];
var RealArray = Array;
Array = function () {
var arr = RealArray.apply(arguments);
stolenArrays.push(arr);
return arr;
}
</script>
<!-- even though the attacker can't access the cookies,
- he can cause the browser to send them to naive-webapp.com -->
<script src="//naive-webapp.com/..."></script>
<script>
// now stolenArrays contains any data from the parsed JSON
</script>
在全局对象上查找[]的混乱行为，并且许多现代浏览器不再容易受到此攻击。
顺便说一句，Oil对于不可预测的URL是错误的。 URL中的密码安全随机标识符是保护资源的好方法。基于身份的安全性不是石油所暗示的灵丹妙药。 有关安全分布式应用程序方案的示例，请参阅http://waterken.sourceforge.net/，该方案基于不需要身份概念的URL中的加密安全标识符。
编辑：
在考虑JSON vs XML时，您也应该了解XML特定的攻击向量。
XXE，XML外部实体攻击，使用精心设计的XML通过防火墙访问文件系统和网络资源。
Array应用程序将输入（参数“in”，其中包含win.ini文件）嵌入到Web服务响应中。
答案 1 :(得分：18)
博客（CSRF）的主要安全漏洞并非特定于JSON。使用XML代替它是一个很大的漏洞。实际上，它完全没有异步调用一样糟糕;常规链接同样容易受到攻击。
当人们谈论唯一网址时，通常不代表http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement。相反，在请求中使用其他独特的东西更为常见;即FORM帖子中的值或URL参数。
通常这涉及在服务器端插入FORM中的随机令牌，然后在发出请求时进行检查。
数组/对象对我来说是新闻：
脚本 - 标签：攻击者可以嵌入一个 脚本标记指向远程服务器 并且浏览器将有效 eval（）给你的回复，不过它 抛弃了回应，从那以后 JSON就是所有响应，你是安全的。
在这种情况下，您的网站根本不需要使用JSON来容易受到攻击。但是，如果攻击者可以将随机HTML插入您的网站，那么您就是干杯。
答案 2 :(得分：3)
使用不可预测的网址保护您的安全数据仍然最佳。
强调我的。胡说些什么！ 最佳 通过一些正确的身份验证来保护您的安全数据，并且可能还有一些加密。 JSON交换仍然可以使用现有的身份验证技术（例如，通过cookie进行会话）和SSL。
当你使用JSON将数据导出到匿名的第三方时，依赖于某人不猜一个URL（他们实际谈论的内容）将只是一种合理的技术（当时甚至只是）网络服务）。一个例子是谷歌的各种网络服务API，其中匿名用户通过其他网站访问谷歌数据。他们使用域名引荐来源和API密钥来确保允许中间人网站提供Gooogle数据。
如果您只是使用JSON向直接的已知用户代理发送私有数据，请使用一些真实的身份验证和加密。如果您正在尝试提供Web服务，那么它实际上取决于“安全”这些数据的方式。如果它只是公共数据而您不介意谁可以阅读它，我认为制作一个无用的URL没有意义。
编辑：要证明他们的意思，请考虑这一点。想象一下，您的银行提供了一个用于获取语句的JSON API。如果我可以输入http://yourbank.com/json-api/your-name/statement，您可能不会感到最满意。
他们可以为您的帐户生成任何JSON请求所需的唯一字符串，例如：http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement
我的猜测机会要少得多。但是你真的希望这是你真正安全的数据和潜在身份窃贼之间的唯一缓冲吗？否。