HTML5安全攻防详析之完结篇:HTML5对安全的改进
最后更新于:2022-04-01 19:44:53
HTML5对旧有的安全策略进行了非常多的补充。
**一、iframe沙箱**
HTML5为iframe元素增加了sandbox属性防止不信任的Web页面执行某些操作,例如访问父页面的DOM、执行脚本、访问本地存储或者本地数据库等等。但是这个安全策略又会带来另外的风险,这很有趣,例如[ClickJacking攻击](http://blog.csdn.net/hfahe/article/details/8138728)里阻止JavaScript脚本的运行来绕过JavaScript的防御方式。
**二、CSP内容安全策略**
XSS通过虚假内容和诱骗点击来绕过同源策略。** **XSS攻击的核心是利用了浏览器无法区分脚本是被第三方注入的,还是真的是你应用程序的一部分。CSP定义了Content-Security-Policy HTTP头来允许你创建一个可信来源的白名单,使得浏览器只执行和渲染来自这些来源的资源,而不是盲目信任服务器提供的所有内容。即使攻击者可以找到漏洞来注入脚本,但是因为来源不包含在白名单里,因此将不会被执行。具体内容可以在[我的博客上](http://blog.csdn.net/hfahe/article/details/7727460)了解到。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-08-09_57a9a2e8157e9.jpg)
XSS攻击的原理
**三、XSS过滤器**
Chrome、Safari这样的现代浏览器也构建了安全防御措施,在前端提供了XSS过滤器。例如[http://test.jiangyujie.com/?text=
在Chrome中将无法得到执行,如下图所示。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-08-09_57a9aa57843e2.jpg)
**四、其他**
另外HTML5的应用程序访问系统资源比Flash更受限制。
最后,关于HTML5专门的安全规范目前还在讨论中,有的人希望分散到HTML5规范的各个章节,有的人希望单独列出,目前没有单独的内容,因为不仅要考虑Web App开发者的安全,还要考虑实现HTML5支持的厂商,对它们进行规范和指导。
我个人认为HTML5的安全规范将会有一个统一的章节来进行阐述,并在各个功能模块相应的提及。
结束语:从2012年9月9日开始,“HTML5安全攻防详析”系列连载终于结束了。谢谢大家的支持,今后我将会介绍更多HTML5其他方面的内容。
相关文章:
《[关注HTML5安全风险](http://blog.csdn.net/hfahe/article/details/7960705)》
《[HTML5安全风险详析之一:CORS攻击](http://blog.csdn.net/hfahe/article/details/7961566)》
《[HTML5安全风险详析之二:WebStorage攻击](http://blog.csdn.net/hfahe/article/details/7961618)》
《[HTML5安全风险详析之三:WebSQL攻击](http://blog.csdn.net/hfahe/article/details/8049414)》
《[HTML5安全风险详析之四:Web Worker攻击](http://blog.csdn.net/hfahe/article/details/8104263)》
《[HTML5安全风险详析之五:劫持攻击](http://blog.csdn.net/hfahe/article/details/8138728)》
《[HTML5安全风险详析之六:API攻击](http://blog.csdn.net/hfahe/article/details/8205148)》
《[HTML5安全风险详析之七:新标签攻击](http://blog.csdn.net/hfahe/article/details/8441060)》
《[HTML5安全风险详析之八:WebSocket攻击](http://blog.csdn.net/hfahe/article/details/8507015)》
本文为原创文章,转载请注明:来自[蒋宇捷的博客](http://blog.csdn.net/hfahe)([http://blog.csdn.net/hfahe](http://blog.csdn.net/hfahe))