web安全之token和CSRF攻擊

阿新 • • 發佈：2019-01-19

上文我轉載了兩篇關於ThinkPHP令牌驗證的文章（ThinkPHP中的create方法與自動令牌驗證）。其中提及到了 token ，這裡針對 token 的作用，轉載了另外兩篇文章。

web安全之token

參考：http://blog.csdn.net/sum_rain/article/details/37085771

Token，就是令牌，最大的特點就是隨機性，不可預測。一般黑客或軟體無法猜測出來。

那麼，Token有什麼作用？又是什麼原理呢？

Token一般用在兩個地方:

1)防止表單重複提交、 2)anti csrf攻擊（跨站點請求偽造）。

兩者在原理上都是通過session token來實現的。當客戶端請求頁面時，伺服器會生成一個隨機數Token，並且將Token放置到session當中，然後將Token發給客戶端（一般通過構造hidden表單）。下次客戶端提交請求時，Token會隨著表單一起提交到伺服器端。
然後，如果應用於"anti csrf攻擊"，則伺服器端會對Token值進行驗證，判斷是否和session中的Token值相等，若相等，則可以證明請求有效，不是偽造的。
不過，如果應用於"防止表單重複提交"，伺服器端第一次驗證相同過後，會將session中的Token值更新下，若使用者重複提交，第二次的驗證判斷將失敗，因為使用者提交的表單中的Token沒變，但伺服器端session中Token已經改變了。

上面的session應用相對安全，但也叫繁瑣，同時當多頁面多請求時，必須採用多Token同時生成的方法，這樣佔用更多資源，執行效率會降低。因此，也可用cookie儲存驗證資訊的方法來代替session Token。比如，應對"重複提交"時，當第一次提交後便把已經提交的資訊寫到cookie中，當第二次提交時，由於cookie已經有提交記錄，因此第二次提交會失敗。
不過，cookie儲存有個致命弱點，如果cookie被劫持（xss攻擊很容易得到使用者cookie），那麼又一次gameover。黑客將直接實現csrf攻擊。

所以，安全和高效相對的。具體問題具體對待吧。

此外，要避免"加token但不進行校驗"的情況

，在session中增加了token，但服務端沒有對token進行驗證，根本起不到防範的作用。

還需注意的是，對資料庫有改動的增刪改操作，需要加token驗證，對於查詢操作，一定不要加token，防止攻擊者通過查詢操作獲取token進行csrf攻擊。但並不是這樣攻擊者就無法獲得token，只是增大攻擊成本而已。

Web安全之CSRF攻擊

CSRF是什麼？

CSRF（Cross Site Request Forgery），中文是跨站點請求偽造。CSRF攻擊者在使用者已經登入目標網站之後，誘使使用者訪問一個攻擊頁面，利用目標網站對使用者的信任，以使用者身份在攻擊頁面對目標網站發起偽造使用者操作的請求，達到攻擊目的。

舉個例子 簡單版：

假如部落格園有個加關注的GET介面，blogUserGuid引數很明顯是關注人Id，如下：

那我只需要在我的一篇博文內容裡面寫一個img標籤：

那麼只要有人開啟我這篇博文，那就會自動關注我。

升級版：

假如部落格園還是有個加關注的介面，不過已經限制了只獲取POST請求的資料。這個時候就做一個第三方的頁面，但裡面包含form提交程式碼，然後通過QQ、郵箱等社交工具傳播，誘惑使用者去開啟，那開啟過部落格園的使用者就中招了。

在說例子之前要糾正一個iframe問題，有人會直接在第三方頁面這樣寫。如下：

<!DOCTYPE HTML> 
<html lang="en-US"> 
<head> 
<title>CSRF SHOW</title> 
</head> 
<body> 
<!--不嵌iframe會跳轉--> 
<iframe style="display:none;"> 
<form  name="form1" action="http://www.cnblogs.com/mvc/Follow/FollowBlogger.aspx" method="post"> 
<input type="hidden" name="blogUserGuid" value="4e8c33d0-77fe-df11-ac81-842b2b196315"/> 
<input type="submit" value> 
</form> 
<script> 
　　document.forms.form1.submit(); 
</script>  </iframe>  </body>  </html>

這樣是用問題的，由於同源策略的原因，iframe內容根本載入不出來，所以裡面form提交當然不會執行。

PS：我嘗試了chrome、IE11、Firefox，情況都是這樣。

所以可以用嵌多一層頁面方式解決，如下：

第一個展示頁面（test）:

<!DOCTYPE HTML> 
<html lang="en-US"> 
<head> 
<title>CSRF SHOW</title> 
</head> 
<body> 
<iframe style="display:none;" src="test2.html"></iframe> 
</body> 
</html>

第二個隱藏頁面（test2）:

