CSRF防御方案:
(1)在Session中綁定token。如果不能保存到服務器端Session中,則可以替代為保存到Cookie里。
(2)在form表單中自動填入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等問題的解決方案。
下一篇:一周內蘇州連發85起網購詐騙