一種基于Apache的CSRF防御模塊的實現(xiàn)

2017-10-13 20:09:28王馬龍

網(wǎng)絡安全技術與應用 2017年3期

◆王馬龍劉健

◆王馬龍劉健

（四川大學計算機學院四川 610065）

跨站請求偽造（CSRF）漏洞的存在十分廣泛，而且是開放式web應用安全項目（OWASP）統(tǒng)計的Top 10 Web攻擊列表中最具威脅的漏洞之一。目前最具代表性的兩種CSRF防御工具是CSRFGuard[2]和jCSRF[3]。針對CSRFGuard會將JS動態(tài)創(chuàng)建的動態(tài)HTTP請求誤認為是CSRF攻擊；jCSRF以代理模式部署，會增大web服務器的響應時間這兩大問題，本文通過重寫XMLHttpRequest對象onsend的方法，向HTTP頭注入CSRF防御Token，基于Apache web 服務器實現(xiàn)了一個CSRF防御模塊mod_anticsrf，去除了代理的網(wǎng)絡通信開銷。實驗結果表明，mod_anticsrf支持動態(tài)HTTP請求，且?guī)缀醪挥绊憌eb服務器的響應時間。

CSRF；Apache；動態(tài)HTTP請求；性能

0 引言

跨站請求偽造（Cross-Site Request Forgery，CSRF）攻擊是一種當今互聯(lián)網(wǎng)上廣泛存在的Web攻擊。近幾年來，CSRF在OWASP（Open Web Application Security Project）每年的十大安全漏洞中[1]始終能夠穩(wěn)居前列。它并不是一種新型的攻擊，但是其攻擊原理簡單，極具破壞性。由于CSRF漏洞存在于大量的Web應用程序中，如果通過手動修改程序源代碼的方式來修復漏洞，工作量將十分巨大?；诖?，本文基于ApacheWeb服務器實現(xiàn)了一種CSRF防御模塊。

1 CSRF防御工具現(xiàn)狀

CSRFGuard[2]和jCSRF[3]都是基于一次性Token的方法實現(xiàn)的CSRF防御工具。CSRFGuard是由OWASP發(fā)布的CSRF防御技術。它是一個實現(xiàn)了 Token模式的JAVA類庫[4]，通過生成隨機的Token，而攻擊者無法構造有效請求，從而對CSRF攻擊進行防御。它的缺點是：（1）只有Javaweb應用服務器能使用；（2）它使用JavaScript DOM注入Token的方法是在頁面加載完后遍歷頁面所有元素，對“form”或“a”等元素或屬性插入Token。因此，CSRFGuard比較適合處理靜態(tài)頁面。如果有表單在頁面加載完后由JavaScript腳本動態(tài)創(chuàng)建，其提交的請求不能被CSRFGuard插入Token，相關頁面的操作也可能因缺少Token被阻止或者可能遭受CSRF攻擊。jCSRF解決了CSRFGuard的第二個缺點，并提出了一種同域和跨域CSRF防御的協(xié)議。但是jCSRF也有兩個不足之處：（1）目前不支持GET方法；（2）它以HTTP代理的方式部署，會增大系統(tǒng)時延。

2 基于Apache的CSRF防御模塊的設計與實現(xiàn)

2.1 基于Apache的CSRF防御模塊的設計

圖1 jCSRF部署圖

如圖1所示，jCSRF以http代理的形式部署在Web服務器的前方，用戶的每次請求都必須由jCSRF轉發(fā)一次，給系統(tǒng)帶來了很大的網(wǎng)絡時延。

為減少了瀏覽器與代理之間的網(wǎng)絡IO造成的開銷，本文將mod_anticsrf設計為一個可動態(tài)加載的模塊，它可根據(jù)用戶的配置由Apache Http服務器動態(tài)加載/卸載。它的部署模式如下圖2所示：

mod_anticsrf的工作流程如圖3所示：

（1）接收用戶的HTTP請求；

（2）判斷該請求是否為此會話的初始請求（即第一次請求），如果是，則跳轉至第（3）步；否則，跳轉至第（4）步；

（3）生成隨機Token，構造CSRF防御js腳本，然后將js腳本注入到HTTP響應中，跳轉至第（7）步；

（4）從HTTP請求中提取Token，成功則跳轉至第（5）步；否則，跳轉至第（6）步；

（5）判斷Token是否合法，如果合法，則跳轉至第（3）步；否則，跳轉至第（6）步；

（6）阻斷當前HTTP請求，視配置決定是否需要記錄日志，跳轉至第（1）步；

（7）將HTTP響應頁面發(fā)送給用戶，跳轉至第（1）步。

圖3 mod_anticsrf工作流程

2.2 基于Apache的CSRF防御模塊的實現(xiàn)

mod_anticsrf從架構上來看主要分為兩個部分。一部分是用C語言實現(xiàn)的Apache模塊，這部分主要負責Token的構造、JS代碼的注入和Token的驗證；另一部分是要注入到用戶響應頁面的JS代碼，這段JS代碼負責在用戶發(fā)起請求的時候將Token添加到HTTP的頭部或請求體里面。在實現(xiàn)mod_anticsrf的過程中，主要解決以下幾個技術問題：

