深刻解析跨站請求僞造漏洞：原理剖析

當存心不良的Web站點致使用戶的瀏覽器在可信的站點上進行非意願的活動時，咱們就說發生了跨站請求僞造(CSRF)攻擊。這些攻擊被譽爲基於Web的漏洞中的「沉睡的巨人」，由於互聯網上的許多站點對此毫無防備，同時還由於這類攻擊一直爲web開發和安全社區所忽視。

1、概述

當存心不良的Web站點致使用戶的瀏覽器在可信的站點上進行非意願的活動時，咱們就說發生了跨站請求僞造(CSRF)攻擊。跨站請求僞造攻擊亦稱跨站引用僞造（XSRF），會話疊置和混淆代理人攻擊。咱們之因此使用術語CSRF，是由於它是描述這類攻擊時最經常使用的術語。這些攻擊被譽爲基於Web的漏洞中的「沉睡的巨人」，由於互聯網上的許多站點對此毫無防備，同時還由於這類攻擊一直爲Web開發社區和安全社區所忽視。目前，人們還沒有將CSRF攻擊列入Web安全威脅分類中，學術和技術文獻也鮮有述及CSRF攻擊者。CSRF攻擊易於識別、易於利用同時也易於修補。它們之因此存在，是因爲Web開發人員對CSRF攻擊的根源和嚴重性的無知所致。Web開發人員也可能還誤認爲對更有名的跨站腳本（XSS）攻擊的防護措施同時也能防護CSRF攻擊。

在本文的下篇中將向讀者介紹本年度在一些大型站點上發現的幾個嚴重的CSRF漏洞，這些漏洞容許攻擊者採集用戶的電子郵件地址，侵犯用戶隱私並操控用戶賬戶。同時，咱們還將介紹對服務器端的改造方案，以便使站點可以全面防護的CSRF攻擊。該方案有多種優勢，這得益於它們不使用服務器的狀態，同時不妨礙典型的web瀏覽活動。此外，咱們也介紹了一個客戶端的瀏覽器插件，它能夠保護用戶免受某些類型CSRF攻擊。服務器端保護措施能使站點自己具有徹底防護CSRF攻擊的能力，而客戶端保護措施使用戶未雨綢繆，提早採起防疫措施，以便在站點沒有采起防禦措施的狀況下也可以免受CSRF攻擊。儘管如今Web開發人員已經有了防護此類攻擊的工具，可是仍但願你們能提升對CSRF攻擊的防範意識。

2、跨站請求僞造攻擊原理

爲了便於讀者對於跨站請求僞造漏洞的原理，下面咱們用圖例進行解釋。圖一、圖2和圖3爲你們介紹了CSRF攻擊的通常原理。

 

圖1  瀏覽器和網站創建認證的會話

 

這裏，Web瀏覽器已經跟可信的站點創建了一個經認證的會話。以後，只要是經過該Web瀏覽器這個認證的會話所發送的請求，都被視爲可信的動做。

 

圖2  瀏覽器發送有效的請求

 

上圖中，瀏覽器正在發送一個有效的請求，即Web瀏覽器企圖執行一個可信的動做。可信的站點經確認發現，該Web瀏覽器已經過認證，因此該動做將被執行。

 

圖3  惡意站點僞造的有效請求

 

上圖中，發生了一個CSRF攻擊。發起攻擊的站點導致瀏覽器向可信的站點發送一個請求。該可信的站點認爲，來自該Web瀏覽器的請求都是通過認證的有效請求，因此執行這個「可信的動做」。CSRF攻擊之因此會發生，其根本緣由就是Web站點所驗證的是Web瀏覽器而非用戶自己。下面咱們用一個具體的示例來詳細介紹CSRF攻擊。

假設某個站點存在CSRF攻擊漏洞，好比一個基於Web的電子郵件網站，用戶經過該站點能夠發送和接收電子郵件。該站點利用隱式認證方式來驗證用戶身份，它的某個頁面，如http://example.com/compose.htm包含一個供用戶輸入收信人的電子郵件地址、主題和消息的HTML表單，以及一個名爲「Send Email」的按鈕。

{form
action="http://example.com/send_email.htm"
method="GET"}
Recipient’s Email address: {input type="text" name="to"}
Subject: {input type="text" name="subject"}
Message: {textarea name="msg"}{/textarea}
{input type="submit" value="Send Email"}
{/form}

