◆王馬龍 劉 健

?

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

◆王馬龍 劉 健

（四川大學(xué)計(jì)算機(jī)學(xué)院 四川 610065）

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

CSRF；Apache；動(dòng)態(tài)HTTP請(qǐng)求；性能

0 引言

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

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

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

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

2.1 基于Apache的CSRF防御模塊的設(shè)計(jì)

圖1 jCSRF部署圖

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

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

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

（1）接收用戶的HTTP請(qǐng)求；

（2）判斷該請(qǐng)求是否為此會(huì)話的初始請(qǐng)求（即第一次請(qǐng)求），如果是，則跳轉(zhuǎn)至第（3）步；否則，跳轉(zhuǎn)至第（4）步；

（3）生成隨機(jī)Token，構(gòu)造CSRF防御js腳本，然后將js腳本注入到HTTP響應(yīng)中，跳轉(zhuǎn)至第（7）步；

（4）從HTTP請(qǐng)求中提取Token，成功則跳轉(zhuǎn)至第（5）步；否則，跳轉(zhuǎn)至第（6）步；

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

（6）阻斷當(dāng)前HTTP請(qǐng)求，視配置決定是否需要記錄日志，跳轉(zhuǎn)至第（1）步；

（7）將HTTP響應(yīng)頁(yè)面發(fā)送給用戶，跳轉(zhuǎn)至第（1）步。

圖3 mod_anticsrf工作流程

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

mod_anticsrf從架構(gòu)上來(lái)看主要分為兩個(gè)部分。一部分是用C語(yǔ)言實(shí)現(xiàn)的Apache模塊，這部分主要負(fù)責(zé)Token的構(gòu)造、JS代碼的注入和Token的驗(yàn)證；另一部分是要注入到用戶響應(yīng)頁(yè)面的JS代碼，這段JS代碼負(fù)責(zé)在用戶發(fā)起請(qǐng)求的時(shí)候?qū)oken添加到HTTP的頭部或請(qǐng)求體里面。在實(shí)現(xiàn)mod_anticsrf的過(guò)程中，主要解決以下幾個(gè)技術(shù)問(wèn)題：

2.2.1 Token的構(gòu)造

Token的構(gòu)造過(guò)程是mod_anticsrf的重要部分，為了區(qū)分攻擊者和正常用戶傳遞過(guò)來(lái)的Token，我們從用戶請(qǐng)求中提取一個(gè)能唯一標(biāo)識(shí)用戶的特征來(lái)構(gòu)造Token，構(gòu)造過(guò)程如下：

2.2.2 Token的注入

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

為值；

對(duì)于表單，遍歷dom樹(shù)，找到所有的