JSON安全最佳实践？

在研究JSON vs XML的问题时，我碰到了this question。现在，选择JSON的原因之一就是在Javascript中易于转换，即使用eval()。从安全角度来看，这立即引起了我的潜在问题。JSON安全最佳实践？

因此，我开始对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来提高安全性？

来源

2008-12-27 cletus

我不明白这一点！当然，任何由浏览器发出的请求（对任何URL都是不可预测的或不可预测的）都可以通过控制台或一些花哨的GM脚本报告给用户。 – James 2008-12-28 00:38:12

“JSON并不像人们认为的那样安全”已经死了 – inf 2015-04-19 15:39:34

博客（CSRF）的主要安全漏洞不是JSON特有的。用XML代替它就像是一个巨大的漏洞。事实上，根本就没有异步调用一样糟糕;定期的链接也同样脆弱。

当人们谈论唯一的URL时，他们通常并不意味着http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement。相反，将请求的其他内容做成独特的更为常见;即FORM帖子中的值或URL参数。

通常这包括在服务器端插入到表单中的随机令牌，然后在请求发出时进行检查。

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

脚本标签：攻击者可以嵌入脚本标记在远程服务器指出，浏览器将有效的eval（）的回复你，但是它扔掉的回应，因为 JSON是所有的回应，你很安全。

在这种情况下，您的网站根本不需要使用JSON。但是，是的，如果攻击者可以将随机的HTML插入到您的网站中，您就会敬酒。

来源

2008-12-28 04:48:43

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

强调我的。胡说些什么！它的最好保护您的安全数据与一些适当的身份验证，并可能在一些加密。 JSON交换仍然可以使用现有的身份验证技术（例如通过cookie进行会话）和SSL。

当您使用JSON将数据导出到匿名第三方时，依靠没有猜测URL的人（他们实际上在谈论什么）只会是一种合理的技术（甚至只是）。一个Web服务）。 Google的各种Web服务API就是一个例子，匿名用户通过其他网站访问Google数据。他们使用域引用者和API密钥来确保允许中间人网站提供Gooogle数据。

如果您只是使用JSON向直接的已知用户代理发送私人数据，则可以使用一些真实的身份验证和加密。如果你想提供一个web服务，那么它真的取决于如何“安全”这个数据将是。如果它只是公开数据，并且你不介意谁可以阅读它，我不认为制作一个hashy 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

我会少得多的能猜到这样的机会。但是，你真的希望这是真正安全的数据和潜在的身份窃贼之间唯一的缓冲区吗？编号

来源

2008-12-28 00:00:14 Oli

我认为你需要阅读博客的其他部分：除了不可预知的URL之外，他不提倡任何安全性。他所说的是通过cookie的安全性不够，他证明了原因。 – cletus 2008-12-28 00:40:46

针对JSON有一些安全攻击，特别是XSRF。

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

如果攻击者可以欺骗登录服务的用户naive-webapp.com访问他们的站点（或嵌入他们控制的IFRAME的任何站点，例如通过嵌入式广告），那么他们可以插入一个<script>使用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全局对象上，许多现代浏览器都没有这不再容易混淆的行为攻击。

顺便说一句，石油错误的不可预知的URL。密码保护URL中的随机标识符是保护资源的好方法。石油暗示，基于身份的安全并不是万能的。查看http://waterken.sourceforge.net/了解基于URL中不需要身份概念的加密安全标识符的安全分布式应用程序方案的示例。

编辑：

当考虑JSON VS XML，你应该知道XML特定的攻击向量的为好。

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

<!DOCTYPE root 
[ 
<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini"> 
]> 
... 
<in>&foo;</in> 
中的应用嵌入（“在”参数，它包含win.ini文件）输入到web服务的响应。

来源

2009-01-09 23:56:59

JSON安全最佳实践？

回答

相关问题