:當example.com站點的用戶單擊「Send Email」時，該用戶輸入的數據就會經過一個GET請求發送到http://example.com/send_email.htm。因爲GET請求只是簡單地將表單數據附加到URL上，因此用戶發送的URL以下所示。這裏假設該用戶輸入的收信人爲「bob@example.com」，主題爲「hello」，消息爲「What’s your name?」：

http://example.com/send_email.htm?to=bob%40example.com&subject=hello&msg=What%27s+your+name%3F

注意的是，上面的URL的數據已通過編碼，@被轉換成%40，等等。

根據收到的數據向用戶指定的收信人發送一封電子郵件。注意，send_email.htm所作的只是提取數據，隨後用該數據完成一個動做。它並不理會該請求來自哪裏，它惟一關心的是收到的請求。這意味着，即便上述URL是用戶手動輸入到他的瀏覽器的，那麼example.com也照常發送一封電子郵件。例如，若是該用戶在其瀏覽器地址欄中鍵入了下列三個URL，那麼send_email.htm頁面將三封電子郵件（分別發給Bob、Alice和Carol ）：

http://example.com/send_email.htm?to=bob%40example.com&subject=hi+Bob&msg=test
http://example.com/send_email.htm?to=alice%40example.com&subject=hi+Alice&msg=test
http://example.com/send_email.htm?to=carol%40example.com&subject=hi+Carol&msg=test

這裏會出現CSRF攻擊，緣由是send_email.htm會把收到的數據悉數提取，而後發電子郵件。它沒有對自compose.htm頁面的表單中的數據進行檢驗。所以，攻擊者只要設法讓用戶向send_email.htm發送一個請求，那麼send_email.htm這個頁面就會引發example.com發送一封電子郵件，要緊的是，該郵件是以該用戶名義發送的，而且包含的是攻擊者任意選擇的任何數據，這樣攻擊者就成功地進行了一次CSRF攻擊。 

爲了利用這個弱點，攻擊者須要強迫用戶的瀏覽器向send_email.htm發送一個請求來完成一些邪惡的動做。咱們假定用戶瀏覽了一個爲攻擊者所控制的站點，而且目標站點沒有采起針對CSRF攻擊的防護措施。具體地說，攻擊者須要僞造一個跨站請求，該請求的發源地是從他的站點，目的地爲example.com，中間會路過受害者的瀏覽器。使人遺憾的是，HTML爲製造這種請求提供了多種方式。例如，瀏覽器遇到標籤時，任何被設置爲src屬性的URI都會被加載，即便那個URI不是一幅圖像。攻擊者能夠用如下代碼建立一個頁面：

{img src="http://example.com/send_email.htm?to=mallory%40example.com&subject=Hi&msg=My+email+address+has+been+stolen"}

當用戶訪問這個頁面時，一個請求被髮送到send_email.htm，而後，將有一封來自該用戶的電子郵件被髮送給Mallory。這個例子跟後面將要介紹的紐約時報站點上發現的漏洞幾乎徹底一致。

要想成功發動CSRF攻擊，攻擊者只要可以引發用戶的瀏覽器在另外一個站點上執行一個非本意的動做便可，固然前提是用戶必須有執行該動做的權限。CSRF攻擊能獲取跟用戶同樣大的權限，即任何用戶能夠執行的動做，攻擊者利用CSRF攻擊也能完成。因此，站點賦予用戶的權限越大，受到CSRF攻擊的可能性就越高，CSRF攻擊帶來的後果也越嚴重。

對於全部使用隱式的認證方式而且沒有采起顯式的針對CSRF攻擊的自我保護措施的站點，CSRF攻擊幾乎總能得手。

3、跨站請求僞造漏洞的根本緣由

CSRF攻擊常常利用目標站點的身份驗證機制，CSRF攻擊這一弱點的根源在於Web的身份驗證機制雖然能夠向目標站點保證一個請求來自於某個用戶的瀏覽器，可是卻沒法保證該請求的確是那個用戶發出的或者是通過那個用戶批准的。例如，假如Alice在瀏覽目標站點T，那麼站點T便會給Alice的瀏覽器一個cookie，用於存放一個僞隨機數做爲會話標識符sid，以跟蹤她的會話。該站點會要求Alice進行登陸，當她輸入有效的用戶名和口令時，該站點會記錄這樣一個事實：Alice已經登陸到會話sid。當Alice發送一個請求到站點T時，她的瀏覽器就會自動地發送包含sid的會話cookie。以後，站點T就會使用站點的會話記錄來識別該會話是否來自Alice。

