基于滲透測試和源代碼掃描的軟件安全測試和開發
自從軟件誕生起，軟件的安全性一直就是每一個程序員不可回避的問題。面對“如何開發出具有高安全性軟件”與“如何利用軟件漏洞進行攻擊”，安全防護人員和黑客，就像中國武俠中的白道高手與黑道高手一樣，在相互的較量中提升自己的功力。隨著計算機語言的不斷進化和互聯網時代的到來，軟件所面臨的安全性問題也在發生著巨大改變。如果將最初的單機病毒攻擊成為軟件安全的第一紀，網絡攻擊稱為第二紀的話，那我們現在正處在軟件安全的第三紀 -- 應用攻擊。Gartner 的數據顯示，75% 的黑客攻擊發生在應用層。而來自 NIST 的數據更為驚人，有 92% 被發現的漏洞屬于應用層而不是網絡。
圖 1. 來自 Gartner 和 NIST 的數據
在這些軟件安全問題中，由于沒有在軟件設計和開發的過程中引入安全開發和測試的情況占了很大比例。其實，從 1968 年軟件工程誕生以來，人們一直企圖在軟件開發生命周期（SDLC）中引入安全開發的理念和方法，并由此出現了安全開發生命周期（Secure Development Lifecycle）。在本文中，我們就將結合示例來討論一下如何能夠在軟件開發生命周期中進行軟件安全開發和測試的問題。
圖 2. 安全開發生命周期示意圖#p#
軟件安全的“聞問望切”—基于黑盒的滲透測試
無論是在傳統的瀑布模型開發還是在方興未艾的敏捷軟件開發中，軟件測試都是重中之重。基于黑盒的滲透測試，是一種有效地將軟件安全性測試引入軟件開發生命周期（SDLC）中的方法。目前，許多軟件廠商都有針對各自技術研發出的滲透測試產品，如 IBM 的 AppScan、HP 的 WebInspect 等。說到滲透測試，就不能不提到由 Barton Miller 和 Lars Frederickson 等人在 1990 年提出的 Fuzz 技術。傳說在 1989 年一個雷電交加的夜晚，Barton Miller 用 Modem 連接自己的主機時，一個閃電過后，電路中的高低位互換了，Miller 由此想到了利用“crash、break、destroy”的方式來進行軟件測試的技術——fuzz。著名的 Fuzz 工具有 Fuzzing 網絡協議的 SPIKE、大桃子 Peach等等。Fuzz 技術自上世紀 90 年代初期起，慢慢的廣泛應用于系統平臺測試，應用軟件測試和網絡安全測試中。
下面我們將展示如何針對一個 Web 應用進行基于安全漏洞檢測的滲透測試。在這里我們選用 IBM Rational AppScan Standard Edition V7.8 （以下簡稱 AppScan）作為測試工具。
首先，我們在 AppScan 里建立一個新的掃描。AppScan 提供了許多預定義的掃描模板來幫助工程師建立針對不同 Web 應用和 Web Service 的掃描。
圖 3. 用 Rational AppScan 模板創建掃描
在這個示例中，我們將對架設在筆者本地的 Tomcat V5.5 服務器上一個名為 AltoroMutual 的電子商務系統進行安全滲透測試。
圖 4. 掃描 URL 配置
完成指定掃描的起始 URL 后，我們將一個擁有普通用戶權限的用戶名和密碼輸入到 AppScan 的自動登錄選項中。AppScan 還支持通過錄制并在測試時播放的方式進行登錄。
圖 5. AppScan 掃描登錄配置#p#
在 AppScan 中，測試策略的選擇會對不同的 Web 應用和 Web Service 產生影響。在本示例中我們僅選擇了針對 Web 應用和 Tomcat 應用服務器的具體中高漏洞等級的自定義測試策略。其實當我們打開每一個具體的測試策略時，會發現 AppScan 在其中定義了包括針對 Java、.NET、PHP 等不同類型網站測試類型種類和相應安全問題嚴重程度的級別。
圖 6. AppScan 安全測試策略配置
圖 7. AppScan 安全測試策略的詳細內容
通過設置 URL 入口、登陸方式和測試策略，AppScan 可以快速完成 Web 應用掃描的配置，從而開始漏洞檢測。其實，除了上述幾種設置，我們在圖 7 左側還可以發現更為完善的測試配置項，比如對參數和 Cookie 的設置，對掃描訪問的 URL 深度和廣度進行配置，對需要填充的表單如何填寫等等。
圖 8. 進行掃描中與發現的部分安全問題
AppScan 的掃描分為二部分，首先是進行探索，將發現的 URL 進行記錄；其次進入實際的測試步驟，將利用之前我們設定的測試策略進行滲透測試。下圖是 AltoroMutual 應用經過 AppScan 黑盒測試發現的部分安全問題。在 AppScan 主窗口左上方顯示的 AltoroMutual 被掃描出的網站 URL 結構圖，每個 URL 上發現的安全漏洞被標注在該 URL 后。左下方的儀表板顯示了安全問題的匯總，由于我們設定只針對中高級別的安全問題進行顯示，所以 Low Level、Info Level 的問題數量為 0。右上方將掃描出安全問題的種類和相應的 URL 一一羅列出來，而在其下方是每一個安全問題的詳細描述、修復建議和問題復現。
圖 9. AppScan 掃描完成后的主窗體#p#
一般來講，基于黑盒的滲透測試具有較高的測試準確率，但是我們依舊需要對掃描出的安全問題進行分析和甄別，從而給出合理的安全級別和修復建議。在本例中，我們具體分析一下 AltoroMutual 應用中存在的跨站腳本攻擊（XSS）問題。
點擊存在 XSS 問題的 URL“http:// www.2cto.com /altoromutual/sendFeedback”中“name”，可以看到產生這個 XSS 問題的詳細信息，我們通過查看“請求 / 響應”來對該漏洞進行復現和判斷其嚴重程度。點擊“請求 / 響應”的標簽后，我們發現 AppScan 發送了如下的內容給 AltoroMutual。利用將“1234>%22%27><img%20src%3d%22javascript:alert(14404)%22>”插入到 cfile=comments.txt&name 后，實施 XSS 攻擊。
圖 10. AppScan 向服務器端發送的帶有跨站腳本攻擊的數據
通過點擊“在瀏覽器中顯示”的方式，我們可以得以在 AppScan 內嵌瀏覽器中將這個跨站腳本攻擊問題復現。
圖 11. 在 AppScan 內置瀏覽器中進行 XSS 問題復現
通過上面的掃描示例我們不難看出，基于黑盒的滲透測試確是有較為高的準確率。在軟件開發生命周期中，滲透測試可以幫助測試人員、QA 人員在 FVT、UAT 等階段發現軟件安全問題。
但是，滲透測試的全面性和覆蓋率一直都是困擾著眾多軟件安全測試人員的問題。而且對于開發人員來說，他們更為關心如何能夠在軟件開發的早期階段就能引入安全性的分析，讓他們能夠根據漏洞分析的提示，盡可能早地將安全問題 Fix 在開發階段，這就引入了基于白盒的源代碼安全分析。
如果把檢測軟件漏洞比作去醫院看病，那滲透測試就如同中醫的“聞問望切”一般，通過給軟件把脈，將病例病因一一道來。而基于白盒的源代碼分析，更像是西醫的內觀外治，先做完 X 片、B 超，然后對癥下藥。
其實長久以來，基于黑盒的滲透測試和基于白盒的源代碼分析到底誰更為有效的問題一直爭論不下，以至于還有了灰盒測試（Gray Box）的出現。接下來就讓我們一起通過示例看看白盒黑盒孰優孰劣。#p#
給軟件拍一張 X 光片—基于白盒的源代碼分析
源代碼分析技術由來已久，Colorado 大學的 Lloyd D. Fosdick 和 Leon J. Osterweil 1976 年的 9 月曾在 ACM Computing Surveys 上發表了著名的 Data Flow Analysis in Software Reliability，其中就提到了數據流分析、狀態機系統、邊界檢測、數據類型驗證、控制流分析等技術。隨著計算機語言的不斷演進，源代碼分析的技術也在日趨完善，在不同的細分領域，出現了很多不錯的源代碼分析產品，如 Klocwork Insight、Rational Software Analyzer 和 Coverity、Parasoft 等公司的產品。而在靜態源代碼安全分析方面，Fortify 公司和 Ounce Labs 公司的靜態代碼分析器都是非常不錯的產品。2009 年 7 月底，IBM 發布收購要約，將 Ounce Labs 納入 Rational 產品線。在本示例中，我們選用 Ounce Labs 的安全分析器（Ounce Security Analyst 6.1）和 Rational Software Analyzer 來分別對示例代碼進行靜態源代碼安全分析和代碼質量分析。
為了保持示例一致性，我們選用 AltoroMutual 應用的源代碼進行靜態分析。首先，我們用Ounce Security Analyst 6.1 進行源代碼安全分析。
Ounce 的安全分析器（Ounce Security Analyst）支持多種部署方式，可以獨立運行，也可以通過 Plug-in 的方式運行在軟件開發人員的集成開發環境中。在軟件開發生命周期（SDLC）中，對于開發人員，更多的是希望在日常的開發過程中能夠進行源代碼的安全分析和檢查，因此在本文的示例中我們選擇將 Ounce 安全分析器（Ounce Security Analyst）通過插件的方式 Plug-in 到基于 Eclipse 的 IBM Rational AppScan Developer Edition 7.8.1 中來使用。
圖 12. Ounce Labs 在 RADE 中的插件
下面我們在裝有 Ounce Security Analyst 的 Rational AppScan Developer Edition 中，將 AltoroMutual 的源文件導入，我們發現 Plug-in 后的 Rational AppScan Developer Edition 上會多了一個名稱為 Ounce 的菜單。
圖 13. 在 RADE 中將 AltoroJ 項目編譯通過
對于一般的靜態安全分析而已，保持代碼在做靜態安全分析前的可編譯性是一項非常重要的工作。因此建議軟件開發人員在進行靜態安全分析前首先保證自己的代碼是編譯通過的。我們首先將 AltoroMutual 的源代碼進行編譯，然后在 Ounce 菜單中選擇對 AltoroMutual 源代碼進行掃描。
下圖中所示的是進行掃描之后的情況。在 Rational AppScan Developer Edition 的控制臺中，我們看到 Ounce Security Analyst 總共掃描了 AltoroMutual 項目的 97 個源文件，在 10625 行代碼里發現了 742 個安全問題，總共用時 62 秒。
圖 14. 利用 Ounce Security Analyst 進行源代碼掃描#p#
將視圖切換到 Ounce Labs Perspective 后，打開 Assessment Summary，我們可以查看發現的漏洞類別與數量。
圖 15. 掃描發現的 Top10 的漏洞類別與數量
掃描完成后，Ounce Security Analyst 會在發現安全漏洞的源文件上加上小紅叉作為標示，幫助開發人員快速對漏洞進行定位。左下方的漏洞描述與修復建議可以幫助開發者進行修復。SmartTrace 直觀的將函數調用關系通過圖示的方式展示出來，點擊 SmartAudit 中的 item 開發者可以直接跳轉到存在漏洞的代碼行上進行工作。
圖 16. Ounce Security Analyst 安全分析視圖
針對前例中 AppScan 通過滲透測試掃描出來的 XSS 問題，我們來看看 Ounce 安全分析器是如何發現并定位該漏洞的。打開 XSS 的漏洞列表，我們從 FeedbackServelet.java 文件中發現這個 XSS 問題是由于在“request.setAttribute("message_feedback", name);”這行代碼中沒有對 name 的輸入值進行檢測，允許了在 name 中包含跨站腳本攻擊中經常使用的特殊字符，從而導致跨站腳本攻擊問題。
圖 17. 針對 XSS 問題的源代碼分析#p#
其實在某些時候，軟件的安全問題也同樣包含了軟件的質量問題，例如在架構中不夠良好的設計會導致系統的拒絕服務攻擊，SQL 鏈接在異常時候的不當處理導致連接池資源沒有釋放等等。Rational Software Analyzer 是一個基于 Eclipse 技術的軟件分析工具，我們可以利用 Rational Software Analyzer 來對軟件代碼的質量和各種指標進行度量。
在示例中，我們選用 Rational Software Analyzer 7.0.1 來對相同的 AltoroMutual 項目進行代碼質量掃描。首先，我們還是將 AltoroMutual 項目創建到 Rational Software Analyzer 的 workspace 中，并對該項目進行源代碼分析的配置（如下圖）。
圖 18. 用 Rational Software Analyzer 進行代碼質量分析的配置
通過掃描，我們可以從代碼體系結構、軟件度量、代碼復審、數據流分析 4 個方面得到關于代碼質量的問題數據。
圖 19. Rational Software Analyzer 中對于軟件度量的分析結果
在下圖 Rational Software Analyzer 的數據流分析結果中，我們可以看到由于 SQL 鏈接在異常時不能釋放而導致的資源泄漏問題。
圖 20. Rational Software Analyzer 中基于數據流分析發現的資源泄漏問題
相似的，在 Ounce 中也可以發現這樣既是安全也同樣存在質量因素的漏洞。
圖 21. Ounce 中針對相同資源泄漏問題的分析
總結
在本文中，我們通過對 Web 應用 AltoroMutual 進行滲透測試和源代碼安全掃描，來對比黑盒動態測試和白盒靜態分析在發現軟件安全漏洞方面的功效，并利用 Rational Software Analyzer 在代碼質量方面進行了粗淺的分析和與安全掃描的對比。
通過上述示例，我們發現源代碼靜態分析在代碼掃描的覆蓋率、發現安全問題的數量上有著不錯的表現，并且能夠找到大部分通過滲透測試發現的安全問題。但這并不能說靜態分析在軟件安全檢測方面要優于滲透測試。靜態分析的高覆蓋率和掃描器的不同設置也導致了相對較高的誤報率，而且靜態代碼的非運行性會導致了很多跟運行環境相關的安全漏洞通過靜態安全分析無法發現。相對于此，滲透測試剛好可以彌補靜態分析的這些劣勢，雖然滲透測試發現安全問題的數量不如靜態分析那么多，但是滲透測試的準確率和針對運行時態的實時檢測都是其優勢所在。所以滲透測試在軟件開發生命周期中是不可或缺的一個環節。同樣，我們看到軟件的質量問題在源代碼分析中也不能忽視。因此，一個理想的選擇是：在整個軟件開發生命周期中的不同階段，針對不同的人員，引入相應的安全策略，制定合理的開發流程，從而達到提高軟件安全性的目的。
