跨站請求偽造漏洞

     一、概述

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

    在本文的下篇中將向讀者介紹本年度在一些大型站點上發現的幾個嚴重的CSRF漏洞，這些漏洞允許攻擊者采集用戶的電子郵件地址，侵犯用戶隱私并操控用戶帳戶。同時，我們還將介紹對服務器端的改造方案，以便使站點能夠全面防御的CSRF攻擊。該方案有多種優點，這得益于它們不使用服務器的狀態，同時不妨礙典型的web瀏覽活動。此外，我們也介紹了一個客戶端的瀏覽器插件，它可以保護用戶免受某些類型CSRF攻擊。服務器端保護措施能使站點本身具備完全防御CSRF攻擊的能力，而客戶端保護措施使用戶未雨綢繆，提前采取防疫措施，以便在站點沒有采取防護措施的情況下也能夠免受CSRF攻擊。盡管現在Web開發人員已經有了防御此類攻擊的工具，但是仍希望大家能提高對CSRF攻擊的防范意識。

    二、跨站請求偽造攻擊原理

    為了便于讀者對于跨站請求偽造漏洞的原理，下面我們用圖例進行解釋。圖1、圖2和圖3為大家介紹了CSRF攻擊的一般原理。 

498)this.style.width=498;" border=0>

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

    這里，Web瀏覽器已經跟可信的站點建立了一個經認證的會話。之后，只要是通過該Web瀏覽器這個認證的會話所發送的請求，都被視為可信的動作。

498)this.style.width=498;" border=0>

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

    上圖中，瀏覽器正在發送一個有效的請求，即Web瀏覽器企圖執行一個可信的動作�？尚诺恼军c經確認發現，該Web瀏覽器已通過認證，所以該動作將被執行。

498)this.style.width=498;" border=0>

圖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為制造這種請求提供了多種方式。例如，瀏覽器遇到498)this.style.width=498;">標簽時，任何被設置為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攻擊幾乎總能得手。 
 

    三、跨站請求偽造漏洞的根本原因

    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攻擊，所以我們只好另外探求一個實用的解決方案。

    四、CSRF攻擊向量

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

    五、CSRF與XSS

    近來，跨站腳本攻擊（XSS）漏洞引起了人們的廣泛注意。XSS攻擊通常是指，攻擊者向一個站點注入惡意代碼（通常為JavaScript），以攻擊該站點的其它用戶（即攻擊的最終目標并非站點本身）。例如，站點可能允許用戶發表評論，這樣的話，評論由用戶張貼，然后被存儲在站點的數據庫中，最后會展示給該站點的所有用戶。如果攻擊者能在評論中夾雜上惡意JavaScript代碼的話，那么這些JavaScript代碼就會嵌入到所有包含該評論的頁面中。當一個用戶訪問該站點時，攻擊者的JavaScript代碼就被執行，執行權限具有目標站點一切特權。嵌入目標站點的惡意JavaScript代碼將能發送和接收來自該站點上的任何頁面的請求，并能夠訪問由該站點設置的cookie。要想防御XSS 攻擊，站點必須仔細過濾所有的用戶輸入，以確保不被注入惡意代碼。

    CSRF和XSS攻擊的區別在于，XSS攻擊需要JavaScript，而CSRF攻擊不需要；XSS攻擊要求站點接受惡意代碼，而對于CSRF攻擊來說，惡意代碼位于第三方站點上。過濾用戶的輸入可以防止惡意代碼注入到某個站點，但是它無阻止法惡意代碼在第三方站點上運行。由于惡意代碼可以在第三方站點上運行，所以防御XSS攻擊的措施無法保護站點不受CSRF攻擊的危害。如果站點具有XSS攻擊漏洞，那么它也有CSRF攻擊漏洞。但是，即使站點針對XSS攻擊采取了全面保護，卻仍然面臨CSRF攻擊的威脅。

    上面介紹了跨站請求偽造的原理、安全問題的根本原因、攻擊手法和與跨站腳本攻擊之間的區別，下面我們看看現有的安全策略是否能夠防御這種攻擊。

    六、同源策略與跨站請求偽造

    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攻擊。

    七、跨域策略與跨站請求偽造

    對于有些站點來說，進行跨域通信是非常有用的，有時候甚至的必不可少的。鑒于此，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”的話，結果是非常嚴重的。

    八、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攻擊。所以，站點應該實現我們的建議的服務器端保護措施，具體如本文下篇所述。

    九、小結

     本文我們對跨站請求偽造攻擊的原理做了深入分析，并指出了該漏洞的根本原因所在；同時介紹了該漏洞的攻擊向量，以及它與跨站腳本攻擊之間的關系。之后后，說明了現有的安全模型，如同源策略等是無法防御該漏洞的。最后，說明了P3P對于跨站請求偽造的作用。