<!DOCTYPE HTML> 
<html lang="en-US"> 
<head> 
<title>CSRF GET</title> 
<body> 
<form  name="form1" action="http://www.cnblogs.com/mvc/Follow/FollowBlogger.aspx" method="post"> 
<input type="hidden" name="blogUserGuid" value="4e8c33d0-77fe-df11-ac81-842b2b196315"/> 
<input type="submit" value> 
</form> 
<script> 
　　document.forms.form1.submit(); 
</script>  </body>  </html>

這樣就可以解決了，有人會問為什麼要加多一層iframe，因為不嵌iframe頁面會重定向，這樣就降低了攻擊的隱蔽性。另外我們test頁面不使用XMLHTTPRequest傳送POST請求，是因為有跨域的問題，而form可以跨域post資料。

進階版：

假如部落格園還是有個加關注的介面，已經限制POST，但博文內容是直接貼進HTML（未過濾），那就遭受XSS攻擊。那麼就可以直接把上面程式碼嵌入博文，那麼只要有人開啟我這篇博文，還是會自動關注我，這組合攻擊方式稱為XSRF。

CSRF攻擊的本質原因

CSRF攻擊是源於Web的隱式身份驗證機制！Web的身份驗證機制雖然可以保證一個請求是來自於某個使用者的瀏覽器，但卻無法保證該請求是使用者批准傳送的。CSRF攻擊的一般是由服務端解決。

CSRF工具的防禦手段

1. 儘量使用POST，限制GET

GET介面太容易被拿來做CSRF攻擊，看第一個示例就知道，只要構造一個img標籤，而img標籤又是不能過濾的資料。介面最好限制為POST使用，GET則無效，降低攻擊風險。

當然POST並不是萬無一失，攻擊者只要構造一個form就可以，但需要在第三方頁面做，這樣就增加暴露的可能性。

2. 瀏覽器Cookie策略

IE6、7、8、Safari會預設攔截第三方本地Cookie（Third-party Cookie）的傳送。但是Firefox2、3、Opera、Chrome、Android等不會攔截，所以通過瀏覽器Cookie策略來防禦CSRF攻擊不靠譜，只能說是降低了風險。

PS：Cookie分為兩種，Session Cookie（在瀏覽器關閉後，就會失效，儲存到記憶體裡），Third-party Cookie（即只有到了Exprie時間後才會失效的Cookie，這種Cookie會儲存到本地）。

PS：另外如果網站返回HTTP頭包含P3P Header，那麼將允許瀏覽器傳送第三方Cookie。

3. 加驗證碼

驗證碼，強制使用者必須與應用進行互動，才能完成最終請求。在通常情況下，驗證碼能很好遏制CSRF攻擊。但是出於使用者體驗考慮，網站不能給所有的操作都加上驗證碼。因此驗證碼只能作為一種輔助手段，不能作為主要解決方案。

4. Referer Check

Referer Check在Web最常見的應用就是"防止圖片盜鏈"。同理，Referer Check也可以被用於檢查請求是否來自合法的"源"（Referer值是否是指定頁面，或者網站的域），如果都不是，那麼就極可能是CSRF攻擊。

但是因為伺服器並不是什麼時候都能取到Referer，所以也無法作為CSRF防禦的主要手段。但是用Referer Check來監控CSRF攻擊的發生，倒是一種可行的方法。

5. Anti CSRF Token

現在業界對CSRF的防禦，一致的做法是使用一個Token（Anti CSRF Token）。

例子：

1. 使用者訪問某個表單頁面。

2. 服務端生成一個Token，放在使用者的Session中，或者瀏覽器的Cookie中。

3. 在頁面表單附帶上Token引數。

4. 使用者提交請求後，服務端驗證表單中的Token是否與使用者Session（或Cookies）中的Token一致，一致為合法請求，不是則非法請求。

這個Token的值必須是隨機的，不可預測的。由於Token的存在，攻擊者無法再構造一個帶有合法Token的請求實施CSRF攻擊。另外使用Token時應注意Token的保密性，儘量把敏感操作由GET改為POST，以form或AJAX形式提交，避免Token洩露。

注意：

CSRF的Token僅僅用於對抗CSRF攻擊。當網站同時存在XSS漏洞時候，那這個方案也是空談。所以XSS帶來的問題，應該使用XSS的防禦方案予以解決。

總結

CSRF攻擊是攻擊者利用使用者的身份操作使用者帳戶的一種攻擊方式，通常使用Anti CSRF Token來防禦CSRF攻擊，同時要注意Token的保密性和隨機性。

參考文獻：

2. 《白帽子講Web安全》

本文為原創文章，轉載請保留原出處，方便溯源，如有錯誤地方，謝謝指正。

web安全之token和CSRF攻擊