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

　　黑客能拿到Cookie嗎?

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

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

　　什么樣的請求是要CSRF保護(hù)?

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

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

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

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

　　直接看下面代碼。

　　PS：這一點(diǎn)是很容易被忽視的，在筆者經(jīng)歷過的幾個(gè)項(xiàng)目的滲透測試中，多次出現(xiàn)。

　　有哪些CSRF 防御常規(guī)思路?

　　1. 驗(yàn)證 HTTP Referer 字段， 根據(jù) HTTP 協(xié)議，在 HTTP 頭中有一個(gè)字段叫 Referer，它記錄了該 HTTP 請求的來源地址。只需要驗(yàn)證referer

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

　　3. 在 HTTP 頭中自定義屬性并驗(yàn)證

　　開發(fā)中如何防御CSRF?

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