JSON安全最佳实践？
在研究JSON和XML的问题的同时，我遇到了这个问题 。 现在，selectJSON的原因之一就是在Javascript中易于转换，即使用eval() 。 从安全的angular度来看，这立即引起了我的问题。
因此，我开始对JSON的安全性方面进行一些研究，并在这篇博文中讨论JSON如何不如人们所想的那样安全 。 这部分突出了：
更新：如果你正在做JSON 100％，那么你将只有顶层的对象。 数组，string，数字等都将被包装。 一个JSON对象然后将不能eval（），因为JavaScript解释器会认为它正在查看一个块而不是一个对象。 这对防范这些攻击有很长的路要走，但最好还是用不可预知的URL来保护您的安全数据。
好吧，这是一个很好的规则：顶层的JSON对象应该始终是对象而不是数组，数字或string。 听起来对我来说是一个很好的规则。
当涉及到JSON和AJAX相关的安全性时，还有什么可以做或者避免的吗？
上面引用的最后部分提到了不可预测的URL。 有没有人有更多的信息，特别是你如何在PHP中做到这一点？ 在Java中，我比PHP更有经验，而且在Java中很容易（因为你可以将一系列的URL映射到一个servlet），而我所做的所有PHP都将一个URL映射到PHP脚本。
另外，您究竟如何使用不可预知的URL来提高安全性？
博客（CSRF）的主要安全漏洞不是JSON特有的。 这是一个使用XML代替的大洞。 事实上，根本就没有asynchronous调用一样糟糕; 定期的链接也同样脆弱。
当人们谈论独特的url时，他们通常并不意味着http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement 。 相反，更为常见的做法是独特的请求。 即FORMpost中的值或URL参数。
通常这涉及在服务器端插入到表单中的随机令牌，然后在发出请求时进行检查。
数组/对象的事情对我来说是新闻：
脚本标记：攻击者可以embedded一个指向远程服务器的脚本标记，浏览器将有效地为你提供eval（）回复，但是它会抛出响应，而且由于JSON都是响应，所以你是安全的。
在这种情况下，您的网站根本不需要使用JSON。 但是，是的，如果攻击者可以在你的网站中插入随机的HTML，你就是敬酒。
有一些针对JSON的安全攻击，特别是XSRF。
当Web服务使用Cookie进行身份validation时，会发生该漏洞，并响应GET请求而响应包含敏感数据的JSON数组。
如果攻击者可以欺骗login到服务的用户naive-webapp.com访问他们的站点（或embedded他们控制的IFRAME的任何站点，例如通过embedded式广告），那么他们可以插入<script>标签一个SRC到naive-webapp.com，并潜在地窃取用户的数据。 这取决于JavaScript怪异的JavaScript Array构造如下：
<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中的随机标识符是保护资源的好方法。 基于身份的安全不是石油build议的万能药。 有关安全分布式应用程序scheme的示例，请参阅http://waterken.sourceforge.net/ ，该scheme基于URL中不需要身份概念的encryption安全标识符。
编辑：
在考虑使用JSON和XML时，您应该了解XML特定的攻击向量。
XXE ，XML外部实体攻击，使用精心devise的XML通过防火墙访问文件系统和networking资源。
<!DOCTYPE root [ <!ENTITY foo SYSTEM "file:///c:/winnt/win.ini"> ]> ... <in>&foo;</in>应用程序将input（参数“in”，其中包含win.ini文件）embedded到Web服务响应中。
用不可预知的URL保护您的安全数据仍然是最好的select。
强调我的。 胡说些什么！ 最好是用一些适当的身份validation来保护你的安全数据，并且可能还有一些encryptionfunction。 JSON交换仍然可以使用现有的身份validation技术（例如通过cookie的会话）和SSL。
当你使用JSON将数据导出到匿名第三方（例如Web服务）时，依赖于不猜测URL的人（他们实际上在谈论什么）将只是一个合理的技术（甚至只是） 。 Google的各种networking服务API就是一个例子，匿名用户通过其他网站访问Google数据。 他们使用域引用和API密钥来确保允许中间人网站提供Gooogle数据。
如果您只是使用JSON向直接的已知用户代理发送私人数据，请使用一些真实的身份validation和encryption。 如果你想提供一个web服务，那么这真的取决于这个数据的安全性 。 如果只是公开的数据，你不介意谁可以阅读，我不认为做一个hashyurl的重点。
编辑：为了展示他们的意思，考虑这个。 想象一下，您的银行提供了用于获取对账单的JSON API。 如果我只能inputhttp://yourbank.com/json-api/your-name/statement ，你可能不会很高兴。
他们可以为您的帐户生成一个唯一的string，这个string在任何JSON请求中都是必需的，例如：http: http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement
我会有更less的机会猜测。 但是，你真的希望这是真正安全的数据和潜在的身份窃贼之间唯一的缓冲区吗？ 没有。
