安全類：CSRF
CSRF：跨站請求僞造，英文：Cross-site request forgery forgery
攻擊原理：
從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：
1.登錄受信任網站A，並在本地生成Cookie。
2.在不退出A的情況下，訪問危險網站B。
看到這裏，你也許會說：“如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的攻擊”。是的，確實如此，但你不能保證以下情況不會發生：
1.你不能保證你登錄了一個網站後，不再打開一個tab頁面並訪問另外的網站。
2.你不能保證你關閉瀏覽器了後，你本地的Cookie立刻過期，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束一個會話，但大多數人都會錯誤的認爲關閉瀏覽器就等於退出登錄/結束會話了…）
3.上圖中所謂的攻擊網站，可能是一個存在其他漏洞的可信任的經常被人訪問的網站。
CSRF攻擊的本質原因
CSRF攻擊是源於Web的隱式身份驗證機制！Web的身份驗證機制雖然可以保證一個請求是來自於某個用戶的瀏覽器，但卻無法保證該請求是用戶批准發送的。CSRF攻擊的一般是由服務端解決。
CSRF工具的防禦手段
- 儘量使用POST，限制GET
GET接口太容易被拿來做CSRF攻擊，看第一個示例就知道，只要構造一個img標籤，而img標籤又是不能過濾的數據。接口最好限制爲POST使用，GET則無效，降低攻擊風險。
當然POST並不是萬無一失，攻擊者只要構造一個form就可以，但需要在第三方頁面做，這樣就增加暴露的可能性。
-
加驗證碼
驗證碼，強制用戶必須與應用進行交互，才能完成最終請求。在通常情況下，驗證碼能很好遏制CSRF攻擊。但是出於用戶體驗考慮，網站不能給所有的操作都加上驗證碼。因此驗證碼只能作爲一種輔助手段，不能作爲主要解決方案。 -
Referer 驗證
Referer Check在Web最常見的應用就是“防止圖片盜鏈”。同理，Referer Check也可以被用於檢查請求是否來自合法的“源”（Referer值是否是指定頁面，或者網站的域），如果都不是，那麼就極可能是CSRF攻擊。
但是因爲服務器並不是什麼時候都能取到Referer，所以也無法作爲CSRF防禦的主要手段。但是用Referer Check來監控CSRF攻擊的發生，倒是一種可行的方法。
- Anti CSRF Token
現在業界對CSRF的防禦，一致的做法是使用一個Token（Anti CSRF Token）。
例子：
-
用戶訪問某個表單頁面。
-
服務端生成一個Token，放在用戶的Session中，或者瀏覽器的Cookie中。
-
在頁面表單附帶上Token參數。
-
用戶提交請求後， 服務端驗證表單中的Token是否與用戶Session（或Cookies）中的Token一致，一致爲合法請求，不是則非法請求。
這個Token的值必須是隨機的，不可預測的。由於Token的存在，攻擊者無法再構造一個帶有合法Token的請求實施CSRF攻擊。另外使用Token時應注意Token的保密性，儘量把敏感操作由GET改爲POST，以form或AJAX形式提交，避免Token泄露。
注意：
CSRF的Token僅僅用於對抗CSRF攻擊。當網站同時存在XSS漏洞時候，那這個方案也是空談。所以XSS帶來的問題，應該使用XSS的防禦方案予以解決。