基于HTML5的Web前端安全性研究Word格式.docx
- 文档编号:16208444
- 上传时间:2022-11-21
- 格式:DOCX
- 页数:6
- 大小:21.64KB
基于HTML5的Web前端安全性研究Word格式.docx
《基于HTML5的Web前端安全性研究Word格式.docx》由会员分享,可在线阅读,更多相关《基于HTML5的Web前端安全性研究Word格式.docx(6页珍藏版)》请在冰豆网上搜索。
文献标识码:
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.1XSS
XSS全称CrossSiteScript,中文名跨站脚本攻击,它是指由于黑客往网页中注入了恶意的脚本,从而导致浏览器在呈现页面时执行了非预期的恶意功能。
XSS分为3种类型:
①反射型XSS,是黑客利用一些社会工程学诱骗用户点击一个恶意链接,服务器直接将这个带有恶意脚本的内容反射给用户的浏览器,从而攻击成功;
②存储型XSS,是黑客在自己的浏览器中提交一段带有恶意脚本的留言,这个留言会被服务器保存到数据库中,下次其它用户查看这段留言时就会被攻击;
③DOMBaseXSS,属于一种特殊的反射型XSS,不需要被服务器端解析响应,直接在浏览器客户端被JavaScript代码解析。
下面来看一个典型的反射型XSS。
黑客诱骗用户点击了如下一个链接:
’>
免费抽奖。
其实XSS不一定要跨站,但是由于为了避免URL地址栏出现太长的JavaScript代码,黑客往往把攻击脚本写在自己网站,例如,xss.js的代码:
newImage().src=http:
//
这样用户的Cookie信息就会被黑客网站盗取。
虽然劫持Cookie算是XSS的一个典型应用,但由于JavaScript代码的复杂性,所以XSS理论上可以背着用户进行破坏操作,以GET方式或者POST方式向服务器发送用户不知情的请求。
对于XSS的防御方法通常有:
①HttpOnly。
很多浏览器都支持在HTTP响应头中将HttpOnly设置为True,从而禁止JavaScript访问Cookie,使XSS带来的Cookie劫持失效;
②输入检查。
XSS攻击很大程度上是由于没有对用户的输入进行过滤检查造成的,以为用户仅仅输入了数据,而实际很可能在数据中混有代码。
输入检查通常使用白名单比黑名单要好,因为黑名单很可能漏掉一些没有考虑周全的情况。
输入检查要结合语境,否则会造成误伤,例如数学论坛中正常输入的“标签中或者事件中输出则采用JavaScriptEncode。
其它可能的编码还包括XML编码、URL编码、JSON编码等。
1.2CSRF
CSRF全称Cross-siterequestforgery(跨站请求伪造),它是一种与XSS截然不同的攻击方式。
XSS利用用户对网站的信任,认为网站输出的内容都是安全的,而CSRF则利用网站对用户的信任,认为是一个合法的用户正在主动提交一个合法的请求。
下面介绍一个典型的CSRF攻击案例:
用户刚刚登录进入一个购书网站,黑客诱使该用户点击了一个受其控制的页面\\csrf.aspx,在这个页面中包含了源代码“”,该购书网站在接受这个请求后以为就是用户本人自愿发出的,同时因为该用户的Cookie认证还没有注销,所以此操作是有效的,于是在用户不知情的情况下就悄悄帮黑客完成了付款购书。
对CSRF的防御方法通常有:
①验证码。
为了区分是用户请求还是伪造请求,采用验证码是对付CSRF简洁有效的方法,但是过多的验证码会影响用户体验,所以只在关键的请求时才使用;
②ReferCheck[1]。
通过查看发出请求的“源”来判断是否可能是CSRF攻击,不过这种方法不是很准确;
③Token[2]。
黑客之所以能够伪造用户请求发出CSRF攻击,是因为可以猜测到请求中的参数值。
基于这个思路,在客户端的表单隐藏域控件(POST提交)或者URL中追加一个随机的Token密钥,在服务器端验证这个密钥是否与保存在Session或者Cookie中的Token密钥一致,如果不一致就很可能是CSRF攻击。
1.3界面操作劫持
界面操作劫持[3]通过在网页的可见输入控件上覆盖一个不可见的框,使用户误以为在操作可见控件,而实际上操作的是不可见框中的控件,从而被攻击。
这种攻击主要利用了CSS中的opacity、position、z-index属性,以及iframe框架技术,这种攻击对美工基础要求较高。
防御界面操作劫持主要是避免嵌入iframe框,通常可以编写一段JavaScript代码,或者在请求报文头中设置X-Frame-Options属性为DENY来禁止内嵌iframe框。
2HTML5安全性问题
2.1HTML5加剧了Web前端危险
部分Web前端的安全性问题可能并不是HTML5本身所带来的,但是HTML5的出现加剧了在传统Web前端中本已经存在的安全性问题。
2.1.1新标签和新属性绕过黑名单策略
对付传统XSS攻击的一个重要方法就是输入检查。
很多网站出于简单方便选用了黑名单,黑客可以利用HTML5中的一些新标签和新属性绕过这些黑名单[4]。
例如在有XSS漏洞的页面注入以下代码(这里因为是示例,使用了弹出对话框,实际攻击中将被替换为真正具有攻击性的代码):
虽然白名单的正则表达式书写要求很严格,但还是建议开发人员优先考虑白名单,如果一定要用黑名单则要将HTML5中这些新标签和新属性考虑进去。
2.1.2隐藏URL中的恶意代码
在XSS攻击中,往往要利用一些社会工程学诱骗用户点击一个恶意链接,如果恶意链接的URL很长,且明显有JavaScript代码,例如这样的恶意链接:
http:
2.1.3界面操作劫持中拖放劫持
界面操作劫持原本是传统Web前端攻击中的一种典型方式,早期主要表现为点击劫持。
随着HTML5对支持拖放操作的API函数增多,拖放劫持攻击也发展迅速[5]。
拖放劫持是攻击者诱使用户从隐藏不可见的iframe中拖拽出希望得到的数据,然后放到攻击者能控制的另一个页面中窃取数据。
由于浏览器中拖放操作是不受“同源策略”限制的,用户可以把一个域的内容拖放到另一个不同的域。
这种劫持技术通常可以窃取到URL链接中的sessionid、token、password等敏感信息。
2.2HTM5本身所带来的Web前端危险
2.2.1CORS攻击
CORS全称CrossOriginResourceSharing,中文全名为跨源资源共享[6]。
浏览器的同源策略限制了跨域访问,但实际业务中有时有跨域需求,HTML5的技术标准中就引入了CORS,其具体含义是如果站点要跨域向站点发出请求,只要站点的HTTP头部设置有Access-Control-Allow-Origin:
//即可。
这个技术在给开发者带来了方便的同时也带来了安全隐患。
例如:
攻击者首先通过页面的XSS漏洞向用户页面注入恶意代码,使用户的客户端向攻击者能够控制的服务器发送跨域的Ajax请求,只要该服务器head头部里Access-Control-Allow-Origin包含有当前客户端的访问域名,就可以对客户端返回。
然后,攻击者就可以把客户端执行的操作代码返回执行。
这时用户很可能正处于登录状态,攻击者就可以冒充用户的身份执行一些恶意操作。
另外,即使攻击者的服务器不设置Access-Control-Allow-Origin,用户客户端的隐私数据也可以发送到攻击者的服务器,只是用户的客户端无法接受返回报错而已。
防御CORS攻击较好的方式是:
对跨域访问不完全依赖HTTP头来控制,因为HTTP头部也可以伪造,还应该进行一些身份验证,例如验证Cookie、SessionID等。
2.2.2WebWorkers
HTML5的WebWorkers可以让Web程序具备后台处理能力,并且支持多线程。
虽然这个技术不会导致浏览器的UI停止响应,但是过多的线程会耗掉大量的CPU资源。
黑客对有XSS漏洞的页面循环构建大量的线程使用户系统变慢,而在后台运行的用户很难察觉;
或者构建大量的恶意请求到目标服务器,发起一次拒绝服务。
如果同时结合前面讲的CORS技术和Web蠕虫,将会把用户的浏览器变成僵尸节点[3],继续感染其它用户,并对目标服务器发起DDOS攻击。
2.2.3WebStorage
HTML5中提供了WebStorage技术,可以存储至少5M的数据,大大提高了Web访问性能,但与此同时也带来了安全隐患[7]。
如果说Cookie还可以通过HTTP响应头中将HttpOnly设置为True,从而禁止JavaScript访问来加以保护的话,WebStorage则会直接暴露给JavaScript代码。
页面只要存在XSS漏洞,黑客就可一方面把大量的恶意代码本身,例如Web蠕虫代码存储在这个至少5M的空间中,另一方面窃取WebStorage中的敏感信息。
WebStorage分为临时本地存储sessionStorage和永久本地存储localStorage。
localStorage的安全隐患更大一些,因为一方面localStorage存储没有路径概念,容易遭到跨目录攻击,另一方面它没有设置过期时间,意味着如果用户不主动删除,数据将永久存在。
2.2.4POSTMessage
HTML5提供了一种称为PostMessageAPI的跨文档消息机制,它不受同源策略的限制,可以很方便地实现跨域通信。
这里要确认3个问题:
①消息的接受者是否可靠?
②消息的发送源是否可信?
③消息本身的内容是否篡改或含有恶意代码。
不能确定这些问题的话就很可能被中间人攻击,即攻击者从发送方截获到敏感消息,篡改后再冒充发送方发送给原来的接收方[8]。
上面这些代码包含如下安全隐患:
首先,发送方将targetOrigin设置为通配符“*”时,将会导致攻击者伪造接受者,所以建议将该参数设为具体的接受者服务器;
其次,接收方没有对发送方的身份进行验证,例如加上if(e.origin!
==“http:
//”)return;
这将导致黑客冒充发送者;
最后,接收方没有对消息内容检查过滤,直接以innerHTML属性来赋值,这样很容易被攻击,所以建议将innerHTML属性修改为textContent。
2.2.5CSS3
一直以来JavaScript扮演着Web前端攻击的重要角色,但其实CSS使用不当同样会带来安全隐患。
前面提到的界面操作劫持就主要利用了CSS中的opacity、position、z-index属性。
以前出现过利用CSS的visited伪类选择器来窃取用户访问历史表的案例,例如:
用这种方法可以判断该值是否是a字符开头,如果不是则继续判断是否是其它字符。
确定了第一位之后再继续判断第二位字符、第三位字符。
尽管这种方式很繁琐,但理论上是可以窃取到表单的value值的。
对于CSS攻击的防范主要是尽量限制用户自定义CSS权限,如果一定要允许用户自定义CSS,则要进行严格的输入检查,尤其要过滤掉style等关键字。
HTML5所带来的安全隐患不止上述,还包括很多其它方面,例如,地理位置API带来的隐私泄露、WebSocket被滥用后带来的后门通信、Canvas画布带来的缓冲区溢出、WebSQL带来的客户端SQL注入攻击等[9]。
3结语
本文针对基于HTML5的Web前端安全问题进行了分析,提出宏观总体上要从多个角度加以防御的思路。
浏览器厂商内置了一些安全策略,例如,几乎所有浏览器都支持同源策略,限制了不同源的脚本跨域执行;
又如部分浏览器支持的Sandbox技术,让不受信任的代码运行在受限制的环境中;
还有部分浏览器支持多进程架构,对浏览器崩溃进行了保护;
更有部分浏览器甚至加入了恶意网址拦截功能。
但这些工作还不够,浏览器还应从HTTP响应头入手,推行CSP技术[3],使得HTML、CSS、JavaScript的加载更加独立安全。
另外,对于网站开发者来说,需要熟悉XSS、CSRF、界面操作劫持等常规的Web前端攻击方式和防御方法,对Cookie、Flash、AJAX等技术应谨慎使用,同时对HTML5带来的新的安全问题也要足够重视。
对网民来说,应该选择安全的浏览器,加强网络安全意识,不要轻易点击来路不明的超链接。
对于敏感信息的输入尤其要谨慎,尽量不要长时间保存在客户端。
参考文献:
[1]BILLYHOFFMAN,BRYANSULLIVAN.Ajax安全技术[M].张若飞,王铮,译.北京:
电子工业出版社,2009.
[2]吴翰清.白帽子讲Web安全[M].北京:
电子工业出版社,2012.
[3]钟晨鸣,徐少培.Web前端黑客技术揭秘[M].北京:
电子工业出版社,2013.
[4]华晨,施化吉.客户端HTML5的安全研究[J].电子设计工程,2012,22(22):
11-13.
[5]张剑,陈剑锋,王强.HTML5新特性及其安全性研究[J].信息安全与通信保密,2013(5):
87-89.
[6]董霁,杨丁宁,史德年.基于HTML5技术的移动智能终端应用及安全问题研究[J].现代电信科技,2012(12):
1-7.
[7]王荣国.HTML5带来的Web应用变革及安全问题研究[J].电脑开发与应用,2012,25(7):
65-67.
[8]李潇宇,张玉清,刘琦旭,等.一种基于HTML5的安全跨文档消息传递方案[J].中国科学院研究生院学报,2013,30
(1):
124-130.
[9]孙松伯,ALIABBASI,诸葛建伟,等.HTML5安全研究[J].计算机应用与软件,2013,30(3):
2-6.
(责任编辑:
杜能钢)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 HTML5 Web 前端 安全性 研究
![提示](https://static.bdocx.com/images/bang_tan.gif)