基于HTML5Web前端安全性研究.docVIP

基于HTML5Web前端安全性研究 　　摘要：Web安全的重点正从服务器端转移到Web前端。伴随着HTML5新技术的兴起， Web前端的安全问题更为突出。对传统的Web前端安全问题XSS、CSRF、界面操作劫持进行了阐述，对由HTML5中的新标签属性、Web Workers、Web Storage、postMessage、CSS3等新技术所带来的安全问题进行了全面细致的分析，给出了一系列安全策略。 　　关键词：Web前端；XSS；CSRF；界面操作劫持；HTML5 　　DOIDOI：10.11907/rjdk.161088 　　中图分类号：TP309 　　文献标识码：A 文章编号：1672-7800（2016）005-0185-03 　　0 引言 　　网络安全总是随着时代的变迁而变化的。早期的互联网，Web并非主流应用，因为功能很弱，黑客们往往不屑攻击。随着互联网的发展，Web功能日渐强大，防火墙等技术的应用，使得非Web服务很难被攻击，于是黑客们将攻击重点转向了Web应用。如果说早期Web1.0时代的安全性问题主要体现在操作系统、缓冲区溢出、数据库SQL注入等Web服务器端的话，那么到了Web2.0时代，安全问题就集中在XSS、CSRF、ClickJacking等Web前端。伴随着移动互联的发展，HTML5技术成为大量黑客的目标。所以，本文对于传统的Web前端以及HTML5出现后所带来的安全问题进行了研究和探讨。 　　1 传统的Web前端安全性问题 　　1.1 XSS 　　XSS全称Cross Site Script，中文名跨站脚本攻击，它是指由于黑客往网页中注入了恶意的脚本，从而导致浏览器在呈现页面时执行了非预期的恶意功能。XSS分为3种类型：①反射型XSS，是黑客利用一些社会工程学诱骗用户点击一个恶意链接，服务器直接将这个带有恶意脚本的内容反射给用户的浏览器，从而攻击成功；②存储型XSS，是黑客在自己的浏览器中提交一段带有恶意脚本的留言，这个留言会被服务器保存到数据库中，下次其它用户查看这段留言时就会被攻击；③DOM Base XSS，属于一种特殊的反射型XSS，不需要被服务器端解析响应，直接在浏览器客户端被JavaScript代码解析。下面来看一个典型的反射型XSS。 　　黑客诱骗用户点击了如下一个链接：’免费抽奖。其实XSS不一定要跨站，但是由于为了避免URL地址栏出现太长的JavaScript代码，黑客往往把攻击脚本写在自己网站，例如，xss.js的代码： 　　new Image（）.src=http：///getCookie.aspx？data=+escape（document.cookie）； 　　这样用户的Cookie信息就会被黑客网站盗取。虽然劫持Cookie算是XSS的一个典型应用，但由于JavaScript代码的复杂性，所以XSS理论上可以背着用户进行破坏操作，以GET方式或者POST方式向服务器发送用户不知情的请求。 　　对于XSS的防御方法通常有：①HttpOnly。很多浏览器都支持在HTTP响应头中将HttpOnly设置为True，从而禁止JavaScript访问Cookie，使XSS带来的Cookie 劫持失效；②输入检查。XSS攻击很大程度上是由于没有对用户的输入进行过滤检查造成的，以为用户仅仅输入了数据，而实际很可能在数据中混有代码。输入检查通常使用白名单比黑名单要好，因为黑名单很可能漏掉一些没有考虑周全的情况。输入检查要结合语境，否则会造成误伤，例如数学论坛中正常输入的“标签中或者事件中输出则采用JavaScriptEncode。其它可能的编码还包括XML编码、URL编码、JSON编码等。 　　1.2 CSRF 　　CSRF全称Cross-site request forgery（跨站请求伪造），它是一种与XSS截然不同的攻击方式。XSS利用用户对网站的信任，认为网站输出的内容都是安全的，而CSRF则利用网站对用户的信任，认为是一个合法的用户正在主动提交一个合法的请求。 　　下面介绍一个典型的CSRF攻击案例：用户刚刚登录进入一个购书网站，黑客诱使该用户点击了一个受其控制的页面＼＼csrf.aspx，在这个页面中包含了源代码“”，该购书网站在接受这个请求后以为就是用户本人自愿发出的，同时因为该用户的Cookie认证还没有注销，所以此操作是有效的，于是在用户不知情的情况下就悄悄帮黑客完成了付款购书。 　　对CSRF的防御方法通常有：①验证码。为了区分是用户请求还是伪造请求，采用验证码是对付CSRF简洁有效的方法，但是过多的验证码会影响用户体验，所以只在关键的请求时才使用；②Refer Check[1]。通过查看发出请求的“源”来判断是否可能是CSRF攻击