Spring Security 3.2.0.RC1 Highlights: CSRF 防禦
1、CSRF攻擊
spring 安全驗證已經添加了對跨域請求偽造攻擊（Cross Site Request Forgery (CSRF) attacks）的防禦，非常強大。但是什麼是跨域請求偽造攻擊（CSRF），Spring 安全校驗是如何防禦攻擊CSRF攻擊的？我們通過一個具體的實例更好的理解spring如何實現防禦CSRF。
例如：用戶通過表單發送請求到銀行網站，銀行網站獲取請求參數後對用戶賬戶做出更改。在用戶沒有退出銀行網站情況下，訪問了攻擊網站，攻擊網站中有一段跨域訪問的代碼，可能自動觸發也可能點擊提交按鈕，訪問的url正是銀行網站接受表單的url。因為都來自於用戶的瀏覽器端，銀行將請求看作是用戶發起的，所以對請求進行了處理，造成的結果就是用戶的銀行賬戶被攻擊網站修改。
例如HTTP請求如下：
POST /transfer HTTP/1.1
Host: bank.example.com
Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly
Content-Type: application/x-www-form-urlencoded
amount=100.00&routingNumber=1234&account=9876
攻擊網站包含一個HTML頁面代碼如下：
這將生成一個JSON格式的數據
{ "amount": 100,"routingNumber": "evilsRoutingNumber","account": "evilsAccountNumber","ignore_me": "=test"}
如果你的應用沒有過濾內容格式（Content-Type），它將會受到攻擊。即使設置內容格式的過濾，攻擊者仍然可以通過將URL後綴修改“.json”的形式攻擊你的應用。
（2）CSRF和無狀態瀏覽器應用
如果我的應用無狀態的，這也並不意味著你是受保護的。事實上，如果一個用戶在一個已經請求過的web瀏覽器上 沒有做任何的工作，他們仍然易受CSRF攻擊。
例如。假設一個應用使用了包含已認證信息而非JSESSIONID的自定義Cookie，當應用受到CSRF攻擊時，自定義Cookie信息也會隨請求一起發過出去，就像先前例子中JSESSIONID被髮送一樣。
用戶使用基本的認證。這也有助於CSRF攻擊，應為瀏覽器所有請求信息中會自動帶著用戶名和密碼
3、同步令牌模式
問題的關鍵在於：來自銀行頁面的HTTP請求和來自惡意攻擊網站的請求信息完全一致，整個攻擊過程才會順利完成。這就是說我們需要採取方法拒絕來自惡意攻擊網站的非法請求，並且允許來自銀行頁面的合法請求。要實現這樣，我們需要提供一個惡意網站沒法提供的令牌防禦CSRF攻擊。
第一個解決方法就是使用同步令牌。這個解決方案是確保每個請求都附帶一個隨機生成的Token作為HTTP參數。當請求被提交時，服務器必須尋找放在Session或者Cookie中的Token值，並校驗請求中的Token值是否一直，如果不一致，服務器拒絕請求。
我們可以將Token值添加到每一個新的HTTP請求中，這種驗證請求來源的防範策略可以防範惡意網站不能讀取響應信息。另外，我們不想將隨機生成的Token信息添加到HTTP GET請求中，這樣會導致Token信息的洩露。
我們一起看一下實例是如何實現的。假設隨機生成的Token信息 作為HTTP的請求參數，並命名為“_csrf”，例如，轉賬的請求如下：
POST /transfer HTTP/1.1Host: bank.example.comCookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnlyContent-Type: application/x-www-form-urlencodedamount=100.00&routingNumber=1234&account=9876&_csrf=<secure-random>
你注意到我們添加了一個帶有隨機數的“_csrf”參數。現在惡意網站不能夠獲取到這個參數的實際值。當服務器不能正確匹配Token值時，轉賬過程就會失敗。
（未完待續）
文章翻譯自http://spring.io/blog/2013/08/21/spring-security-3-2-0-rc1-highlights-csrf-protection/和http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#csrf-attacks
閱讀更多 IT碼將 的文章