2.2.1 Token的構造

Token的構造過程是mod_anticsrf的重要部分，為了區(qū)分攻擊者和正常用戶傳遞過來的Token，我們從用戶請求中提取一個能唯一標識用戶的特征來構造Token，構造過程如下：

2.2.2 Token的注入

在服務器端添加Token至HTTP響應頁面是一種注入Token的方法，但是這樣添加Token會對整個頁面進行遍歷，從而導致服務器的延遲增大。本文采用了在用戶瀏覽器中通過JS腳本（anticsrf.js）的方式，動態(tài)地在用戶的HTTP請求中添加Token。具體方法如下：

為值；

對于表單，遍歷dom樹，找到所有的

節(jié)點，然后添加一個類型為hidden的子節(jié)點，name設置為“csrfToken”，value設置為；

對于Ajax請求，需要重寫XMLHttpRequest對象的onsend方法以注入請求頭域“csrfToken：”，核心代碼如下：

XMLHttpRequest.prototype.onsend = function（data）{

// 注入請求頭 "csrfToken：tokenValue"

this.setRequestHeader（"csrfToken"，tokenValue）；

}

2.2.3 在HTTP響應中注入JS腳本

注入JS腳本的步驟如下：

找到標簽，在它的前面插入對anticsrf.js的引用，即：

找到標簽，在它的前面插入對anticsrf.js中的主函數(shù)insertToken的調(diào)用代碼以傳入生成的Token，即：

2.2.4 Token的提取和驗證

當Apache接收到的HTTP請求不是當前會話的初始請求時，mod_anticsrf就要提取該請求中的Token，過程如下：

（1）在HTTP請求頭中尋找csrfToken域，如果找到，說明這是一個Ajax請求，取出它的Token值，跳轉至第（3）步；否則，跳轉至第（5）步；

（2）在HTTP的請求參數(shù)和表單參數(shù)中尋找csrfToken域，如果找到，取出它的Token值，跳轉至第（3）步；否則跳轉至第（5）步；

（6）提取本次請求的源IP地址，如果，則說明請求合法，將該請求的控制權交還給Apache；否則，跳轉至第（7）步；

（7）驗證失敗，阻斷請求。

3 實驗及結果分析

為測試mod_anticsrf能否支持JS動態(tài)創(chuàng)建的HTTP請求，本文設計了一個簡單的網(wǎng)頁：changePassword.php，這個頁面模擬的是用戶改密碼的功能，它提交數(shù)據(jù)的方式是Ajax。從圖4可以看出，頁面能正常訪問，不會被誤認為是CSRF攻擊。

圖4 Ajax請求抓包

本文還針對無CSRF防御、開啟mod_anticsrf和使用jCSRF三種情況進行了性能測試，測試方法為使用Apache開源性能測試工具ab向服務器發(fā)起10000次請求，并發(fā)為100rps（具體命令為：ab -n 10000 -c 100 -p post.txt http：//192.168.11.120/ changePassword.php），最終比較各種情況下的總耗時。結果如圖5所示：Apache在開啟mod_anticsrf模塊之后基本不影響系統(tǒng)性能，而使用jCSRF卻會導致系統(tǒng)時延增加大約1/2。

圖5性能對比圖

由實驗結果可以看出，由于Ajax請求頭里面被成功地注入了CSRF防御Token，所以它不會被判定為CSRF攻擊；而且，由于mod_anticsrf直接運行在Apache進程內(nèi)，不會像jCSRF那樣需要與代理之間的網(wǎng)絡通信，所以幾乎不會增加系統(tǒng)時延。

4 結束語

本文基于Apache實現(xiàn)了一種CSRF防御模塊mod_anticsrf，可以避免mod_anticsrf將JS動態(tài)創(chuàng)建的HTTP請求誤判為CSRF攻擊；此外，將mod_anticsrf以動態(tài)模塊的方式部署于Apache服務器中，幾乎不會影響系統(tǒng)響應時間?，F(xiàn)在，mod_anticsrf暫不支持jQuery等三方JS庫；該模塊有待改進以支持Web應用中存在XSS漏洞的情況。

[1]OWASP.“Top ten most critical web application security vulnerabilities”.http：//www.owasp.org/index.php/OWASP_Top_Ten_Project，2013.

[2]Boyan Chen，Pavol Zavarsky，Ron Ruhl and Dale Lindskog A Studyof the Effectiveness of CSRF Guard. 2011 IEEE International Conferenceon Privacy，Security，Risk，and Trust，and IEEE InternationalConference on Social Computing .

[3]Riccardo Pelizzi，R. Sekar. A server- and browser- transparent CSRF defensefor web 2.0 applications[C]// ACSAC'11：Proceedings of the 27th AnnualComputer Security Applications Conference. New York：ACM，2011.

[4]OWASP.Category：OWASP CSRFGuard Project [EB/ OL].https：//www.owasp.org/index.php/CSRFGuard，2016.

國家重點研發(fā)計劃（2016yfb00604，2016yfb00605），國家自然科學基金項目（61572334）。