公司前段时间使用了Fortify扫描项目代码，在修复完这些Fortify漏洞后，最近又启用了Appscan对项目代码进行漏洞扫描，一样也是安排了本人对这些漏洞进行修复。如今，针对修复过的Appscan漏洞也一一总结一下。本次先对 Cross-site request forgery（跨站请求伪造） 漏洞进行总结以下：php
一、跨站点请求伪造（CSRF）
1.一、攻击原理
CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，一般缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS很是不一样，XSS是因为听任来自浏览器的输入任意执行致使了，而CSRF则是由于过度信任用户，听任来自经过身份验证的所谓合法用户的请求执行网站的某个特定功能而进行的攻击。与XSS攻击相比，CSRF攻击每每不大流行（所以对其进行防范的资源也至关稀少）和难以防范，CSRF比XSS更具危险性。html
1.二、案例分析
背景：某用户在正常转帐时被CSRF攻击，帐户余额被盗取java
1）用户Bob 向银行发起转帐请求http://bank.com.cn/transfer?account=bob&amount=1000000&for=bob2, 此时，服务器经过验证Session对Bob身份进行验证，Bob完成正常转帐操做web
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.三、APPSCAN测试过程
APPSCAN将可能干扰 CSRF 攻击的 HTTP 头除去，并使用伪造的 Referer 头 http://bogus.referer.ibm.com/向服务器发起请求，若应用服务器正常返回则判断此应用易被跨站点请求伪造攻击。cookie
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.四、防护建议
1）验证 HTTP Referer 字段app
根据 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.五、实际修复方案
经过在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中的拦截器