在研究JSON与XML的问题时,我遇到了这个问题.现在,偏好JSON的原因之一被列为Javascript中的转换易用性,即使用eval().从安全角度来看,这立刻让我感到有些问题.
所以我开始对JSON的安全方面进行一些研究,并在博客文章中讨论JSON如何不像人们想象的那样安全.这部分突出:
更新:如果您正确地执行JSON 100%,那么您将只有顶级对象.数组,字符串,数字等都将被包装.然后,JSON对象将无法使用eval(),因为JavaScript解释器会认为它正在查看块而不是对象.这对于防止这些攻击有很长的路要走,但最好用不可预测的URL来保护您的安全数据.
好的,这是一个很好的规则:顶层的JSON对象应始终是对象,而不是数组,数字或字符串.听起来对我来说是一个很好的规则.
在涉及JSON和AJAX相关的安全性时还有什么可做的或避免的吗？
上面引用的最后一部分提到了不可预测的URL.有没有人有更多的信息,特别是你如何在PHP中做到这一点？我在Java方面比PHP更有经验,在Java中它很容易(因为你可以将一系列URL映射到单个servlet),而我所做的所有PHP都已经将一个URL映射到PHP脚本.
另外,您如何使用不可预测的URL来提高安全性？
针对JSON的攻击有很多,特别是XSRF.
当Web服务使用cookie进行身份验证时,会发生此漏洞,并使用包含敏感数据的JSON数组进行响应以响应GET请求.
如果攻击者可以欺骗登录服务的用户naive-webapp.com访问他们的网站(或嵌入他们控制的IFRAME的任何网站,例如通过嵌入式广告),那么他们可以插入 EcmaScript 5修复了导致 顺便提一下,Oil对于不可预测的URL是错误的.URL中的密码安全随机标识符是保护资源的好方法.基于身份的安全性不是石油所暗示的灵丹妙药.有关安全分布式应用程序方案的示例,请参阅http://waterken.sourceforge.net/,该方案基于URL中的加密安全标识符,不需要身份概念. 编辑: 在考虑JSON与XML时,您也应该了解XML特定的攻击向量. XXE,XML外部实体攻击,使用精心设计的XML通过防火墙访问文件系统和网络资源. 应用程序将输入(参数"in",其中包含win.ini文件)嵌入到Web服务响应中.
[]查找Array全局对象的混乱行为,许多现代浏览器不再容易受到这种攻击.
]>
...
博客(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插入您的网站,那么您就是敬酒.
京公网安备 11010802040832号 | 京ICP备19059560号-6 