JSON 安全最佳实践？

在研究 JSON vs XML的问题时，我偶然发现了 这个问题。现在，选择 JSON 的原因之一被列为易于转换的 Javascript，即与 eval()。从安全的角度来看，这立刻让我觉得有潜在的问题。

因此，我开始对 JSON 的安全性方面进行一些研究，并在这篇博客文章中讨论了 JSON 并不像人们想象的那样安全如何。这部分引人注目:

更新: 如果您正在做 JSON 100% 那么你只有 在顶层的物体。数组, 字符串、数字等都是 然后，JSON 对象将失败 Eval () ，因为 JavaScript 翻译会认为它在看 一个块而不是一个物体 对于防范 这些攻击，但这仍然是最好的 以保护您的安全数据 不可预测的网址。

好的，这是一个很好的开始规则: 顶层的 JSON 对象应该始终是对象，而不是数组、数字或字符串。听起来是个不错的规矩。

当涉及到 JSON 和 AJAX 相关的安全性时，还有什么需要做或避免的事情吗？

上述引用的最后一部分提到了不可预测的 URL。有人有更多关于这方面的信息吗，特别是在 PHP 中是如何做到这一点的？我在 Java 方面比 PHP 更有经验，而且 Java 很简单(因为您可以将所有 URL 映射到单个 servlet) ，而我所做的所有 PHP 都将单个 URL 映射到 PHP 脚本。

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

76832 次浏览
小开

它仍然是 最好的，用不可预测的 URL 保护您的安全数据。

重点是我的。胡说八道！最好的通过适当的身份验证和可能的加密来保护您的安全数据。JSON 交换器仍然可以使用现有的身份验证技术(例如通过 cookie 的会话)和 SSL。

当您使用 JSON 将数据导出到匿名第三方(例如 Web 服务)时，依赖于某些人不猜测 URL (他们实际上在谈论的东西)将只是一种合理的技术(甚至仅仅是合理的技术)。一个例子是谷歌的各种网络服务 API，匿名用户可以通过其他网站访问谷歌数据。他们使用域名引用和 API 密钥来确保中间人网站被允许提供 Google 数据。

如果您只是使用 JSON 向直接的、已知的用户代理发送私有数据，请使用一些真正的身份验证和加密。如果你试图提供一个网络服务，那么它真的取决于如何 “安全”这个数据将是。如果它只是公共数据，你不介意谁可以阅读它，我不明白为什么要做一个模糊的网址。

编辑: 要演示它们的意思，请考虑以下内容。假设您的银行提供了一个用于获取报表的 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

我猜到的可能性要小得多。但是，你真的希望它成为你真正安全的数据和潜在的身份窃贼之间的唯一缓冲区吗？没有。

小开
最佳答案

来自 blog (CSRF)的主要安全漏洞不是特定于 JSON 的。相反，使用 XML 会造成同样大的漏洞。实际上，没有异步调用也一样糟糕; 普通链接也一样脆弱。

当人们谈论唯一的 URL 时，他们通常不是指 http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement。相反，更常见的做法是使请求的其他内容变得惟一; 即 FORM 文章中的值或 URL 参数。

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

数组/对象对我来说是新鲜事:

Script-Tags: 攻击者可以嵌入一个 指向远程服务器的脚本标记 而且浏览器会有效地 Eval ()给你的回复，但是 抛弃了回应 JSON 是所有响应，你是安全的。

在这种情况下，您的站点根本不需要使用 JSON 来保护自己。但是，如果攻击者可以将随机 HTML 插入到您的站点中，那么您就完蛋了。

小开

有许多针对 JSON 的安全性攻击，尤其是 XSRF。

当 Web 服务使用 cookie 进行身份验证，并使用包含敏感数据的 JSON 数组响应 GET 请求时，就会出现漏洞。

如果攻击者可以欺骗登录服务的用户访问他们的网站(或者任何嵌入了他们控制的 IFRAME 的网站，例如通过嵌入式广告) ，那么他们可以在 naive-webapp.com 中插入一个带有 SRC 的 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>
<!-- 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>

EcmaScript 5修复了导致 []在全局对象上查找 Array的混乱行为，许多现代浏览器不再容易受到这种攻击。

顺便说一句，Oil 关于不可预测的 URL 的说法是错误的。URL 中的加密安全随机标识符是保护资源的好方法。基于身份的安全并不像《石油》所说的那样是万灵药。 有关基于 URL 中不需要标识概念的加密安全标识符的安全分布式应用程序方案的示例，请参见 http://waterken.sourceforge.net/。

编辑:

在考虑 JSON 与 XML 时，您还应该注意 XML 特定的攻击向量。

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

<!DOCTYPE root
[
<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini">
]>
...
<in>&foo;</in>

Application 将输入(参数“ in”，其中包含 win.ini 文件)嵌入到 Web 服务响应中。


提交答案