第12章 Web框架安全

總的來說，實施安全方案，要達到好的效果，必須要完成兩個目標：
- 安全方案正確、可靠
- 能夠發現所有可能存在的安全問題，不出現遺漏

12.1 MVC框架安全

1. MVC架構：Model-View-Controller
2. 一個優秀的安全方案，應該是：在正確的地方，做正確的事情。
   
   • 資料在經過不同的應用邏輯處理後，其內容可能會發生改變。因此在設計安全方案時，要考慮到資料可能的變化，認真斟酌安全檢查插入的時機。
3. 在框架中實施安全方案，比由程式設計師在業務中修復一個個具體的bug，有著更多的優勢。
   
   • 有些安全問題可以在框架中統一解決，能夠大大節省程式設計師的工作量，節約人力成本。
   • 對於一些常見的漏洞來說，由程式設計師一個個修補可能會出現遺漏，而在框架中統一解決，有可能解決“遺漏”的問題。
   • 在每個業務裡修補安全漏洞，補丁的標準難以統一。而在框架中集中實施的安全方案，可以使所有基於框架開發的業務都嗯那個受益，從安全方案的有效性來說，更容易把握。

12.2 模板引擎與XSS防禦

1. 從MVC架構來說，XSS時發生在View層，因此使用“輸出編碼”的防禦方法更加合理。
   
   • 這意味著需要針對不同上下文的XSS攻擊場景，使用不同的編碼方式。
2. 當代流行的MVC框架中，View層常用的技術是使用模板引擎對頁面進行渲染，比如Django Templates作為模板引擎。
3. Django的auto-escape機制。
4. 開發者在使用框架時，應該慎重對待安全問題，不可盲從官方指導文件。

12.3 Web框架與CSRF防禦

1. CSRF攻擊的目標，一般都會產生“寫資料”操作的URL，比如“增刪改”；而“讀資料”操作並不是CSRF攻擊的目標，因為在CSRF的攻擊過程中攻擊者無法獲取到伺服器端返回的資料，攻擊者只是借用戶之手觸發伺服器動作，所以讀資料對於CSRF來說並無直接的意義。
2. 因此，在Web應用開發中，有必要對“讀操作”和“寫操作”予以區分，比如要求所有的“寫操作”都使用HTTP POST。
   
   • POST的使用，對於保護token有者積極的意義，而security token的私密性（不刻預測性原則），是防禦CSRF攻擊的基礎。
3. 完整的CSRF防禦方案，對於Web框架來說有以下基礎地方需要改動。
   
   • 在Sessin中繫結token
   • 在form表單中自動填入token欄位
   • 在Ajax請求中自動新增token，這可能需要已有的Ajax封裝實現的支援
   • 在伺服器端對比POST提交引數的token與Session中繫結的token是否一致，以驗證CSRF攻擊。
   • 書中針對Spring MVC，Django和Rails等框架舉例。

12.4 HTTP Headers管理

1. 在Web框架中，可以對HTTP頭進行全域性化的處理，因此一i邪惡基於HTTP頭的安全方案可以很好地實施。
2. 對於框架來說，管理好跳轉目的地址是很有必要的。一般來說，可以在兩個地方做這件事：
   
   • Web框架提供的統一跳轉函式，在內部實現一個白名單；
   • 控制HTTP的Location欄位，限制Location的值只能是哪些地址（本質還是白名單）
3. 有很多與安全相關的Headers，也可以統一在Web框架中配置。
4. HttpOnly Cookie

12.5 資料持久層與SQL注入

1. 使用ORM（Object/Realtion Mapping）框架對SQL注入是有積極意義的。
2. 對抗SQL注入的最佳方式就是使用“預編譯繫結變數”。
   
   • 實際解決SQL注入是，有一個難點是應用複雜後，程式碼數量龐大，難以把可能存在SQL注入的地方不遺漏地找出來，而ORM框架為我們發現問題提供了一個便捷的途徑。
3. 使用Web框架提供的功能，在程式碼風格上更加統一，也更利於程式碼審計。

12.6 還能想到什麼

1. 凡是在Web框架中可能實現的安全方案，只要對效能沒有太大的損耗，都應該考慮實施。
2. 在設計整體安全方案時，比較科學的方法：
   
   • 首先建立威脅模型
   • 然後再判斷哪些威脅時可以在框架中得到解決的
3. 在設計Web框架安全解決方案時，還需要儲存好安全檢查的日誌。
4. 設計Web框架安全也要與時俱進。

12.7 Web框架自身安全

1. Struts2命令執行漏洞
   
   • 遠端執行程式碼的漏洞
2. Spring MVC命令執行漏洞
   
   • 遠端執行命令漏洞
3. Django命令執行漏洞
   
   • 遠端執行命令漏洞（“命令注入”漏洞）