跨站請求偽造是目前很多知名網站都存在的一個漏洞，如果惡意攻擊者運用得當會給網站和用戶（特別是用戶）造成嚴重的傷害。今天和大家一起討論下跨站請求偽造的基本原理和常用攻擊手法，防患于未然。 

本系列導航http://www.cnblogs.com/xuanhun/archive/2008/10/25/1319523.html

安全技術區http://space.cnblogs.com/group/group_detail.aspx?gid=100566

                                                                                                    正文

15.1 從校內說起

（一）簡單效果

   話說校內網目前儼然是中國第一大學生社交網站了，它的安全性也是從最初的一塌糊涂越變越好�？蛻舳蓑炞C也從最初可以添加任意代碼（html，css，script）到現在的只允許css，而且過濾了關鍵字，進行服務器端驗證。。。使用校內的過程中真的學到了不少知識。偶爾在校內寫寫日志，難免會注意它的編輯器。

這就是編輯器的全部功能。它不允許查看源代碼，當然這不是問題，因為我們知道日志的呈現結果必須是html代碼的。隨便找個在線編輯器就可以編輯了，然后把編輯后的內容貼過來就好了。不過校內做的還不錯，對貼過來的內容也做了過濾，我試著添加script結果都在服務器端被過濾掉了。不知不覺給校內做了個廣告。。。下面看我發的一篇日志吧：

題目：我的處男生涯

“你來了，

  你真的來了，

但你想走的時候。。。。

已經晚了。。。

”

校內來訪問我日志的人，在想離開的時候發現跳到了這個頁面：

不明白的還納悶？怎么退出來了。。。明白的已經在罵我了。慘��！估計挨了不少罵。

（二）查看內幕

下面我們來簡單分析下對這段簡單的日志http請求的情況：

（1）對日志內容的第一次請求

GET /GetEntry.do?id=379593678&owner=201573034 HTTP/1.1 
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-Excel, application/vnd.ms-powerpoint, application/msword, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */* 
Referer: http://blog.xiaonei.com/ 
Accept-Language: zh-cn 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; WINdows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) 
Accept-Encoding: gzip, deflate 
Host: blog.xiaonei.com 
Connection: Keep-Alive 
Cookie: __utma=204579609.347185043.1238318018.1240453421.1240456537.158; __utmz=204579609.1240405279.155.23.utmccn=(referral)|utmcsr=home.xiaonei.com|utmcct=/Home.do|utmcmd=referral; _de=8EAD38BFFD04FDBE; id=201800742; mop_uniq_ckid=123.189.23.249_1238318098_149848619; _r01_=1; wpi_clew_cookie=exsit; headbulletincookie232023771=0; homeNtcInf=0; notifyTips201800742=1; xiaonei_stage=20; xiaonei_guide_uid=201573034; __utmb=204579609; depovince=LN; XNESSESSIONID=c9da0fa7aff8; __utmc=204579609; userid=201573034; univid=5426; gender=1; univyear=2005; societyguester=a2ac4d18338093affb56d55a2b96c90a4; kl=b1f2731841d14040d19a6e3eda22a11a_201573034; hostid=201573034; jebecookies=201573034|1|1985-1-5|20|0|5426_; xn_app_histo_201573034=6-26302-3-20706-23446-20-9999-21461-8-17954-17940-2

這一次請求返回了頁面的基本html代碼

（2）緊接著根據第一次請求獲得的html代碼分析里面的元素，對<img src=”http://www.xiaonei.com/Logout.do” />做了請求，目的是下載圖片。

GET /Logout.do HTTP/1.1 
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */* 
Referer: http://blog.xiaonei.com/GetEntry.do?id=379593678&owner=201573034 
Accept-Language: zh-cn 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) 
Accept-Encoding: gzip, deflate 
Host: www.xiaonei.com 
Connection: Keep-Alive 
Cookie: __utma=204579609.347185043.1238318018.1240453421.1240456537.158; __utmz=204579609.1240405279.155.23.utmccn=(referral)|utmcsr=home.xiaonei.com|utmcct=/Home.do|utmcmd=referral; _de=8EAD38BFFD04FDBE; id=201800742; mop_uniq_ckid=123.189.23.249_1238318098_149848619; _r01_=1; wpi_clew_cookie=exsit; headbulletincookie232023771=0; homeNtcInf=0; notifyTips201800742=1; xiaonei_stage=20; xiaonei_guide_uid=201573034; depovince=LN; XNESSESSIONID=c9da0fa7aff8; __utmc=204579609; userid=201573034; univid=5426; gender=1; univyear=2005; societyguester=a2ac4d18338093affb56d55a2b96c90a4; kl=b1f2731841d14040d19a6e3eda22a11a_201573034; hostid=201573034; jebecookies=201573034|1|1985-1-5|20|0|5426_; xn_app_histo_201573034=6-26302-3-20706-23446-20-9999-21461-8-17954-17940-2