如今，咱們假設Alice訪問了一個惡意站點M，該站點提供的內容中的JavaScript代碼或者圖像標籤會致使Alice的瀏覽器向站點T發送一個HTTP請求。因爲該請求是發給站點T的，因此Alice的瀏覽器自動地給該請求附上與站點T對應的該會話cookie的sid。站點T看到該請求時，它就能經過該cookie的推斷出：該請求來自Alice，因此站點T就會對Alice的賬戶執行所請求的操做。這樣，CSRF攻擊就能得逞了。

其餘大多數Web認證機制也面臨一樣的問題。例如，HTTP BasicAuth機制會要求Alice告訴瀏覽器她在站點T上的用戶名和口令，因而瀏覽器將用戶名和口令附加到以後發給站點T的請求中。固然，站點T也可能使用客戶端SSL證書，但這也面臨一樣的問題，由於瀏覽器也會將證書附加到發給站點T的請求中。相似的，若是站點T經過IP地址來驗證Alice的身份的話，照樣面臨CSRF攻擊的威脅。

總之，只要身份認證是隱式進行的，就會存在CSRF攻擊的危險，由於瀏覽器發出請求這一動做未必是受用戶的指使。原則上，這種威脅能夠經過對每一個發送至該站點的請求都要求用戶進行顯式的、不可欺騙的動做（諸如從新輸入用戶名和口令）來消除，但實際上這會致使嚴重的易用性問題。大部分標準和普遍應用的認證機制都沒法防止CSRF攻擊，因此咱們只好另外探求一個實用的解決方案。

4、CSRF攻擊向量

成功發動攻擊前提是，用戶必須已經登陸到目標站點，而且必須瀏覽了攻擊者的站點或被攻擊者部分控制的站點。若是一個服務器有CSRF漏洞，而且接受GET請求（就像上面的例子那樣），那麼無需使用JavaScript就能夠發動CSRF攻擊，例如，只需使用{IMG}標籤就能夠搞定。若是該服務器僅接受POST請求，那麼要想從攻擊者的站點自動發送POST請求到目標站點的話，就必須使用JavaScript。

5、CSRF與XSS

近來，跨站腳本攻擊（XSS）漏洞引發了人們的普遍注意。XSS攻擊一般是指，攻擊者向一個站點注入惡意代碼（一般爲JavaScript），以攻擊該站點的其它用戶（即攻擊的最終目標並不是站點自己）。例如，站點可能容許用戶發表評論，這樣的話，評論由用戶張貼，而後被存儲在站點的數據庫中，最後會展現給該站點的全部用戶。若是攻擊者能在評論中夾雜上惡意JavaScript代碼的話，那麼這些JavaScript代碼就會嵌入到全部包含該評論的頁面中。當一個用戶訪問該站點時，攻擊者的JavaScript代碼就被執行，執行權限具備目標站點一切特權。嵌入目標站點的惡意JavaScript代碼將能發送和接收來自該站點上的任何頁面的請求，並可以訪問由該站點設置的cookie。要想防護XSS 攻擊，站點必須仔細過濾全部的用戶輸入，以確保不被注入惡意代碼。

CSRF和XSS攻擊的區別在於，XSS攻擊須要JavaScript，而CSRF攻擊不須要；XSS攻擊要求站點接受惡意代碼，而對於CSRF攻擊來講，惡意代碼位於第三方站點上。過濾用戶的輸入能夠防止惡意代碼注入到某個站點，可是它無阻止法惡意代碼在第三方站點上運行。因爲惡意代碼能夠在第三方站點上運行，因此防護XSS攻擊的措施沒法保護站點不受CSRF攻擊的危害。若是站點具備XSS攻擊漏洞，那麼它也有CSRF攻擊漏洞。可是，即便站點針對XSS攻擊採起了全面保護，卻仍然面臨CSRF攻擊的威脅。

上面介紹了跨站請求僞造的原理、安全問題的根本緣由、攻擊手法和與跨站腳本攻擊之間的區別，下面咱們看看現有的安全策略是否可以防護這種攻擊。

6、同源策略與跨站請求僞造

Web瀏覽器有一項艱鉅的任務，那就是容許用戶維護到達多個網站的安全的專用連接，同時還容許訪問包含不可信代碼的不可信的站點。另外，站點可以從不一樣的域加載資源。舉例來講，站點a.com 可以分別使用{IMG}或者 {SCRIPT} 標籤從b.com加載圖象或者JavaScript。然而，若是用戶已經登陸到一個可信的站點，那麼固然不該該讓不可信的第三方站點讀取可信的站點的內容。

