Web 應用的自動化安全測試技術通常分爲兩類：黑盒安全測試和白盒安全測試。這兩種方法孰優孰劣一直衆口不一。廣爲公認的是，這兩種方式各有優缺點，且具備良好的互補性。下面筆者簡單介紹一下兩種測試技術的原理，便於讀者瞭解這兩種技術的優缺點。數據庫
白盒安全測試技術
白盒安全測試有時候也被稱爲靜態測試，主要基於源代碼進行分析。所以，白盒安全測試不須要部署、運行整個應用。白盒安全測試主要分析代碼中的函數及其調用關係，分析數據在其中的不一樣的執行路徑。常見白盒安全測試工具主要採用污染分析（Taint Analysis）方法，它檢測代碼中全部可能的數據流，尋找黑客能夠利用的輸入數據，跟蹤這些數據在整個應用中的使用過程，以及最終的數據去向，結合規則來判斷當前數據流是否存在安全漏洞。例如，若是某個輸入字段經過 HTTP 請求傳入系統中，最終被編織到某個數據庫查詢語句被執行，白盒安全檢測工具就能根據這個數據流分析出可能存在 SQL 注入漏洞。白盒安全測試的優點很明顯，它一般能檢查整個應用中的全部代碼，分析代碼中的全部執行路徑，精肯定位到具體代碼行存在的安全漏洞。但它的缺點也比較多，譬如：apache
- 基於白盒安全測試的原理，它能檢測應用中代碼的全部執行路徑和數據流。但事實總跟理論有些差距，實際項目中白盒安全測試並不能真正作到這一點。譬如：若是代碼中採起了反射機制，白盒安全就難以處理這類邏輯；若是代碼中存在大量多線程併發，白盒安全測試也難以檢測這些併發問題；此外，若是應用的控制流是基於配置文件實現的，譬如基於 Spring 配置，白盒安全測試工具也難以分析這類框架下完整的數據流。
- 白盒安全測試僅側重代碼的分析，而不考慮中間件部署等問題。測試過程不依賴運行環境雖然簡化了安全測試方法，可是存在不少基礎中間件層的安全漏洞，白盒安全測試技術沒法檢測此類問題，能夠說這是白盒安全測試先天性的不足。
- 白盒安全測試引覺得傲的一點是，它能測試代碼中的全部執行路徑。這實際上是一把雙刃劍。實際項目運行過程當中，實際會執行到的路徑跟理論存在的路徑相比，會遠遠小於理論路徑數量。讀者能夠找些代碼進行度量分析，某些方法圈複雜度可能會 30 以上，但實際咱們不必定爲它寫那麼多單元測試用例，咱們的單元測試用例每每只會覆蓋到實際項目可能會命中的那些路徑。所以，白盒安全測試工具每每會檢測出大量的安全漏洞，其中大量問題事實上在運行期永遠不會被執行到。
黑盒安全測試技術
黑盒安全測試有時候也被稱爲動態測試。這種方法主要測試應用的功能點，而不是分析內部代碼。黑盒安全不須要測試人員具有編程能力，不須要測試人員瞭解代碼實現的邏輯，所以經常是業界安全測試人員的首選安全測試方法。黑盒安全測試過程當中，每每經過網頁爬蟲模擬正經常使用戶訪問應用站點，探測出應用站點的所有訪問路徑，而後基於探測結果生成安全測試用例。黑盒測試工具會分析安全測試用例觸發的 HTTP 響應，判斷其中是否存在某種安全漏洞。由此看出，黑盒測試時，被測站點每每被視爲一個黑盒，咱們不用去關心它如何運行，用何種語言編寫。黑盒測試技術從用戶的角度，或者說是從黑客的角度去分析測試站點，它所發現的問題每每更爲精確，同時也能檢測出中間件配置問題所致使的安全漏洞。黑盒安全測試一樣也存在着一些不足。編程
- 測試覆蓋率較低。因爲黑盒安全測試是從用戶角度分析站點的 URL，而不是從源代碼級分析方法的參數，所以，黑盒測試的測試覆蓋率會小於白盒安全測試。對於黑盒安全測試工具而言，如下場景都很難自動探測出來。譬如：根據特定表單字段內容控制的不一樣頁面邏輯；某個請求存在隱式的參數（即某些參數沒公開，經過 URL 發現不到這些參數）等。
- 黑盒安全測試沒法發現某些安全漏洞。因爲黑盒安全測試本質上基於服務器端的響應來驗證漏洞是否存在。大多數安全漏洞能夠經過這種方式分析出來，但不是全部漏洞都能如此。譬如：密碼以明文存儲，這種安全隱患就不能經過黑盒測試檢測出來；系統存在默認調試密碼的現象也沒法經過黑盒測試檢測出來。因而可知，只要被污染參數沒有被寫回 HTTP 響應，黑盒安全測試技術就沒法探測出相應的漏洞。
- 黑盒安全測試所發現的安全漏洞修復難度大。儘管黑盒安全測試所發現的安全漏洞容易被重現，但根據 HTTP 請求 / 響應找出存在安全漏洞的代碼行並非一件容易的事情。相信從事過相關安全漏洞修復的讀者對此都感覺深入。
- 黑盒安全測試效率較低。根據黑盒安全測試原理能夠知道，黑盒測試工具每每會根據所探測出來的 URL 設計安全測試用例（也稱爲測試變體），譬如一個 URL 中存在三個參數，黑盒測試工具會爲每一個參數都設計大量的測試變體，如 XSS 變體、注入變體等等。隨着已知漏洞數量的增長，須要設計的測試變體會愈來愈多。這樣對於一個 URL 的測試變體每每會有好幾十個，甚至上百個。這種測試方法不只僅會對被測試站點帶來較高的訪問壓力，對於測試機器而言，也會因多線程發送大量請求、分析大量響應致使測試性能低下。尤爲對於一個大型站點來講，黑盒安全測試的性能每每比較低下，須要針對性的進行掃描性能調優。
因而可知，黑盒安全測試和白盒安全測試兩種方法各具特點和不足，且二者具有較好的互補性。目前業界基本公認，二者的結合（即混合測試，Hybrid Test）是下一代安全檢測技術的發展趨勢。AppScan Standard v8.5（下文簡稱 AppScan）新發布了 Glass Box 安全測試技術（下文稱之爲"玻璃盒測試技術"），創新地在黑盒安全測試工具中引入了代碼分析技術，實現了混合測試。下文筆者將跟讀者分析這一新技術，探究它的運行原理，幫助讀者掌握並運用到實際項目中去。網頁爬蟲
新一代玻璃盒安全測試技術
近年來 IBM 安全團隊一直致力於研究開發新一代安全檢測技術，即玻璃盒安全測試技術，並在 2009 年爲之申請了專利。簡言之，利用玻璃盒測試技術，測試工具能夠在作黑盒測試的同時，觀察並分析服務器端運行期所執行的代碼。研究發現，這種新方法改進了傳統黑盒測試的不足。圖 1 展現了玻璃盒測試技術的基本原理，下文將詳細介紹玻璃盒安全測試技術是如何綜合黑白盒兩種技術之長。瀏覽器
圖 1. 玻璃盒測試原理圖
咱們能夠看到，跟之前版本的 AppScan 相比，這裏多了兩個組件：玻璃盒代理（Glass Box Agent）和玻璃盒引擎（Glass Box Engine）。玻璃盒代理是用來採集信息的應用程序，負責監控、收集和分析所在組件中的有價值信息，而後將這些信息發送給 AppScan，AppScan 會基於這些信息改進探索和測試。根據 IBM 發佈的玻璃盒技術白皮書，玻璃盒代理一般能夠部署在 Web 應用環境中的不一樣組件中，譬如 Web 應用服務器、操做系統或者數據庫。不一樣環境中的玻璃盒代理所收集的信息不一樣。表 1 闡述了不一樣位置的玻璃盒代理所採集的不一樣信息，以及這些信息會如何改進測試結果。tomcat
表 1. 常見玻璃盒代理
| 代理所在位置 | 所採集信息 | 改善點 | ||
|---|---|---|---|---|
| 精確度 | 性能 | 漏洞報告 | ||
| Web 應用 | 運行期代碼信息 | √ | √ | |
| 源代碼信息 | √ | |||
| Web 應用服務器 | 配置文件 | √ | √ | √ |
| Web 服務器日誌 | √ | √ | ||
| 操做系統 | 文件建立 | √ | ||
| 進程信息 | √ | |||
| 註冊表訪問 | √ | |||
| 數據庫服務器 | SQL 執行信息 | √ | √ | |
咱們以表 1 中最後的數據庫端的玻璃盒代理爲例。Web 應用一般使用外部的關係型數據庫來存儲信息。經過在數據庫端安裝玻璃盒代理，黑盒測試工具便可監控到 Web 應用所執行的 SQL 語句。當黑盒測試工具發送一個 SQL 注入測試變體的時候，玻璃盒代理會分析數據庫端實際執行的 SQL 語句，以此判斷當前攻擊是否成功。若是玻璃盒代理探測到攻擊已經成功，它將通知黑盒測試工具，黑盒測試工具從而會報告存在 SQL 注入安全漏洞。請注意，這種判斷方法跟基於 HTTP 響應對比的優點：若是 SQL 執行結果沒有被回寫到 HTTP 響應中，傳統上的基於 HTTP 響應分析的方法就不能檢測出當前存在 SQL 注入漏洞，而玻璃盒測試方法能夠測試成功。此外，玻璃盒代理經過監控數據庫端執行的 SQL 語句，能夠知道當前 SQL 存在哪些參數，從而通知黑盒測試工具僅對這些參數發送 SQL 注入測試變體。這樣就大大下降了無效測試變體的數量，從而提高了總體掃描效率。安全
AppScan v8.5 目前集成的的玻璃盒代理是運行期代碼代理。這種代理能夠在 Web 應用程序啓動加載的時候，經過動態代理一類的機制，將監控代碼動態注入到 Web 應用程序代碼中。這樣運行期代碼代理能夠監控到 Web 應用代碼的執行狀況，分析出代碼的邏輯關係和運行期的數據流，從而找到數據的源和接收器。經過運行期代碼代理，能夠輕鬆定位安全漏洞所在代碼，並且利用數據的源和接收器分析，安全漏洞的斷定也比較容易和準確。服務器
以上對玻璃盒代理的分析，從原理上解釋了玻璃盒測試如何克服了傳統黑盒測試工具和白盒測試工具的常見不足。下面咱們總結一下玻璃盒技術的優點所在。
加強了探索能力
在黑盒測試工具的探測階段，玻璃盒代理可以基於白盒分析找出應用中的隱藏參數，通知黑盒測試工具對隱藏參數進行探測。這種方式改善了黑盒測試工具的測試覆蓋率。咱們經過一個簡單的例子來講明，參見清單 1 中的代碼。
清單 1. 影響測試覆蓋率的隱藏參數
String debug = request.getParameter("debug");
if(debug == "enabled"){
// hidden code
}
若是黑盒測試工具沒有發送 debug 參數爲 enabled 的請求，這段隱藏代碼就永遠不會被測試到，黑盒測試工具也就沒法檢測這段代碼是否存在安全漏洞，這就影響了測試覆蓋率。玻璃盒測試技術經過玻璃盒代理找到這些代碼分支，並查明這些代碼分支的調用方式。玻璃盒代理會通知黑盒測試工具，後者會利用相似例中 debug 參數，發送測試變體去檢測這段代碼。
加強了測試能力
利用玻璃盒測試技術，黑盒測試工具能夠準確知道操做系統、應用服務器、數據庫及相關第三方組件等信息，從而改進測試策略的針對性，提升了測試精確性和測試效率。同時，經過玻璃盒代理監控服務器端環境，黑盒測試工具可以更好地驗證安全漏洞是否存在。譬如那些不回寫 HTTP 響應的安全漏洞，如日誌僞造、不安全的加密存儲及不合理的文件操做權限等。此外，玻璃盒技術也有利於提升安全漏洞報告的準確度，準確提示用戶漏洞所在的文件名、方法名及代碼行數等。
提高了效率和準確度
使用過黑盒測試工具的讀者都知道，安全測試的時候常常須要權衡性能和準確度這兩個指標。爲了提升準確度，就須要增長測試變體數量，這就影響了測試性能；經過算法優化減小測試變體，仍是會可能下降測試準確度。因爲玻璃盒測試技術洞悉服務器端的環境和代碼，利用這些信息，黑盒測試工具能夠精確針對測試環境編制測試變體，這樣的話，測試變體的數量會大大下降，而其測試覆蓋率也不會受影響，因此可以保證測試準確度的同時，提升了測試效率。
IBM 研究人員曾對 WAVSEP（Web Application Vulnerability Scanner Evaluation Project）應用進行了對比測試，利用黑盒測試技術僅能測試出 62 個安全漏洞，而啓用了玻璃盒測試技術後，AppScan 能測試出該網站的所有 198 個安全漏洞。這些數據進一步驗證了玻璃盒測試技術的先進性。
掌握玻璃盒測試技術
在 AppScan 中啓用玻璃盒測試很是簡單，歸納下來有三個步驟：
- 在應用服務器上安裝玻璃盒測試代理程序，此操做僅需執行一次。雖然玻璃盒代理程序能夠被安裝到多臺服務器上，但一次掃描過程當中只能包含一臺服務器。
- 在 AppScan 中定義已安裝好的代理程序，以便它能與這些代理程序進行通訊。同一個玻璃盒代理程序能夠被多個 AppScan 使用，但不能同時使用。
- 配置掃描時啓用所需的玻璃盒代理程序。缺省狀況下這是自動配置的，能夠在"掃描配置"-"Glass Box 視圖"中爲每一個掃描調整代理程序配置。
另外，須要注意的是，若是 AppScan 自動更新的時候，若提示更新服務器代理程序，請務必執行該操做，以便 AppScan 和玻璃盒代理程序中的規則保持同步。同時，一旦玻璃盒代理程序完成更新，要從新啓動 Web 應用服務器，從新加載服務器應用程序。
安裝玻璃盒代理程序
目前版本的玻璃代理程序主要支持主流 Java EE 應用程序服務器（如 JBoss，Tomcat，WebLogic 和 WebSphere）。玻璃盒代理程序能夠自動化安裝，但考慮到 Java EE 應用服務器的配置一般較爲複雜，爲支持客戶手工部署需求，玻璃盒代理程序也能夠手動安裝。AppScan 的用戶手冊中有詳細的解釋和示例。簡而言之，玻璃盒代理程序安裝主要包括 Java 代理程序包的配置和代理應用 WAR 包文件的部署。下面筆者在本機 Tomcat 環境中自動安裝玻璃盒代理程序。
- 打開文件夾"C:\Program Files (x86)\IBM\Rational AppScan\Glass box"，雙擊 GB_Setup.exe 程序啓動安裝。（由於筆者是在本地安裝，因此直接執行這個安裝程序。若是應用服務器不在本機，則須要將這個文件夾的內容拷貝到應用服務器所在電腦上，確保文件訪問權限正常後，再執行這個文件。）
圖 2. 選擇應用服務器
- 選擇 Apache Tomcat 後，點擊"下一步"，安裝程序會提示指定 Tomcat 所在路徑，譬如"D:\apache-tomcat-6.0.32"，而後點擊"下一步"。
- 安裝程序提示設置代理程序憑證，這裏的用戶名和密碼未來須要記錄到 AppScan 中，AppScan 利用這個賬號跟代理程序進行通訊。
圖 3. 設置代理程序的訪問賬號
最後確認安裝文件夾位置，點擊"安裝"完成代理程序的安裝。安裝程序會幫助你驗證代理程序是否安裝成功。咱們也能夠手工經過瀏覽器來驗證：在瀏覽器中輸入"http://localhost/GBootStrap/ "（讀者需根據本機 Tomcat 的配置修改機器名和端口），若是系統提示輸入密碼，則輸入步驟三提供的賬號，查看到"Glass Box API"的話，即說明安裝成功。
註冊玻璃盒代理程序
點擊菜單"工具"-"Glass Box 代理程序管理"，打開管理界面，點擊"+"按鈕，註冊剛纔安裝的玻璃盒代理程序，如圖 4 所示。而後點擊"肯定"關閉對話框便可。
圖 4. 註冊玻璃盒代理程序
啓用玻璃盒代理程序
當掃描某個應用服務器上的 Web 站點時，咱們能夠在掃描配置中啓用安裝在這臺應用服務器上的玻璃盒代理程序。缺省狀況下，AppScan 會自動啓用目標應用服務器上已註冊好的代理程序。在"掃描配置"對話框中，選擇"探索 -Glass Box"便可看到配置項，如圖 5 所示。
圖 5. 啓用玻璃盒代理程序
案例
下文筆者將針對本地的一個應用使用 AppScan 進行兩次掃描，兩次測試都掃描相同的站點，第一次不啓用玻璃盒掃描，第二次啓用玻璃盒掃描，其餘配置徹底相同。咱們來看看兩次掃描結果的區別。
首先筆者使用 AppScan 測試本地的 wavsep 程序：
- 點擊"文件"-"新建"，使用"常規掃描"模板，設置"Web 應用程序掃描"。起始 URL 設置爲"http://localhost/wavsep/index-active.jsp"，登陸方法選擇"無"，使用"開發者精要"測試策略。
- 由於 AppScan 默認會啓用玻璃盒代理，這裏筆者暫將之停用。點擊"徹底掃描配置"，在"Glass Box"選項中，禁用"在探索階段使用 Glass Box"和"在測試階段使用 Glass Box"。點擊肯定，啓動全面自動掃描。
- 掃描完成後觀察狀態欄，咱們能夠看到已訪問的 URL 是 315 個。測試共發現 66 個安全問題，如圖 6 所示。
圖 6. 停用玻璃盒測試的掃描結果
接下來，筆者啓用玻璃盒代理，而後點擊"掃描"-"從新掃描（全面）"，利用玻璃盒測試從新掃描上述站點。結果如圖 7 所示。啓用玻璃盒測試後，AppScan 探索出 398 個 URL，測試發現 70 個安全問題。因而可知，啓用玻璃盒掃描後，AppScan 的探測能力加強，發現了更多的安全問題。
圖 7. 啓用玻璃盒測試的掃描結果
總結
玻璃盒測試技術是 IBM 發佈的一項領先混合測試技術，它綜合了黑盒安全測試和白盒安全測試的二者之長，克服了傳統黑盒安全測試的不足，加強了 AppScan Standard 的探索能力，提升了掃描效率和結果準確性。本文筆者跟讀者分享了玻璃盒測試技術的原理，介紹了 AppScan 中玻璃盒測試的使用方法，同時結合案例，跟讀者演示了停用玻璃盒測試和啓用玻璃盒測試兩種場景下的測試結果，經過這兩個測試結果的對比，讓讀者更直觀領略到玻璃盒測試技術的領先。鑑於筆者經驗有限，如有不及之處，歡迎讀者來信交流。
參考資料
學習
- 查看文章"Web 應用安全利器：IBM Rational AppScan"，瞭解 Rational AppScan Standard 的基本使用。
- >查看 IBM 白皮書"Glass box testing: Thinking inside the box"，瞭解 IBM 玻璃盒測試技術的研究成果。
- 參考 Rational AppScan 產品專題，查看 IBM Rational AppScan 產品介紹及文檔庫。
- 參考 IBM X-Force 網站，瞭解 IBM 發佈的最新因特網威脅趨勢及應對威脅的建議。
- 參考WAVSEP 網站，瞭解 Web 應用安全漏洞掃描工具評估項目。
- 訪問 IBM developerWorks 中國網站 Rational 專區，得到關於 IBM Rational 軟件交付平臺（Rational Software Delivery Platform）產品的技術資源和最佳實踐。
- 訂閱 IBM developerWorks 時事通信，一份關於 developerWorks 指南、文章、下載、社區活動、網絡廣播和技術講座的電子週刊。
得到產品和技術
- 下載免費的 IBM Rational AppScan Standard Edition（標準版）試用版。
- 獲取免費的 Rational 軟件工具包系列，瞭解最新的 IBM Rational 軟件開發工具技術文檔和資源。
- 下載更多免費的 IBM Rational 試用版軟件，瞭解 IBM Rational 軟件的最新特性。
- 獲取更多 IBM 試用版軟件，並熟練掌握來自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的開發工具和中間件產品，用這些試用版軟件開發您的下一個項目。這些試用版軟件能夠免費直接從 developerWorks 下載。