《白帽子講Web安全》12-Web框架安全
阿新 • • 發佈:2019-02-02
第12章 Web框架安全
總的來說,實施安全方案,要達到好的效果,必須要完成兩個目標:
- 安全方案正確、可靠
- 能夠發現所有可能存在的安全問題,不出現遺漏
12.1 MVC框架安全
- MVC架構:Model-View-Controller
- 一個優秀的安全方案,應該是:在正確的地方,做正確的事情。
- 資料在經過不同的應用邏輯處理後,其內容可能會發生改變。因此在設計安全方案時,要考慮到資料可能的變化,認真斟酌安全檢查插入的時機。
- 在框架中實施安全方案,比由程式設計師在業務中修復一個個具體的bug,有著更多的優勢。
- 有些安全問題可以在框架中統一解決,能夠大大節省程式設計師的工作量,節約人力成本。
- 對於一些常見的漏洞來說,由程式設計師一個個修補可能會出現遺漏,而在框架中統一解決,有可能解決“遺漏”的問題。
- 在每個業務裡修補安全漏洞,補丁的標準難以統一。而在框架中集中實施的安全方案,可以使所有基於框架開發的業務都嗯那個受益,從安全方案的有效性來說,更容易把握。
12.2 模板引擎與XSS防禦
- 從MVC架構來說,XSS時發生在View層,因此使用“輸出編碼”的防禦方法更加合理。
- 這意味著需要針對不同上下文的XSS攻擊場景,使用不同的編碼方式。
- 當代流行的MVC框架中,View層常用的技術是使用模板引擎對頁面進行渲染,比如Django Templates作為模板引擎。
- Django的auto-escape機制。
- 開發者在使用框架時,應該慎重對待安全問題,不可盲從官方指導文件。
12.3 Web框架與CSRF防禦
- CSRF攻擊的目標,一般都會產生“寫資料”操作的URL,比如“增刪改”;而“讀資料”操作並不是CSRF攻擊的目標,因為在CSRF的攻擊過程中攻擊者無法獲取到伺服器端返回的資料,攻擊者只是借用戶之手觸發伺服器動作,所以讀資料對於CSRF來說並無直接的意義。
- 因此,在Web應用開發中,有必要對“讀操作”和“寫操作”予以區分,比如要求所有的“寫操作”都使用HTTP POST。
- POST的使用,對於保護token有者積極的意義,而security token的私密性(不刻預測性原則),是防禦CSRF攻擊的基礎。
- 完整的CSRF防禦方案,對於Web框架來說有以下基礎地方需要改動。
- 在Sessin中繫結token
- 在form表單中自動填入token欄位
- 在Ajax請求中自動新增token,這可能需要已有的Ajax封裝實現的支援
- 在伺服器端對比POST提交引數的token與Session中繫結的token是否一致,以驗證CSRF攻擊。
- 書中針對Spring MVC,Django和Rails等框架舉例。
12.4 HTTP Headers管理
- 在Web框架中,可以對HTTP頭進行全域性化的處理,因此一i邪惡基於HTTP頭的安全方案可以很好地實施。
- 對於框架來說,管理好跳轉目的地址是很有必要的。一般來說,可以在兩個地方做這件事:
- Web框架提供的統一跳轉函式,在內部實現一個白名單;
- 控制HTTP的Location欄位,限制Location的值只能是哪些地址(本質還是白名單)
- 有很多與安全相關的Headers,也可以統一在Web框架中配置。
- HttpOnly Cookie
12.5 資料持久層與SQL注入
- 使用ORM(Object/Realtion Mapping)框架對SQL注入是有積極意義的。
- 對抗SQL注入的最佳方式就是使用“預編譯繫結變數”。
- 實際解決SQL注入是,有一個難點是應用複雜後,程式碼數量龐大,難以把可能存在SQL注入的地方不遺漏地找出來,而ORM框架為我們發現問題提供了一個便捷的途徑。
- 使用Web框架提供的功能,在程式碼風格上更加統一,也更利於程式碼審計。
12.6 還能想到什麼
- 凡是在Web框架中可能實現的安全方案,只要對效能沒有太大的損耗,都應該考慮實施。
- 在設計整體安全方案時,比較科學的方法:
- 首先建立威脅模型
- 然後再判斷哪些威脅時可以在框架中得到解決的
- 在設計Web框架安全解決方案時,還需要儲存好安全檢查的日誌。
- 設計Web框架安全也要與時俱進。
12.7 Web框架自身安全
- Struts2命令執行漏洞
- 遠端執行程式碼的漏洞
- Spring MVC命令執行漏洞
- 遠端執行命令漏洞
- Django命令執行漏洞
- 遠端執行命令漏洞(“命令注入”漏洞)