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

　　黑客能拿到Cookie嗎?

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

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

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

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

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

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

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

　　直接看下面代碼。

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

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

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

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

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

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

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