一、MVC框架安全

從數據的流入來看，用戶提交的數據先後流經了View層、Controller、Model層，數據流出則反過來。在設計安全方案時，要牢牢把握住數據這個關鍵因素。

比如在Spring Security中，通過URL pattern實現的訪問控制，需要由框架來處理所有用戶請求，在Spring Security獲取了URL handler基礎上，才有可能將後去的安全檢查落實。在Spring Security的配置中，第一步就是在web.xml文件中增加一個filter，接管用戶數據。

<filter>
    <filter-name
 
>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</
 
filter-mapping>

一些主要的Web安全威脅，如XSS、CSRF、SQL註入、訪問控制、認證、URL跳轉等不涉及業務邏輯的安全問題，都可以集中放在MVC框架中解決。

二、模板引擎與XSS防禦

在View層，可以解決XSS問題。XSS攻擊是在用戶的瀏覽器上執行的，其形成過程則是在服務器端頁面渲染時，註入了惡意的HTML代碼導致的。從MVC架構來說，是發生在View層，因此使用“輸出編碼”的防禦方法更加合理，這意味著需要針對不同上下文的XSS攻擊場景，使用不同的編碼方式。

三、Web框架與CSRF防禦

在Web框架中可以使用security token解決CSRF攻擊的問題。

CSRF攻擊的目標，一般都會產生“寫數據”操作的URL，因為在CSRF的攻擊過程中攻擊者無法獲取到服務器端返回的數據，攻擊者只是借用戶之手觸發服務器的動作，所以讀數據對於CSRF來說無直接的意義（但是如果同時存在XSS漏洞或者其他的跨域漏洞，則可能會引起別的問題，在這裏，僅僅就CSRF對抗本身進行討論）。

在Web應用開發中，有必要對“讀操作”和“寫操作”予以區分，比如要求所有的“寫操作”都使用HTTP POST。

實際上POST本身並不足以對抗CSRF，因為POST也是可以自動提交的。但是POST的使用，對於保護token有著積極的意義，二security token的私密性（不可預測性原則），是防禦CSRF攻擊的基礎。

對於Web框架來說，可以自動地在所有涉及POST的代碼中添加token，這些地方包括所有的form表單、所有的Ajax POST請求等。

完整的CSRF防禦方案，對於Web框架來說有以下幾處地方需要改動。

• 在Session中綁定token。如果不能保存到服務器端Session中，則可以代替為保存到Cookie裏。
• 在form表單中自動填入token字段，比如<input type=hidden name="anti_csrf_token" value="$token"/>。
• 在Ajax請求中自動添加token，這可能需要已有的Ajax封裝實現的支持。
• 在服務器端對比POST提交參數的token與Session中綁定的token是否一致，以驗證CSRF攻擊。

四、HTTP Headers管理

在Web框架中，可以對HTTP頭進行全局化的處理，因此一些基於HTTP頭的安全方案可以很好地實施。

比如針對HTTP返回頭的CRLF註入。

類似的，針對30X返回好的HTTP Response，瀏覽器將會跳轉到Location指定的URL，攻擊者往往利用此類功能實施釣魚或詐騙。

HTTP/1.1 302 Moved Temporarily
(...)
Location: http://www.phishing.tld

對於框架來說，管理好跳轉地址是很有必要的。一般來說，可以在兩個地方這件事情：

• 如果Web框架中提供統一的跳轉函數，則可以在跳轉函數內部實現一個白名單，指定跳轉地址只能在白名單中；
• 另一種解決方式是控制HTTP的Location字段，限制Location的值只能是哪些地址，也能起到同樣的效果。

五、數據持久層與SQL註入

使用ORM（Object/Relation Mapping）框架對SQL註入是有積極意義的。對抗SQL註入的最佳方式就是使用“預編譯綁定變量”。

[筆記]《白帽子講Web安全》- Web框架安全