跨站请求伪造攻击技术浅析

2020-05-11王保锦王健如李桂青

网络安全技术与应用 2020年5期

◆王保锦林卉王健如李桂青

跨站请求伪造攻击技术浅析

◆王保锦林卉王健如李桂青

（山东曲阜师范大学（软件学院）山东 273100）

随着WEB应用逐渐普及，这提升了用户的使用体验，但是随之而来的安全漏洞时刻威胁着服务提供商与用户，引起人们对网络安全问题的关注。本文以“跨站”脚本201D攻击为例，首先对CSRF攻击技术的基本概念进行介绍，分析“跨站”请求伪造攻击原理，复现攻击场景，剖析该类漏洞的利用方法与触发条件。根据“跨站”请求伪造攻击的特点提出三种防御策略，为服务器安全体系结构的设计提供思路。

CSRF攻击；Web应用；“跨站”脚本攻击

近年来，作为网络内容传播和通讯载体的Web应用越来越多。在优化用户体验、提升工作效率的同时，也可能会带来巨大的隐私泄露风险。本文通过使用相关检测工具，模拟攻击场景，评估漏洞风险。从对安全策略、攻击方式的分析中总结经验，为将来开发高效防御应用打下基础。

1 “跨站”请求伪造攻击简介

CSRF（Cross Site Request Forgery），其攻击的目的是伪造用户请求，非法修改数据。受害者访问并登录存在CSRF漏洞的网站后，获得服务器发送的身份信息，携带身份信息访问攻击者制作的攻击页面，攻击页面跨域向原网站提交请求，主流浏览器默认携带受害者的身份信息，存在CSRF漏洞的网站收到请求后，将执行攻击者的请求。

图1 CSRF攻击流程

2 “跨站”请求伪造攻击原因分析

通过剖析安全策略以及浏览器对安全策略的执行程度，明确如何绕过安全策略，完成CSRF攻击。在真实的应用场景中存在一些安全策略，如cookie策略、同源策略、“跨源”资源共享策略等。本节将对上述安全策略进行分析，找到可能触发CSRF漏洞的部分条件。

2.1 同源策略

同源策略（Same Origin Policy ，SOP），也称为同域策略。浏览器的功能实现基于同源策略。同源策略是指一些动态脚本只被允许访问与之同域名、协议、端口的资源。假设存在域：http：//csrftest.com/dir/test.html （默认80端口），在HTML中，一些标签的“src”属性可以跨域请求资源，例如＜iframe＞、＜img＞、＜svg＞。这些标签对资源的加载本质上是对目标资源发送的请求。另外，XMLHttpRequest（XHR）不能跨域请求资源，但它可以访问同源的内容以及提交跨域请求，CSRF攻击正是利用了该特性实施攻击。

2.2 cookie策略

HTTP无法保存用户状态，为了提高用户使用体验，出现了cookie技术。cookie分为临时cookie和本地cookie。临时cookie在关闭浏览器后失效，而本地cookie会在到达响应头中expires属性[2]指定的时间后自动失效。主流浏览器如火狐，chrome等在进行跨域资源请求时默认允许携带第三方cookie，为CSRF攻击创造了条件。

2.3 “跨源”资源共享策略

“跨源”资源共享（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攻击提供了条件。

3 “跨站”请求伪造攻击实现

3.1 基于GET请求的CSRF攻击

通过模拟用户操作进行抓包发现，请求方式为GET，携带cookie，可能存在CSRF攻击。编写攻击页面，其中，payload为

3.2 基于TOKEN验证的CSRF攻击

通过对目标网站分析，发现TOKEN作为其中一个input标签的属性值隐藏在了表单当中。同时，对留言板界面进行测试，发现如图2所示XSS漏洞：

图2 网站存在存储型XSS漏洞

攻击者首先在留言板写入XSS代码。当用户访问留言板时， XSS代码自动获取当前用户token并向服务器发送请求。

4 “跨站”请求攻击防御

4.1 请求头验证

请求头中的referer字段表明了请求来源[4]。通过在服务器端添加对请求头字段的验证拒绝一切“跨站”请求。

4.2 验证码验证

通过触发式、嵌入式、字符式验证码易于拦截“跨站”请求伪造攻击。对敏感操作添加随机验证码，验证码强制只有用户与Web应用完成交互后才能实现正常的请求[5]。这种方法防范效率较高，但影响了用户的使用体验。

4.3 token验证

令牌（token）通常作为一种身份标识，如果来自浏览器请求中的token值与服务器发送给用户的token不匹配或者请求中token不存在，则拒绝该请求。使用token验证可以有效防止CSRF攻击，优化了用户体验。但该方式增加了后端数据处理的工作量。

4.4 same-site字段验证

在HTTP的响应头中，same-site有两种值：strict或lax。当设置为strict时，则表明该服务器发送的cookie值不允许附带在第三方请求中；当设置为lax时，如果请求类型为同步请求且请求方式为GET，则允许此cookie作为请求头的附带信息。将same-site的值设为strict可破坏产生CSRF攻击的必要条件。