跨站請(qǐng)求偽造攻擊的基本原理與防范

摘要：文章介紹了跨站請(qǐng)求偽造攻擊的基本情況，并以兩種常見的場(chǎng)景作為講解的范例，分析了該類攻擊的主要原理與產(chǎn)生條件。針對(duì)跨站請(qǐng)求偽造攻擊的主要目標(biāo)和所利用的漏洞，重點(diǎn)介紹了5種不同的防范方法，并簡單的說明5種方法各自的優(yōu)劣之處。為Web應(yīng)用系統(tǒng)的安全防范和設(shè)計(jì)提供參考。

關(guān)鍵詞：跨站請(qǐng)求偽造；會(huì)話劫持；安全防范

中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2014）05-0902-03

The Basic Principles and Prevention of Cross-site Request Forgery Attacks

CHEN Chun-yan

（Dept. of Information and Culture， Guangzhou Municipal Vocational School， Guangzhou 510507， China）

Abstract： This paper introduces the basic situation of cross-site request forgery attacks （CSRF）， analyzes the main principles and conditions of the CSRF with two common scenarios as examples. Focuses on five different prevention methods according to the main target and vulnerabilities of the CSRF， and explaining their strengths and weaknesses of 5 ways. Provide a reference for designing Web applications and systems security.

Key words： CSRF； Session hijacking； Security

1 跨站請(qǐng)求偽造簡介

跨站請(qǐng)求偽造（Cross Site Request Forgery，簡稱CSRF），也被稱為“one click attack”或“session riding”?？缯菊?qǐng)求偽造與目前非常流行的安全漏洞“跨站腳本攻擊（Cross Site Scripting）”名字上有點(diǎn)相似，但它與XSS的攻擊方法完全不一樣。XSS利用漏洞影響站點(diǎn)內(nèi)的用戶，攻擊目標(biāo)是同一站點(diǎn)內(nèi)的用戶者，而CSRF通過偽裝成受害用戶發(fā)送惡意請(qǐng)求來影響Web系統(tǒng)中受害用戶的利益。

CSRF的形成是因?yàn)楣粽咻^容易猜測(cè)某些Web應(yīng)用一個(gè)特定敏感操作的所有細(xì)節(jié)（若是開源項(xiàng)目，則更直接找到關(guān)鍵操作的漏洞細(xì)節(jié)）。利用瀏覽器能保存會(huì)話cookie等憑證，并會(huì)自動(dòng)發(fā)送的特點(diǎn)，攻擊者可以創(chuàng)建一個(gè)惡意web頁面生成偽造請(qǐng)求，再利用社會(huì)工程學(xué)的手段蠱惑受害者進(jìn)行操作，從而在被攻擊Web應(yīng)用上偽裝成受害者進(jìn)行的特定敏感操作，如修改密碼、通信方式甚至轉(zhuǎn)賬等。

CSRF不像XSS那么廣為人知，但在OWASP 2013公布的10大Web應(yīng)用安全威脅中，跨站請(qǐng)求偽造依然位居第8位，依然是一個(gè)不可忽略的嚴(yán)重安全漏洞。又因?yàn)镃SRF比XSS更難以防范，且更具危險(xiǎn)性，所以CSRF也被稱為“沉睡的巨人”。

2 跨站請(qǐng)求偽造的場(chǎng)景

跨站請(qǐng)求偽造攻擊可以在以受害者名義偽造請(qǐng)求并發(fā)送給受攻擊的站點(diǎn)，這樣就能以受害者的身份和權(quán)限執(zhí)行一些特殊敏感的操作，但這一切受害者是毫不知情的。例如：

Tom登錄了一個(gè)銀行網(wǎng)站affectedBank.com，并沒有退出。

黑客Jerry知道affectedBank.com的轉(zhuǎn)賬功能有CSRF漏洞。于是Jerry在大型社交網(wǎng)站sns.com中發(fā)表一張?zhí)?，在帖子中Jerry插入一行類似的html代碼

Tom在瀏覽器的另外一個(gè)標(biāo)簽頁中查看Jerry的這條消息

Tom的瀏覽器將Jerry偽造的轉(zhuǎn)賬請(qǐng)求發(fā)送給affectedBank，從而轉(zhuǎn)出1000元到Jerry的賬戶。

流程如圖1所示。

