公司前段時間使用了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中的攔截器