跨站請求偽造

跨站請求攻擊，簡單地説，是攻擊者通過一些技術手段欺騙用户的瀏覽器去訪問一個自己曾經認證過的網站並運行一些操作（如發郵件，發消息，甚至財產操作如轉賬和購買商品）。由於瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用户操作而去運行。這利用了web中用户身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用户的瀏覽器，卻不能保證請求本身是用户自願發出的。

假如一家銀行用以運行轉賬操作的URL地址如下：http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

那麼，一個惡意攻擊者可以在另一個網站上放置如下代碼： <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

如果有賬户名為Alice的用户訪問了惡意站點，而她之前剛訪問過銀行不久，登錄信息尚未過期，那麼她就會損失1000資金。

這種惡意的網址可以有很多種形式，藏身於網頁中的許多地方。此外，攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇，博客等任何用户生成內容的網站中。這意味着如果服務端沒有合適的防禦措施的話，用户即使訪問熟悉的可信網站也有受攻擊的危險。

透過例子能夠看出，攻擊者並不能通過CSRF攻擊來直接獲取用户的賬户控制權，也不能直接竊取用户的任何信息。他們能做到的，是欺騙用户瀏覽器，讓其以用户的名義運行操作。 ^[1] 

HTTP頭中有一個Referer字段，這個字段用以標明請求來源於哪個地址。在處理敏感數據請求時，通常來説，Referer字段應和請求的地址位於同一域名下。以上文銀行操作為例，Referer字段地址通常應該是轉賬按鈕所在的網頁地址，應該也位於www.examplebank.com之下。而如果是CSRF攻擊傳來的請求，Referer字段會是包含惡意網址的地址，不會位於www.examplebank.com之下，這時候服務器就能識別出惡意的訪問。

這種辦法簡單易行，工作量低，僅需要在關鍵訪問處增加一步校驗。但這種辦法也有其侷限性，因其完全依賴瀏覽器發送正確的Referer字段。雖然http協議對此字段的內容有明確的規定，但並無法保證來訪的瀏覽器的具體實現，亦無法保證瀏覽器沒有安全漏洞影響到此字段。並且也存在攻擊者攻擊某些瀏覽器，篡改其Referer字段的可能。

由於CSRF的本質在於攻擊者欺騙用户去訪問自己設置的地址，所以如果要求在訪問敏感數據請求時，要求用户瀏覽器提供不保存在cookie中，並且攻擊者無法偽造的數據作為校驗，那麼攻擊者就無法再運行CSRF攻擊。這種數據通常是窗體中的一個數據項。服務器將其生成並附加在窗體中，其內容是一個偽隨機數。當客户端通過窗體提交請求時，這個偽隨機數也一併提交上去以供校驗。正常的訪問時，客户端瀏覽器能夠正確得到並傳回這個偽隨機數，而通過CSRF傳來的欺騙性攻擊中，攻擊者無從事先得知這個偽隨機數的值，服務端就會因為校驗token的值為空或者錯誤，拒絕這個可疑請求。 ^[1]