上述例子當(dāng)中的轉(zhuǎn)賬操作是通過GET請(qǐng)求方式執(zhí)行，在實(shí)際中可能會(huì)更多使用POST的方式。受攻擊站點(diǎn)只接納使用POST方式請(qǐng)求，表面上已經(jīng)不能直接將偽造請(qǐng)求包裝在其他網(wǎng)站中，但黑客仍然可以使用重定向的方式將社交網(wǎng)站中GET的請(qǐng)求指向一個(gè)封裝POST的頁面，從而實(shí)現(xiàn)POST請(qǐng)求組合與提交。

在上述例子中進(jìn)行一些擴(kuò)展：

A. Jerry在自己控制的站點(diǎn)evil.com中構(gòu)造一個(gè)頁面Redirector.php。將使得外部通過GET請(qǐng)求Redirector.php而來的參數(shù)在頁面中重新組合出表單的內(nèi)容，再通過頁面內(nèi)的JavaScript提交到www. affectedBank.com/Transfer.php中。

B. 在sns.com的帖子中包裝一個(gè)不可見的GET請(qǐng)求，申請(qǐng)?jiān)L問Redirector.php。類似于

C. Tom在訪問帖子時(shí)，實(shí)際將執(zhí)行兩次請(qǐng)求，第一次是GET請(qǐng)求跳轉(zhuǎn)到Redirector頁面，第二次是POST請(qǐng)求將數(shù)據(jù)提交到affectedBank.com/Transfer.php。

流程如圖2所示：

圖2 重定向?qū)崿F(xiàn)POST請(qǐng)求的CSRF

直接利用GET請(qǐng)求Redirector.php頁面容易暴露黑客的攻擊意圖，Jerry可以在Evil.com的Web服務(wù)器中設(shè)置一個(gè)Rewrite功能，將請(qǐng)求而來的face.png重寫為http：//www.evil.com/Redirector.php？csrf= http：//www.affectedBank.com/Transfer.php？toAccount=Jerry&money=1000，這樣在sns.com發(fā)帖時(shí)的引用部分就可以直接寫成“http：//www.evil.com/face.png”，使得攻擊更加隱蔽。

3 跨站請(qǐng)求偽造的基本原理

從上述的跨站請(qǐng)求偽造攻擊的場(chǎng)景中，有三個(gè)引發(fā)攻擊形成的必要條件。

1） 瀏覽器會(huì)自動(dòng)發(fā)送用戶標(biāo)識(shí)的會(huì)話信息，并且用戶毫不知情也無法干預(yù)。換而言之，用戶不知道瀏覽器發(fā)送的內(nèi)容中，已經(jīng)包含身份標(biāo)識(shí)信息。身份標(biāo)識(shí)信息（例如cookie）主要是站點(diǎn)用于識(shí)別受認(rèn)證用戶的一個(gè)標(biāo)志。如果站點(diǎn)收到帶有受害者認(rèn)證信息的請(qǐng)求，那么這個(gè)請(qǐng)求就會(huì)被看作是已登錄的受害者發(fā)送而來的正確操作請(qǐng)求。

2） 攻擊者清楚在被攻擊網(wǎng)站的特殊敏感操作的URL結(jié)構(gòu)，并能分析其中所支持的參數(shù)和允許值。一般而言，通過訪問被攻擊Web應(yīng)用程序，查看潛入在HTML或JavaScript中的URL、分析提交的表單結(jié)構(gòu)就可以了解到相應(yīng)的信息。如果是一個(gè)開源項(xiàng)目，攻擊者直接就可以從源代碼中進(jìn)行分析提取可以攻擊的特殊敏感操作。

3） 被攻擊網(wǎng)站完全依賴于會(huì)話信息識(shí)別用戶。因?yàn)闀?huì)話信息其實(shí)對(duì)瀏覽器而言是透明的，瀏覽器只負(fù)責(zé)存放和在發(fā)送請(qǐng)求時(shí)附加相關(guān)的會(huì)話信息，通過瀏覽器并不能解析出會(huì)話信息的內(nèi)容。為了提高Web應(yīng)用的便利性，降低開發(fā)的成本，部分Web應(yīng)用就會(huì)完全依賴這類信息來標(biāo)識(shí)一個(gè)用戶會(huì)話。從而導(dǎo)致Web應(yīng)用程序不會(huì)判斷一個(gè)請(qǐng)求是否真是由合法用戶發(fā)送的。

一般來說，要發(fā)生跨站請(qǐng)求偽造攻擊，需要有以下幾個(gè)特點(diǎn)：

1） 在受攻擊站點(diǎn)已經(jīng)登錄，且沒有正常退出。

2） 受攻擊站點(diǎn)的會(huì)話失效時(shí)間比較長。而且失效時(shí)間越長受攻擊機(jī)率越高。

