CSRF跨站請求偽造和XSS攻擊壹樣，有巨大的安全隱患。妳可以這樣理解:攻擊者竊取了妳的身份，以妳的名義發送惡意請求。這個請求對於服務器來說是完全合法的，但是它卻偷偷完成了壹個攻擊者所期望的操作，比如以妳的名義發送郵件和消息，盜取妳的賬號，添加系統管理員，甚至。
假設:Web A是壹個存在CSRF漏洞的網站，Web B是攻擊者搭建的惡意網站，用戶C是Web A網站的合法用戶。攻擊的大致過程如下:
目前，在我們的工作中通常使用三種主要策略來防禦CSRF攻擊:
首先，驗證HTTP Referer字段
根據HTTP協議，HTTP頭中有壹個名為Referer的字段，記錄了HTTP請求的源地址。通常，訪問安全受限頁面的請求來自同壹個網站，例如http://bank.example/withdraw?.帳戶=鮑勃& amp金額= 1000000 & amp；對於=Mallory，用戶必須先登錄bank.example，然後點擊頁面上的按鈕觸發轉賬事件。此時，轉賬請求的Referer值將是轉賬按鈕所在頁面的URL，通常是以bank.example域名開頭的地址，但如果黑客想對銀行網站進行CSRF攻擊，只能在自己的網站上構造請求。當用戶通過黑客的網站向銀行發送請求時，請求的推薦人指向黑客自己的網站。因此，為了防禦CSRF攻擊，銀行網站只需要為每個轉賬請求驗證其Referer值。如果是以bank.example開頭的域名，說明請求來自銀行網站本身，是合法的。如果Referer是另壹個網站，則可能是黑客的CSRF攻擊，請求被拒絕。
這種方法的明顯優點是簡單易行。網站的普通開發者不需要擔心CSRF的漏洞，只需要在所有安全敏感請求的末尾添加壹個攔截器來檢查Referer的值即可。特別是對於目前已有的系統，不需要改變當前系統的任何已有代碼和邏輯，無風險，非常方便。
然而，這種方法並不是萬無壹失的。Referer的值由瀏覽器提供。雖然在HTTP協議中有明確的要求，但是Referer的具體實現可能每個瀏覽器都不壹樣，也不能保證瀏覽器本身沒有安全漏洞。使用驗證Referer值的方法是依靠第三方(也就是瀏覽器)來保證安全。理論上，這是不安全的。事實上，對於壹些瀏覽器，如IE6或FF2，已經有壹些方法來篡改Referer值。如果bank.example網站支持IE6瀏覽器，黑客可以將用戶瀏覽器的Referer值設置為以bank.example域名開頭的地址，這樣就可以通過驗證，進行CSRF攻擊。
即使是最新的瀏覽器，黑客也無法篡改Referer值，這種方法還是有問題的。由於Referer值會記錄用戶的訪問來源，因此壹些用戶認為這樣會侵犯自己的隱私權，尤其是壹些機構擔心Referer值會將機構內網的壹些信息泄露到外網。因此，用戶可以設置自己的瀏覽器，以便在發送請求時不再提供Referer。當他們正常訪問銀行網站時，網站會認為這是CSRF攻擊，因為該請求沒有Referer值，並拒絕合法用戶的訪問。
2.向請求地址添加壹個令牌並驗證它。
CSRF攻擊之所以能夠成功，是因為黑客完全可以偽造用戶的請求，而請求中的所有用戶認證信息都存在於cookie中，所以黑客可以在不知道這些認證信息的情況下，直接使用用戶自己的cookie通過安全認證。要抵抗CSRF，關鍵是把信息放在黑客無法偽造的請求中，而這些信息並不存在於cookie中。您可以在HTTP請求中以參數的形式添加壹個隨機生成的令牌，並在服務器端設置壹個攔截器來驗證這個令牌。如果請求中沒有令牌或令牌內容不正確，可能會被認為是CSRF攻擊，請求會被拒絕。
這種方法比檢查Referer更安全。令牌可以在用戶登錄並放入會話後生成，然後可以在用戶每次請求時從會話中取出，並與請求中的令牌進行比較。但是，這種方法的難點在於如何將令牌作為參數添加到請求中。對於GET請求，令牌將被追加到請求地址，這樣URL就變成了http://url？csrftoken=tokenvalue .對於POST請求，將其添加到表單的末尾，以便將令牌以參數的形式添加到請求中。但是，在壹個網站中，有很多地方可以接受請求。每個請求加壹個令牌很麻煩，很容易漏掉。通常的方法是在每次加載頁面時使用javascript遍歷整個dom樹，並為dom中的所有A和form標記添加壹個令牌。這樣可以解決大部分請求，但是這種方法對頁面加載後動態生成的html代碼沒有影響，程序員需要在編碼時手動添加token。
這種方法的另壹個缺點是很難保證令牌本身的安全性。特別是在壹些論壇和其他支持用戶發布自己內容的網站上，黑客可以在上面發布他們個人網站的地址。因為系統還會給這個地址添加壹個令牌，黑客可以在自己的網站上獲得這個令牌，並立即發起CSRF攻擊。為了避免這種情況，系統可以在添加令牌時添加壹個判斷。如果鏈接是鏈接到自己的站點，後面加個令牌，如果是通向外網，就不要加了。然而，即使這個csrftoken沒有以參數的形式附加到請求中，黑客的網站也可以通過Referer獲得這個令牌值，從而發起CSRF攻擊。這也是為什麽有些用戶喜歡手動關閉瀏覽器的Referer功能的原因。
3.自定義HTTP頭中的屬性並驗證它。
這個方法也使用令牌並驗證它。與前面的方法不同，令牌不是作為參數放在HTTP請求中，而是放在HTTP頭中的壹個自定義屬性中。通過XMLHttpRequest類，可以壹次性將HTTP頭屬性csrftoken添加到所有這樣的請求中，並將令牌值放入其中。這解決了在以前的方法中向請求添加令牌的不便。同時，通過XMLHttpRequest請求的地址不會被記錄在瀏覽器的地址欄中，也不用擔心token會通過Referer泄露給其他網站。
但是，這種方法有很大的局限性。XMLHttpRequest請求通常用於Ajax方法中本地頁面的異步刷新。並不是所有的請求都適合由該類發起，通過這類請求獲取的頁面無法被瀏覽器記錄，從而無法進行前進、後退、刷新、收藏等操作，給用戶帶來不便。另外，對於不受CSRF保護的遺留系統，用這種方法保護無疑是不可接受的，把所有請求都改成XMLHttpRequest請求，幾乎會重寫整個網站。
自springsecurity3.2.0版本3.2.0以來，已經提供了針對csrf攻擊的保護。
版本升級配置
HTTP配置
前端配置
壹般我們的項目中有壹個公共文件(比如壹個公共js文件)，每個頁面都會引用這個文件，所以我們可以在公共文件中做如下配置:
$.ajaxSetup意味著將這個頭和令牌添加到我們所有的ajax請求中，或者將它們放入表單:
註意_csrf要匹配spring security的配置文件中的配置，默認值是_csrf。