CSRF防禦方案:
（1）在Session中綁定token。如果不能保存到服務器端Session中，則可以替代爲保存到
Cookie裏。
（2）在form表單中自動填入token字段，比如 <input type=hidden name="anti_csrf_token"
value="$token" />。
（3）在Ajax請求中自動添加token，這可能需要已有的Ajax封裝實現的支持。
（4）在服務器端對比POST提交參數的token與Session中綁定的token是否一致，以驗證
CSRF***。
注意：
在Spring MVC以及一些其他的流行Web框架中，並沒有直接提供針對CSRF的保護，因
此這些功能需要自己實現。
因此，對於框架來說，管理好跳轉目的地址是很有必要的。一般來說，可以在兩個地方做
這件事情：
（1）如 果Web框架提供統一的跳轉函數，則可以在跳轉函數內部實現一個白名單，指定跳
轉地址只能在白名單中；
（2）另一種解決方式是控制HTTP的Location字段，限制Location的值只能是哪些地址，
也能起到同樣的效果，其本質還是白名單。
有很多與安全相關的Headers，也可以統一在Web框架中配置。比如用來對抗ClickJacking
的X-Frame-Options，需要在頁面的HTTP Response中添加：
X-Frame-Options: SAMEORIGIN
Web框架可以封裝此功能，並提供頁面配置。該HTTP頭有三個可選的值：SAMEORIGIN、
DENY、ALLOW-FROM origin，適用於各種不同的場景。
在前面的章節中，還曾提到Cookie的HttpOnly Flag，它能告訴瀏覽器不要讓JavaScript
訪問該Cookie，在Session劫持等問題上有着積極的意義，而且成本非常小。
但並不是所有的Web服務器、Web容器、腳本語言提供的API都支持設置HttpOnly Cookie，
所以很多時候需要由框架實現一個功能：對所有的Cookie默認添加HttpOnly，不需要此功能
的Cookie則單獨在配置文件中列出。
這將是非常有用的一項安全措施，在框架中實現的好處就是不用擔心會有遺漏。就
HttpOnly Cookie來說，它要求在所有服務器端設置該Cookie的地方都必須加上，這可能意味
着很多不同的業務和頁面，只要一個地方有遺漏，就會成爲短板。當網站的業務複雜時，登錄
入口可能就有數十個，兼顧所有Set-Cookie頁面會非常麻煩，因此在框架中解決將成爲最好的
方案。
一般來說，框架會提供一個統一的設置Cookie函數，HttpOnly的功能可以在此函數中實
現；如果沒有這樣的函數，則需要統一在HTTP返回頭中配置實現。
Spring Security爲Spring MVC的用戶提供了許多安全功能，比如基於URL的訪問控制、
加密方法、證書支持、OpenID支持等。但Spring Security尚缺乏諸如XSS、CSRF等問題的解
決方案。