Appscan漏洞之跨站点请求伪造（CSRF）

　　公司前段时间使用了Fortify扫描项目代码，在修复完这些Fortify漏洞后，最近又启用了Appscan对项目代码进行漏洞扫描，同样也是安排了本人对这些漏洞进行修复。现在，针对修复过的Appscan漏洞也一一总结一下。本次先对 Cross-site request forgery（跨站请求伪造） 漏洞进行总结如下：

1、跨站点请求伪造（CSRF）

1.1、攻击原理

　　CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS是由于放任来自浏览器的输入任意执行导致了，而CSRF则是因为过分信任用户，放任来自通过身份验证的所谓合法用户的请求执行网站的某个特定功能而进行的攻击。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，CSRF比XSS更具危险性。

1.2、案例分析

背景：某用户在正常转账时被CSRF攻击，账户余额被盗取

　　1）用户Bob 向银行发起转账请求http://bank.com.cn/transfer?account=bob&amount=1000000&for=bob2, 此时，服务器通过验证Session对Bob身份进行验证，Bob完成正常转账操作

　　2）黑客Lisa也在同一家银行开设了账户，并向银行发起转账请求：http://bank.com.cn/transfer?account=bob&amount=1000000&for=lisa, Lisa身份验证失败，请求失败

　　3）此网站存在CSRF漏洞，Lisa伪造了一个网址或超链接图片，网址中嵌入代码http://bank.com.cn/transfer?account=bob&amount=1000000&for=lisa, 并诱导Bob点击此网址或图片，此时请求将从Bob的浏览器向银行发起请求，并附带有Bob的Cookie，Bob刚刚访问了银行网站，Session值尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息

　　4）悲剧发生！通过Bob浏览器向银行服务器发送的请求http://bank.com.cn/transfer?account=bob&amount=1000000&for=lisa将会被执行，Bob账户中的钱款被转账至Lisa账户

　　5）无法追溯及追责，银行日志显示确实有一个来自于Bob本人的合法请求转移了资金，没有任何被攻击的痕迹.

1.3、APPSCAN测试过程

　　APPSCAN将可能干扰 CSRF 攻击的 HTTP 头除去，并使用伪造的 Referer 头 http://bogus.referer.ibm.com/向服务器发起请求，若应用服务器正常返回则判断此应用易被跨站点请求伪造攻击。

POST /tg/supplier/supplyFreezeSearch.do HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Accept-Language: en-US

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Referer: http://bogus.referer.ibm.com

Host: pxxx-core-stg2.paic.com.cn

User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Win32)

ec_i=ec&ec_eti=&ec_ev=&ec_efn=&ec_crd=15&ec_f_a=&ec_p=1&ec_s_supplyId=&ec_s_supplyName=&ec_s_reason=&ec_s_flagMean=&ec_s_cdate=&ec_s_beginDate=&ec_s_acceName=&__ec_pages=2&ec_rd=50&ec_f_supplyId=1234&ec_f_supplyName=1234&ec_f_reason=1234&ec_f_flagMean=1234&ec_f_cdate=1234&ec_f_beginDate=1234&ec_f_acceName=1234

HTTP/1.1 OK

Date: Mon, 10 Apr 2017 14:17:54 GMT

Location: http://pxxx-core-stg2.paic.com.cn/login

X-Powered-By: Servlet/2.5 JSP/2.1

Set-Cookie: WLS_HTTP_BRIDGE=Ln1YOmot2_3Gzn7sonux8lIOYaSafCnOVQZzmUl8EjaP1lHMMwqP!-1955618416; path=/; HttpOnly

<html><head><title>欢迎登陆XXX系统</title></head>

1.4、防御建议

　　1）验证 HTTP Referer 字段

　　根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆 bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 bank.example 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。

　　2）在请求地址中添加 token 并验证 CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于cookie之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

　　3）在 HTTP 头中自定义属性并验证，这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。

　　4）使用不允许此弱点出现的经过审核的库或框架，如：OWASP CSRFGuard：http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

“ESAPI 会话管理”控件 http://www.owasp.org/index.php/ESAPI

　　5）确保没有XSS漏洞，因为XSS通常会导致用户身份信息被盗取

　　6）请勿对触发状态更改的任何请求使用 GET 方法

1.5、实际修复方案

　　通过在web.xml中配置过滤器，过滤对应请求，在过滤类中继承OncePerRequestFilter.java父类，再在对应的过滤器中对请求头等进行对应的匹配判断，如果不匹配，则认为是一种CSRF攻击的请求，不给执行该请求。

　　针对过滤条件（url-pattern）要根据实际情况进行配置，有时候不一定是.do或者.html结尾的请求报这个漏洞，这个时候就需要根据实际情况进行其它配置了，可能需要 /* 进行全局请求匹配。

　　同时服务器中web.xml有可能被缓存文件web_merged.xml覆盖而导致新加到web.xml中的配置失效，而导致还是执行的缓存文件中旧有的配置，这点需要注意。解决方法：关闭服务器，删除该缓存文件，然后重启服务。

图1.5.1 配置在web.xml中的拦截器

图1.5.2 配置在web.xml中的拦截器