爲了可以在容許不可信的站點顯示來自外部站點的數據的同時還能保持這些數據的私密性，人們建立了同源策略。該策略不只定義了「源」的含義，還規定了當訪問來自不一樣源的數據時，站點能作哪些事情。該策略認爲，若是兩個頁面的協議、端口（若是給出的話）和主機徹底一致，那麼就說這兩個頁面是同源的。根據同源策略的規定，站點不能讀取或者修改來自不一樣的源的資源。

然而，該策略卻容許向不一樣源請求資源。所以，evil.com 能夠在它的站點中經過{IMG}標籤包含圖像http://trusted.com/image.gif，可是它不可以讀取這幅圖像的像素。一樣的，evil.com也能夠在他的站點內利用{iframe}標籤來包含http://trusted.com/private.htm ，可是evil.com卻不能訪問或者修改瀏覽器顯示的這個頁面的內容。

同源策略僅僅阻止了第三方站點讀取來自其餘站點的內容，可是卻沒有防止這些第三方站點向其餘站點發出請求。由於CSRF攻擊是因爲某些請求被髮出（而引發在服務器端執行了某些動做）所引發的，因此同源策略只能用來保護第三方站點上的數據的私密性，可是同源策略沒法防止CSRF攻擊。

7、跨域策略與跨站請求僞造

對於有些站點來講，進行跨域通訊是很是有用的，有時候甚至的必不可少的。鑑於此，Adobe提出了一個機制，稱爲跨域策略，該策略在某些狀況下能夠容許它的Flash插件跟不一樣的域進行通訊即發送和接收數據。該機制當前只用於Flash，具體地說，站點可以規定哪些第三方站點能夠訪問它。第三方站點只能跟其跨域策略文件中規定的第三方站點進行聯絡。下面的跨域策略文件容許訪問源自www.friendlysite.com、*.trusted .com 和IP地址64.233.167.99的請求。這些文件被命名爲crossdomain.xml並放在該域的根目錄下。

{?xml version="1.0"?}{cross-domain-policy}
domain="www.friendlysite.com" /}
{allow-access-from domain="*.trusted.com" /}
{allow-access-from domain="64.233.167.99" /}
{/cross-domain-policy}

假設以上文件位於http://trusted.com/crossdomain.xml。若是evil.com使用Flash向http://trusted.com/private.htm發出了一個請求，Flash將首先加載http://trusted.com/crossdomain.xml以檢驗evil.com是否已做爲受信任的域列於其中。由於它沒有列於其中，因此該請求就會被阻止。相反，若是同一請求來自www.friendlysite.com的話，則Flash將容許該請求，這是由於www.friendlysite.com已經位於被許可的列表中了。

若是使用恰當的話，Adobe的跨域策略可以比同源策略（除非在crossdomain.xml中找到匹配，不然該請求沒法啓動）更好地防護CSRF攻擊，而且具備更高的靈活性（若是目標站點信任發起方站點即源站點的話，則容許跨域通訊）。 然而，跨域策略常常被不正確使用，好比將一個目標站點放到「accept all」的條款中，這會容許第三方從任何站點（無論這個站點是善意的仍是惡意的）訪問它。甚至Adobe的聯盟站點crossdomainxml.org的crossdomain.xml文件也出現了不適當甚至極度危險的用法：域名crossdomainxml.org被註冊到TPowerSDK Software 有限公司的heodore E Patrick名下，該公司在其LinkedIn profile（http://www.linkedin.com/in/tedpatrick）中寫道他們是Adobe Systems的Flex的技術佈道者。 這個站點提供了「accept all 」跨域策略文件的例子，使用該文件的危險性不言自明。

安全研究人員曾經對世界500強的網站進行了分析，其中發現有143個站點使用了crossdomain.xml策略文件。而在這143個站點中，又有47個站點對來自第三方站點的連接徹底接受，這可能致使CSRF漏洞。Adobe的跨域策略多是有效和安全的，但前提是要當心使用。若是在策略文件中使用了「accept all」的話，結果是很是嚴重的。

8、P3P與跨站請求僞造

