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