3） 受攻擊站點(diǎn)的特殊敏感操作沒有嚴(yán)謹(jǐn)?shù)挠脩羯矸輼?biāo)識(shí)驗(yàn)證。

4） 受害者主動(dòng)訪問含有偽造請(qǐng)求的頁面。電子郵件、論壇、博客等常見的互聯(lián)網(wǎng)應(yīng)用都是攻擊者可利用的社會(huì)工程學(xué)的范圍。

4 跨站請(qǐng)求偽造防范的主要方法

要做好攻擊的防范，首先需要明確攻擊的目標(biāo)?？缯菊?qǐng)求偽造攻擊的對(duì)象，就是要保護(hù)的對(duì)象。從上文的分析可知，跨站請(qǐng)求偽造攻擊是黑客利用受害者瀏覽器中包含的用戶身份認(rèn)證信息騙取服務(wù)器的信任，但是黑客其實(shí)并不能拿到身份認(rèn)證的具體憑證，也看不到身份認(rèn)證的內(nèi)容。另外，由于瀏覽器同源策略的限制，黑客也無法進(jìn)行解析查看從受攻擊服務(wù)器響應(yīng)回來的內(nèi)容。因此，黑客無法從服務(wù)器響應(yīng)中得到任何東西。他所能做的僅僅是給服務(wù)器發(fā)送請(qǐng)求，以執(zhí)行請(qǐng)求中所包含的特殊敏感操作，從而達(dá)到在服務(wù)器端直接更改數(shù)據(jù)，并非竊取服務(wù)器的敏感信息或受害者的個(gè)人資料。

因此，針對(duì)跨站請(qǐng)求偽造攻擊要保護(hù)的對(duì)象是那些可以直接影響數(shù)據(jù)改變的操作或服務(wù)，其他僅僅讀取信息的操作或服務(wù)，則不需要進(jìn)行跨站請(qǐng)求偽造攻擊的防范。例如上文中的銀行系統(tǒng)，查詢余額是僅僅返回讀取到的金額數(shù)，跨站請(qǐng)求偽造攻擊無法攔截服務(wù)器返回的結(jié)果，不需要防范。而轉(zhuǎn)賬的操作會(huì)涉及改變賬戶的金額，有遭受跨站請(qǐng)求偽造攻擊的威脅，需要保護(hù)。

一般的攻擊防范，都可以從服務(wù)端和客戶端兩方面入手，因?yàn)榭缯菊?qǐng)求偽造主要是針對(duì)服務(wù)端的欺騙，所以這里攻擊的防范主要在服務(wù)端進(jìn)行。防范的核心思想則是在服務(wù)器端不唯一依靠瀏覽器所直接提交的身份認(rèn)證信息，而需要添加額外的校驗(yàn)信息。主要的實(shí)現(xiàn)方式有以下幾種。

1） 驗(yàn)證 HTTP Referer。在 HTTP 協(xié)議的請(qǐng)求頭部含有一個(gè)字段叫 Referer，它記錄了本次請(qǐng)求的來源地址。只需校驗(yàn)Referer是否以本域作為來源，則可以判斷這個(gè)請(qǐng)求的真?zhèn)巍?/p>

這種方式的優(yōu)點(diǎn)在于簡單易用，開發(fā)人員只需用在敏感操作前增加一個(gè)攔截器檢查Referer的值即可。對(duì)于已有的系統(tǒng)，不需要改動(dòng)內(nèi)部的邏輯，比較方便。但這種方法并不是百分百有效。每個(gè)瀏覽器對(duì)HTTP協(xié)議的實(shí)現(xiàn)有一些差別，目前已經(jīng)發(fā)現(xiàn)，IE6的瀏覽器Referer的值是可以被篡改。對(duì)于新版瀏覽器，雖然無法纂改Referer值，但部分用戶基于隱式權(quán)的需要，可以設(shè)置瀏覽器發(fā)送的請(qǐng)求不包含Referer信息。這些用戶在訪問時(shí)會(huì)被誤認(rèn)為偽造的請(qǐng)求，從而拒絕了合法用戶的訪問。

2） 加密cookie信息。在敏感操作的提交內(nèi)容中，添加一個(gè)對(duì)cookie進(jìn)行Hash后的值，服務(wù)器端對(duì)Hash值進(jìn)行校驗(yàn)，若通過則是合法的用戶請(qǐng)求。因?yàn)樵谥苯拥目缯菊?qǐng)求偽造攻擊中，黑客其實(shí)是無法獲取cookie的具體內(nèi)容，因此也無法構(gòu)造一個(gè)Hash后的cookie值，從而基本杜絕了跨站請(qǐng)求攻擊的實(shí)施。但是這種方法還有一種可能的泄露情況。如果黑客先通過XSS攻擊盜取了用戶的cookie，然后再利用盜取的cookie生成Hash值而制作偽造請(qǐng)求。這種情況的攻擊實(shí)現(xiàn)比較繁瑣復(fù)雜，涉及到XSS和CSRF兩種攻擊的結(jié)合使用。

