◆王保锦 林 卉 王健如 李桂青
跨站请求伪造攻击技术浅析
◆王保锦 林 卉 王健如 李桂青
(山东曲阜师范大学(软件学院) 山东 273100)
随着WEB应用逐渐普及,这提升了用户的使用体验,但是随之而来的安全漏洞时刻威胁着服务提供商与用户,引起人们对网络安全问题的关注。本文以“跨站”脚本201D攻击为例,首先对CSRF攻击技术的基本概念进行介绍,分析“跨站”请求伪造攻击原理,复现攻击场景,剖析该类漏洞的利用方法与触发条件。根据“跨站”请求伪造攻击的特点提出三种防御策略,为服务器安全体系结构的设计提供思路。
CSRF攻击;Web应用;“跨站”脚本攻击
近年来,作为网络内容传播和通讯载体的Web应用越来越多。在优化用户体验、提升工作效率的同时,也可能会带来巨大的隐私泄露风险。本文通过使用相关检测工具,模拟攻击场景,评估漏洞风险。从对安全策略、攻击方式的分析中总结经验,为将来开发高效防御应用打下基础。
CSRF(Cross Site Request Forgery),其攻击的目的是伪造用户请求,非法修改数据。受害者访问并登录存在CSRF漏洞的网站后,获得服务器发送的身份信息,携带身份信息访问攻击者制作的攻击页面,攻击页面跨域向原网站提交请求,主流浏览器默认携带受害者的身份信息,存在CSRF漏洞的网站收到请求后,将执行攻击者的请求。
图1 CSRF攻击流程
通过剖析安全策略以及浏览器对安全策略的执行程度,明确如何绕过安全策略,完成CSRF攻击。在真实的应用场景中存在一些安全策略,如cookie策略、同源策略、“跨源”资源共享策略等。本节将对上述安全策略进行分析,找到可能触发CSRF漏洞的部分条件。
同源策略(Same Origin Policy ,SOP),也称为同域策略。浏览器的功能实现基于同源策略。同源策略是指一些动态脚本只被允许访问与之同域名、协议、端口的资源。假设存在域:http://csrftest.com/dir/test.html (默认80端口),在HTML中,一些标签的“src”属性可以跨域请求资源,例如<iframe>、<img>、<svg>。这些标签对资源的加载本质上是对目标资源发送的请求。另外,XMLHttpRequest(XHR)不能跨域请求资源,但它可以访问同源的内容以及提交跨域请求,CSRF攻击正是利用了该特性实施攻击。
HTTP无法保存用户状态,为了提高用户使用体验,出现了cookie技术。cookie分为临时cookie和本地cookie。临时cookie在关闭浏览器后失效,而本地cookie会在到达响应头中expires属性[2]指定的时间后自动失效。主流浏览器如火狐,chrome等在进行跨域资源请求时默认允许携带第三方cookie,为CSRF攻击创造了条件。
“跨源”资源共享(Cross Origin Resouce Sharing ,CORS)是W3C委员会在制定HTML5标准时,为了解决日益增多的“跨站资源请求而提出来的标准。CORS策略将请求分为简单请求和非简单请求[3]。
简单请求:浏览器向网站A发起简单请求,网站A根据自身设置的相关字段的值与请求附带的相关值进行对比,判断是否允许该请求。如果通过验证会返回请求内容,否则“HTTP状态码”置为403。
非简单请求:浏览器不会直接发送用户的跨域请求,而是先发送请求方法为option的预先验证请求,网站B接收到非简单请求后,会通过对请求头的相关字段进行验证决定是否允许此跨域请求。如果验证通过,则浏览器发送跨域请求,否则将“HTTP状态码”置为403。
但是CORS策略也存在安全问题。如果通过XHR对象将WithCredentials属性的值设置为true,Content-Type字段的值设为“multi-part/form-data”的同时,服务器端将“Access-Control-Allow-Credentials”字段的值设置为true,则浏览器会携带cookie直接向服务器发送请求,为CSRF攻击提供了条件。
通过模拟用户操作进行抓包发现,请求方式为GET,携带cookie,可能存在CSRF攻击。编写攻击页面,其中,payload为 通过对目标网站分析,发现TOKEN作为其中一个input标签的属性值隐藏在了表单当中。同时,对留言板界面进行测试,发现如图2所示XSS漏洞: 图2 网站存在存储型XSS漏洞 攻击者首先在留言板写入XSS代码。当用户访问留言板时, XSS代码自动获取当前用户token并向服务器发送请求。 请求头中的referer字段表明了请求来源[4]。通过在服务器端添加对请求头字段的验证拒绝一切“跨站”请求。 通过触发式、嵌入式、字符式验证码易于拦截“跨站”请求伪造攻击。对敏感操作添加随机验证码,验证码强制只有用户与Web应用完成交互后才能实现正常的请求[5]。这种方法防范效率较高,但影响了用户的使用体验。 令牌(token)通常作为一种身份标识,如果来自浏览器请求中的token值与服务器发送给用户的token不匹配或者请求中token不存在,则拒绝该请求。使用token验证可以有效防止CSRF攻击,优化了用户体验。但该方式增加了后端数据处理的工作量。 在HTTP的响应头中,same-site有两种值:strict或lax。当设置为strict时,则表明该服务器发送的cookie值不允许附带在第三方请求中;当设置为lax时,如果请求类型为同步请求且请求方式为GET,则允许此cookie作为请求头的附带信息。将same-site的值设为strict可破坏产生CSRF攻击的必要条件。 本文阐述了CSRF攻击的概念、产生原因、场景以及常见的防御方法。在防范CSRF攻击时,应选择折中的方案,既要优化用户体验,又要考虑服务器性能,达到用户体验与服务器负载的平衡。用户与网络管理员应提高安全意识,避免遭到与XSS、社会工程学结合的CSRF攻击。 [1]徐淑芳.服务器端CSRF防御研究[D].江西师范大学,2014. [2]陈万坡.基于WEB应用程序技术的CSRF攻击与防御技术[D].上海交通大学,2015. [3]Hosee.CORS与CSRF[EB/OL].https://my.oschin a.net/hosee/blog/903665,2017-5-18. [4]陈春艳.“跨站”请求伪造攻击的基本原理与防范[J].电脑知识与技术,2014,10(05):902-904.3.2 基于TOKEN验证的CSRF攻击
4 “跨站”请求攻击防御
4.1 请求头验证
4.2 验证码验证
4.3 token验证
4.4 same-site字段验证
5 结束语