（三）簡要分析：

其實迫使用戶退出登錄的原因在于那張圖片。圖片的url并沒指向一個真正的圖片而是“http://www.xiaonei.com/Logout.do”，這個鏈接會向校內網發出一個退出的請求。而這個請求是瀏覽器發出的，這是第一點。第二點，你很容易注意到瀏覽器發送任何請求的時候都帶上了本地的cookie，這是用戶退出成功的最基本條件。服務器會根據cookie判斷用戶的身份和狀態。本例演示的就是最簡單的請求偽造。

15.2 跨站請求偽造原理

（一）什么是跨站請求偽造

CSRF是偽造客戶端請求的一種攻擊，CSRF的英文全稱是Cross Site Request Forgery，字面上的意思是跨站點請求偽造。是強迫受害者的瀏覽器向一個易受攻擊的Web應用程序發送請求,最后達到攻擊者所需要的操作行為。

（二）跨站請求偽造的分類

1.站內偽造。站內偽造不涉及跨域，所以相對來說實施起來比較簡單。校內網插入圖片的例子就是一個站內偽造的例子。我們注意到http頭中的

“Referer: http://blog.xiaonei.com/GetEntry.do?id=379593678&owner=201573034”，如果“blog.xiaonei.com/”變成了“hi.baidu.com”，這時候因為跨域了，這個請求會失敗。如果我們提交一個“http://xiaonei.com/DelFriend.do?id=200945709&from=vu”的請求，那么id為200945709的用戶就會從當前用戶的好友列表中刪除。更壞的例子我就不舉例了，總之當前用戶已經登陸了，理論上你想讓他干什么他就會干什么。電子商務類型的網站如果出現這種情況會更糟糕的。

2.站外偽造。這是個跨域提交請求的方式。站外偽造也是彌補站內偽造的各種缺點的有效方式。比如你在站內無法提交特定的腳本或者相應的html代碼的時候，你可以在站外構造自己的頁面。站外偽造的靈活性更大，我們有更多的選擇的余地。

（三）get和post

get請求就像我們前面看到的，一個圖片，或者一個超鏈接就可以辦到。對于很多站內偽造，其實只接受post請求就可以解決了，因為很多情況下無法自己發送post請求。但我們也看到這樣的情況，本來是要求post的數據，但是由于程序員的疏忽導致get方式也可以成功。Request.Form、Request.QueryString，Request是asp.net接受數據的三種方式，但是如果你使用Request方法時就無法區分是get還是post了，使惡意攻擊者有機可乘。post方法的跨站偽造幾乎都是在站外偽造中進行的。因為我可以輕松的構造表單然后提交。

（四）瀏覽器安全特性與偽造請求的關系

客戶端的cookie是進行用戶狀態識別，權限管理，認證，保持會話狀態的最常用的方式，但是我們的瀏覽器對像<img src=””/>這樣的請求都要附帶上cookie，這使偽造請求有了最基本的保證。

下面這段描述引自網絡：