Cookie可用於在站點之間跟蹤用戶，舉例來講，若是登廣告者在他的服務器上寄放了一張圖片（即廣告），而他的服務器將被大量廣告發行站點所引用。當該圖像被顯示時，登廣告者能夠設置一個cookie，這樣，當同一個用戶訪問不一樣的廣告發布站點時，登廣告者也能認出他是同一我的。換句話說，當該用戶訪問一個廣告發布者的站點並加載登廣告者的圖像時，該用戶的cookie會發回給登廣告者，因爲該cookie是惟一的，因此登廣告者可以識別該用戶。登廣告者可使用這些Cookie來收集有關該用戶上網的習慣的數據。

Cookie在用戶隱私方面的負面影響致使了「隱私權偏好選項平臺」 (Platform for Privacy Preferences，P3P)的出現。P3P「提供了通用的語法和傳輸機制，使得Web站點可以將網站對客戶隱私的處理狀況傳達給Internet Explorer 6(或者其餘任何用戶代理)」。從Internet Explorer 6起，微軟公司開始要求全部站點包含一個P3P策略，以便判斷接受第三方Cookie。

按照微軟公司的說法：

先進的cookie過濾技術，會對Web 站點的隱私作法進行評測，並根據站點的策略跟用戶設置的比較結果來決定接受哪些Cookie。根據默認設置，用於收集我的標識信息的Cookie和不容許用戶進行選擇的Cookie被認爲是「不能使人滿意的」。默認時,將在瀏覽結束時把第一方中的不能使人滿意的Cookie刪掉，並拒絕第三方環境中不能使人滿意的Cookie。（注意，P3P政策沒有進行驗證。因此若是一個站點要求具備一項可接受的政策，Internet Explorer就會容許第三方Cookie。）

假設一個用戶正在瀏覽一個頁面，而該頁面包含了一張位於第三方站點上的圖像。那麼在P3P的環境中，雖然用戶所在的頁面被認爲是安全的，可是第三方站點仍可能存在威脅。 對於CSRF漏洞來講狀況正好相反，雖然第三方站點（是潛在的攻擊目標）是安全的，可是用戶所在的頁面卻存在潛在的危害。若是Internet Explorer認爲一個第三方站點是危險的，那麼它就會阻止向那個站點發送cookes。這樣作可以在使用會話cookie的狀況下有效地阻止CSRF攻擊 ，由於Internet Explorer從跨站請求中提取驗證信息。

Internet Explorer的P3P政策對CSRF漏洞的影響很是有趣：具備有效P3P政策的站點沒法防範CSRF攻擊(Internet Explorer認爲這些站點是安全的，而且容許Cookie），而沒有該政策的站點卻能防護（Internet Explore認爲這些站點是危險的，並攔阻Cookie）CSRF攻擊。 注意，這些只對使用Cookie進行認證的受CSRF漏洞影響的站點有效。使用其它的類型的認證的站點可能仍然對CSRF攻擊有脆弱性。

總而言之，當使用會話cookie進行認證而且目標站點沒有實現P3P政策的時候，Internet Explorer使用P3P可以讓用戶的IE免受CSRF攻擊。這項保護措施是P3P政策的無意插柳之做，由於它的本意並不是防止CSRF攻擊。因此，站點應該實現咱們的建議的服務器端保護措施，具體如本文下篇所述。

9、小結

本文咱們對跨站請求僞造攻擊的原理作了深刻分析，並指出了該漏洞的根本緣由所在；同時介紹了該漏洞的攻擊向量，以及它與跨站腳本攻擊之間的關係。以後後，說明了現有的安全模型，如同源策略等是沒法防護該漏洞的。最後，說明了P3P對於跨站請求僞造的做用。

在下篇中，咱們將向讀者介紹在一些大型站點上發現的幾個嚴重的CSRF漏洞，攻擊者利用這些漏洞不只可以採集用戶的電子郵件地址，侵犯用戶隱私並操控用戶賬戶。實際上，若是金融站點出現了跨站請求僞造漏洞的話，這些漏洞甚至容許攻擊者從用戶的銀行賬戶中划走資金。爲了全面的防護CSRF攻擊，建議對服務器端進行改造。此外，咱們還會介紹服務器端解決方案應具有的特徵，若是缺少這些特性，就會致使CSRF保護措施沒必要要地妨礙典型的web瀏覽活動。除此以外，咱們還將介紹一個客戶端瀏覽器插件，有了該插件的保護，即便站點自身沒有保護措施的狀況下，用戶也能免受某些類型的CSRF攻擊的滋擾。跨站請求僞造是一種嚴重的Web漏洞，但願你們能提升對CSRF攻擊的防範意識。