你這可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。

　　黑客能拿到Cookie嗎?

　　CSRF 攻擊是黑客借助受害者的 cookie 騙取服務器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的內容。

　　對于服務器返回的結果，由于瀏覽器同源策略的限制，黑客也無法進行解析。因此，黑客無法從返回的結果中得到任何東西，他所能做的就是給服務器發送請求，以執行請求中所描述的命令，在服務器端直接改變數據的值，而非竊取服務器中的數據。

　　什么樣的請求是要CSRF保護?

　　為什么有些框架(比如Spring Security)里防護CSRF的filter限定的Method是POST/PUT/DELETE等，而沒有限定GET Method?

　　我們要保護的對象是那些可以直接產生數據改變的服務，而對于讀取數據的服務，則不需要進行 CSRF 的保護。通常而言GET請作為請求數據，不作為修改數據，所以這些框架沒有攔截Get等方式請求。比如銀行系統中轉賬的請求會直接改變賬戶的金額，會遭到 CSRF 攻擊，需要保護。而查詢余額是對金額的讀取操作，不會改變數據，CSRF 攻擊無法解析服務器返回的結果，無需保護。

　　為什么對請求做了CSRF攔截，但還是會報CRSF漏洞?

　　為什么我在前端已經采用POST+CSRF Token請求，后端也對POST請求做了CSRF Filter，但是滲透測試中還有CSRF漏洞?

　　直接看下面代碼。

　　PS：這一點是很容易被忽視的，在筆者經歷過的幾個項目的滲透測試中，多次出現。

　　有哪些CSRF 防御常規思路?

　　1. 驗證 HTTP Referer 字段， 根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。只需要驗證referer

　　2. 在請求地址中添加 token 并驗證，可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token，并在服務器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。 這種方法要比檢查 Referer 要安全一些，token 可以在用戶登陸后產生并放于 session 之中，然后在每次請求時把 token 從 session 中拿出，與請求中的 token 進行比對，但這種方法的難點在于如何把 token 以參數的形式加入請求。

　　3. 在 HTTP 頭中自定義屬性并驗證

　　開發中如何防御CSRF?

　　可以通過自定義xxxCsrfFilter去攔截實現， 這里建議你參考 Spring Security - org.springframework.security.web.csrf.CsrfFilter.java。