JSON安全最佳实践？-Java 学习之路

在研究JSON vs XML的问题时，我遇到了this question . 现在，偏好JSON的原因之一被列为Javascript中的转换易用性，即 eval() . 从安全角度来看，这立刻让我感到有些问题 .

所以我开始对JSON的安全方面进行一些研究，并在博客文章中介绍了如何JSON is not as safe as people think it is . 这部分突出：

更新：如果您正确地执行JSON 100％，那么您将只有顶级对象 . 数组，字符串，数字等都将被包装 . 然后，JSON对象将无法使用eval（），因为JavaScript解释器会认为它正在查看块而不是对象 . 这对于防止这些攻击有很长的路要走，但最好用不可预测的URL来保护您的安全数据 .

好的，这是一个很好的规则：顶层的JSON对象应始终是对象，而不是数组，数字或字符串 . 听起来对我来说是一个很好的规则 .

在涉及JSON和AJAX相关的安全性时还有什么可做的或避免的吗？

上面引用的最后一部分提到了不可预测的URL . 有没有人有更多的信息，特别是你如何在PHP中做到这一点？我在Java方面比PHP更有经验，在Java中它很容易（因为你可以将一系列URL映射到单个servlet），而我所做的所有PHP都已经将一个URL映射到PHP脚本 .

另外，您如何使用不可预测的URL来提高安全性？

3 回答

53
针对JSON的攻击有很多，特别是XSRF .

当Web服务使用cookie进行身份验证时，会发生此漏洞，并使用包含敏感数据的JSON数组进行响应以响应GET请求 .

如果攻击者可以欺骗登录服务的用户naive-webapp.com访问他们的网站（或嵌入他们控制的IFRAME的任何网站，例如通过嵌入式广告），那么他们可以插入带有SRC的 <script> 标签到naive-webapp.com，并可能窃取用户的数据 . 这取决于JavaScript Array 构造函数的javascript怪癖，如下所示：
```
<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>
 
 <script src="//naive-webapp.com/..."></script>
 <script>
   // now stolenArrays contains any data from the parsed JSON
 </script>
```
EcmaScript 5修复了导致 [] 在全局对象上查找 Array 的混乱行为，并且许多现代浏览器不再容易受到此攻击 .

顺便提一下，Oil对于不可预测的URL是错误的 . URL中的密码安全随机标识符是保护资源的好方法 . 基于身份的安全性不是石油所暗示的灵丹妙药 . 有关安全分布式应用程序方案的示例，请参阅http://waterken.sourceforge.net/，该方案基于URL中的加密安全标识符，不需要身份概念 .

编辑：

在考虑JSON与XML时，您也应该了解XML特定的攻击向量 .

XXE，XML外部实体攻击，使用精心设计的XML通过防火墙访问文件系统和网络资源 .

<！DOCTYPE root
[
<！ENTITY foo SYSTEM“file：/// c：/winnt/win.ini”>
]>
...
<在>＆FOO; </在>
应用程序将输入（参数“in”，其中包含win.ini文件）嵌入到Web服务响应中 .
回复于 2024-04-20T07:59:40+08:00
3

博客（CSRF）的主要安全漏洞不是JSON特有的 . 使用XML代替它是一个很大的漏洞 . 实际上，它完全没有异步调用一样糟糕;常规链接同样容易受到攻击 .

当人们谈论唯一的URL时，他们通常不是指http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement . 相反，在请求中使用其他独特的东西更为常见;即FORM帖子中的值或URL参数 .

通常这涉及在服务器端插入FORM中的随机令牌，然后在发出请求时进行检查 .

数组/对象对我来说是新闻：

脚本标签：攻击者可以嵌入一个指向远程服务器的脚本标签，浏览器将有效地为您回复eval（），但是它会丢弃响应，因为JSON都是响应，所以您是安全的 .

在这种情况下，您的站点根本不需要使用JSON来容易受到攻击 . 但是，如果攻击者可以将随机HTML插入您的网站，那么您就是敬酒 .

回复于 2024-04-20T07:59:40+08:00
18

使用不可预测的URL保护您的安全数据仍然是最好的 .

强调我的 . 胡说些什么！这是 best 用一些适当的身份验证来保护您的安全数据，并且可能还有一些加密 . JSON交换仍然可以使用现有的身份验证技术（例如，通过cookie的会话）和SSL .

依赖某人不猜猜URL（当他们使用JSON将数据导出到匿名第三方（例如Web服务）时，他们正在有效地讨论的内容）将只是一种合理的技术（即便如此） . 一个例子是谷歌的各种网络服务API，其中匿名用户通过其他网站访问谷歌数据 . 他们使用域名引荐来源和API密钥来确保允许中间人网站提供Gooogle数据 .

如果您试图提供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

我的猜测能力要小得多 . 但是你真的希望这是你真正安全的数据和潜在身份窃贼之间的唯一缓冲吗？没有 .

回复于 2024-04-20T07:59:40+08:00

JSON安全最佳实践？

3 回答

相关问题