“參照Set-Cookie的標準格式，現今瀏覽器支持的cookie實際上分為兩種形式： 
Set-Cookie: <name>=<value>[; <name>=<value>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly] 
        一種是內存COOKIE，在沒有設定COOKIE值的expires參數，也就是沒有設置COOKIE的失效時間情況下，這個COOKIE在關閉瀏覽器后將失效，并且不會保存在本地。另外一種是本地保存COOKIE，也就是設置了expires參數，COOKIE的值指定了失效時間，那么這個COOKIE 會保存在本地，關閉瀏覽器后再訪問網站，在COOKIE有效時間內所有的請求都會帶上這個本地保存COOKIE。 
        Internet Explorer有一個隱私報告功能，其實這是一個安全功能，它會阻擋所有的第三方COOKIE，比如A域Web頁面嵌入了B域的文件，客戶端瀏覽器訪問了A域的Web頁面后對B域所發起的文件請求所帶上的COOKIE會被IE攔截。除開文件請求情況，A域的Web頁面如果使用IFRAME幀包含B域的 Web頁面，訪問A域的Web頁面后，B域的Web頁面里的所有請求包括文件請求帶上的COOKIE同樣會被IE攔截。不過Internet Explorer的這個安全功能有兩個特性，一是不會攔截內存COOKIE，二是在網站設置了P3P頭的情況下，會允許跨域訪問COOKIE，隱私報告功能就不會起作用了。 
        所以在Internet Explorer的這個安全特性的前提下，攻擊者要進行站外的CSRF攻擊使用文件請求來偽造GET請求的話，受害者必須在使用內存COOKIE也就是沒有保存登陸的會話狀態下才可能成功。而Firefox瀏覽器并沒有考慮使用這樣的功能，站外的CSRF攻擊完全沒有限制。

”

15.3常用的跨站請求偽造方法

這里我不想舉過于詳細的例子，網上也有相關資料，大家可以看看，旨在拋磚引玉。

（1）直接請求

       本質上是get請求。這種方法比較直接，可以采取讓用戶點擊超鏈接的方法，瀏覽器自動請求資源的方法（如<img>,<script>等標簽）。如果鏈接包含在郵件中，是不是可以讓用戶刪除郵件呢？我沒試過。

（2）post

      post數據一定要有JavaScript的配合，因此對于站內偽造來說很難辦到（有xss漏洞的除外）,一般用于站外偽造。

<iframe name="XX" display="none">

<form method="POST" name="xxx" 

action=http://*****.com/deleteFriend.aspx>

<input type="hidden" name="ID”  value="2702455999">

</form>

</iframe>

<script type="text/javascript">

function DealFriend()

{

iframe = document.frames["XX"];

iframe.document.Submit("xxx");

}

</script>

（3）Ajax調用

json數據的應用越來越廣泛，攻擊者可以向返回json數據的數據接口發起請求從而獲得一些關鍵數據。百度hi蠕蟲攻擊利用的就是json數據獲得好友列表然后傳播腳本。部分代碼如下：

好友json數據的動態獲取

var gotfriends = function (x) 
{ 
for(i=0;i<x[2].length;i++) 
{ 
friends.push(x[2][i][1]); 
} 
} 
loadjson(’<script src=”http://frd.baidu.com/?ct=28&un=’+lusername+’&cm=FriList&tn=bmABCFriList&callback=gotfriends&.tmp=&1=2″></script>’);

感染信息輸出和消息發送的核心部分

evilurl=url+”/wish.php?from=”+lusername+”&to=”; 
sendmsg=”http://msg.baidu.com/?ct=22&cm=MailSend&tn=bmSubmit&sn=[user]&co=[evilmsg]” 
for(i=0;i<friends.length;i++){ 
省略……………. 
mysendmsg=mysendmsg+”&”+i; 
eval(’x'+i+’=new Image();x’+i+’.src=unescape(”‘+mysendmsg+’”);’); 
省略…………….

Ajax的另一種用法是請求script文件或者動態生成script文件的頁面，插入到當前頁面執行一些操作，這也是站內偽造不準隨意添加代碼的解決方案之一。

（4）偽造http頭

這是對于跨域驗證的問題的對策之一，通常是偽造Referer。

.net中可以通過類似這樣的代碼設置

HttpWebRequest myHttpWebRequest=(HttpWebRequest)WebRequest.Create(myUri); 

myHttpWebRequest.Referer=http://www.microsoft.com;

或者HttpWebRequest的Header屬性。

編程設置http頭需要攻擊者把受害用戶的信息提交到自己的頁面，然后由自己頁面發送到目標頁面的自定義請求攜帶受害者的認證信息。

（5)AJAX跨域解決方案

這里談到的知識作為一個補充，不涉及直接攻擊問題。具體的可參考相關文章，我只簡單羅列一下。因為具體談的話內容會很多，夠一個專題了。

     1.iframe嵌套

      2.應用代理

     3.script標簽