3） 添加人工驗(yàn)證碼。每次的操作都需要用戶填寫一個(gè)圖片上的隨機(jī)字符串。校驗(yàn)碼由服務(wù)器端生產(chǎn)，黑客是無法獲知每一次操作的校驗(yàn)碼并附加在偽造的請(qǐng)求中。這種方法從理論上是完全解決跨站請(qǐng)求偽造的攻擊問題。但這要求用戶在敏感操作的時(shí)候都需要輸入驗(yàn)證碼，在降低了系統(tǒng)的易用性，而且驗(yàn)證碼圖片對(duì)部分IE瀏覽器而言，存在一個(gè)MHTML的漏洞（MS11-037）。

4） 使用令牌。添加一個(gè)隱藏表單域記錄隨機(jī)的令牌，在求的參數(shù)中包含該令牌。服務(wù)器端執(zhí)行操作前驗(yàn)證這個(gè)令牌，如果請(qǐng)求中沒有令牌或者內(nèi)容不正確，則認(rèn)為可能是偽造請(qǐng)求攻擊而拒絕該請(qǐng)求。這種方法也可以完全解決請(qǐng)求偽造的問題。但在一個(gè)網(wǎng)站中，需要防范的地方非常多，要求每一個(gè)請(qǐng)求都加上令牌會(huì)增加了開發(fā)人員的工作量，而且還很容易遺漏。

5） 在 HTTP 頭中自定義屬性。為了解決上一個(gè)方法設(shè)置Token比較麻煩的問題，可以將令牌放到 HTTP 頭中自定義的屬性里。利用XMLHttpRequest這個(gè)對(duì)象，一次性為所有敏感操作在請(qǐng)求頭增加一個(gè)新的屬性，該屬性的值則是一個(gè)令牌。這種添加令牌的方式比上一種方法簡單。而且，通過 XMLHttpRequest請(qǐng)求的地址不會(huì)被記錄到瀏覽器的訪問歷史，不用擔(dān)心令牌會(huì)透過Referer被竊取。這種其實(shí)是使用Ajax方法在頁面局部的異步刷新的操作，令牌在前進(jìn)，后退，收藏等行為中將失效，而且如果是遺留系統(tǒng)，添加Ajax請(qǐng)求的方法等同重新設(shè)計(jì)整個(gè)系統(tǒng)，代價(jià)過高。

此外，還有一些措施加固防范。如：在每次敏感操作都彈出對(duì)話框需要用戶進(jìn)行二次確認(rèn)。服務(wù)器端將用戶會(huì)話的失效時(shí)間設(shè)置得較短一些。用戶自己養(yǎng)成習(xí)慣，在一個(gè)站點(diǎn)操作完成后，馬上退出登錄以撤銷認(rèn)證會(huì)話。

5 總結(jié)

跨站偽造請(qǐng)求攻擊的威脅雖然比較大，但是其原理與機(jī)制相對(duì)集中。只要把握其無法偽造的一些信息，就可以有效的防范該類攻擊。在防范偽造請(qǐng)求攻擊的方法選用時(shí)，注意選擇最有效而且代價(jià)最少的方案，不能盲目追求技術(shù)的先進(jìn)或復(fù)雜，而且在先滿足系統(tǒng)的安全需要的前提下，盡量做到用戶的易用性和系統(tǒng)的安全性的平衡。Web應(yīng)用的安全威脅層出不窮，在系統(tǒng)設(shè)計(jì)的時(shí)候需要注意做好安全漏洞的測(cè)試，以防止用戶和企業(yè)不必要的損失。

參考文獻(xiàn)：

[1] 王文君，李建蒙. Web應(yīng)用安全威脅與防治[M]. 北京：電子工業(yè)出版社，2013，1.

[2] 季凡，方勇，蒲偉，周妍. CSRF新型利用及防范技術(shù)研究[J].信息安全與通信保密，2013（3）.

[3] 褚誠云.跨站請(qǐng)求偽造攻擊：CSRF安全漏洞[J].程序員，2009（3）.

[4] OWASP. OWASP T10 – 2013[EB/OL].www.OWASP.org，2013.