Web 應用安全利器：IBM Rational AppScan

基于 Web 的應用正受到越來越多的青睐，從企業應用到形形×××的公共站點，可以說 Web 無處不在。黑客也逐漸将注意力從以往對網絡伺服器的攻擊逐漸轉移到了對 Web 應用的攻擊上，“跨站腳本”、“SQL 注入”新的網絡安全問題不斷湧現，如何保障 Web 應用的安全已成為當今業界關注的問題。Rational AppScan 是 IBM 公司推出的全面 Web 安全解決方案，提供了掃描、報告和修複建議等功能，可以幫助開發者在項目起始階段即全面準确地發現并解決安全問題。

　　Web 應用安全現狀

　　很多開發人員對 Web 安全有着片面的認識，認為隻要建立了防火牆，設定了入侵檢測系統，部署了網絡安全工具，Web 應用的安全就可以高枕無憂了。的确，通過以上措施确實可以從網絡以及系統層面增強 Web 應用的安全性，但它片面強調了硬體的作用卻忽視了 Web 應用本身的安全問題。對于存在缺陷的應用來說，再多的防護措施也将形同虛設。Web 安全是各種因素的綜合體，涵蓋了網絡、作業系統、應用伺服器以及 Web 應用本身的安全問題，任何方面的缺失都會将應用暴露于黑客的攻擊之下。著名統計機構Gartner的報告稱發生在網絡上的攻擊當中，大約 75% 是針對 Web 應用的；而另外一項統計資料更是讓人不安，約 67% 的 Web 程式是存在安全缺陷的。

　　開放 Web 應用安全組織 OWASP（Open Web Application Security Project）釋出了2010年 Web 應用十大安全缺陷，與上一榜單相比：注入缺陷（Injection flaws）位列榜首，跨站腳本攻擊（Cross Site Scripting）退至第二；錯誤安全配置（Security Misconfiguration）與非法連結跳轉（Unvalidated Redirects and Forwards）首次上榜，分列第六，第八位；惡意檔案執行（Malicious File Execution）與資訊洩露/異常處理（Imformation Leakage and Improper Error Handling）跌出前十。

　　為使讀者對 Web 安全問題有所了解，在此隻對 SQL Injection（注入缺陷的一種）進行簡單介紹，如果讀者感興趣可以學習本文的參考資料或者通路 OWASP 官方網站以獲得更多資訊。對于使用者登入來說，大多數程式都會使用如下的 SQL 語句對使用者名和密碼進行驗證：

<code>SELEECT　*　FROM　user_table　WHERE　user_name　=　''　AND　password　=　''</code>

　　通常情況下上述 SQL 語句可以對使用者賬号進行有效的檢測，但是如果使用者輸入的賬号資訊為：使用者名 'or 1 = 1--；密碼 test，那麼登陸程式拼接出的 SQL 語句将變為：

<code>SELEECT　*　FROM　user_table　WHERE　user_name　=　''　or　1　=　1--'　AND　password　=　'test'</code>

　　資料庫在執行 SQL 語句時會将 "--" 後面的内容作為注釋忽略掉，其結果是上述 SQL 語句永遠傳回真，一個非法的使用者獲得了網站的登入權限。為了防止此類問題我們通常會對使用者輸入資料的合法性進行校驗，同時使用預編譯語句将使用者輸入作為參數傳遞到SQL語句中。

　　Rational AppScan 初識

　　Web 安全檢測主要分為兩大類，分别是白盒檢測和黑盒檢測。白盒工具通過分析應用程式源代碼以發現問題，而黑盒工具則通過分析應用程式運作的結果來報告問題。 Rational AppScan（以下簡稱 AppScan）屬于後者，它是業界領先的 Web 應用安全檢測工具，提供了掃描、報告和修複建議等功能。為使本文達到更好的效果，在繼續文本前讀者最好先從 developerWorks 網站下載下傳并安裝 Rational AppScan 試用版，安裝完成後導入證書激活産品。證書的有效期為 30 天，授予了使用産品全部功能的權限，但是使用者隻可以掃描本機（localhost）或者 Rational AppScan 測試站點（http://demo.testfire.net）上部署的應用程式。需要說明的是登入 http://demo.testfire.net 站點的使用者名和密碼為：jsmith / Demo1234，該登入賬号在後面的章節中會用到。

圖 1. 開始安裝

　　檢視原圖（大圖）

　　安裝完成後，啟動 AppScan 應用程式，其界面主要包括如下部分:

　　菜單欄：涵蓋了 AppScan 中的所有可用功能

　　工具條：常用功能的快捷菜單，如開始掃描、掃描配置、掃描專家等

　　左上部網站導航視圖：在掃描過程中 AppScan 會按照一定的層次組織顯示站點結構圖（預設是按照 URL 層次進行組織，使用者可以在掃描配置中更改這一設定）

　　右上部安全問題顯示視圖：AppScan 将在此視圖中列出檢測到的所有安全缺陷

　　左下部安全問題彙總視圖：AppScan 将在此視圖中列出檢測到的安全缺陷統計資訊

　　右下部安全問題詳細資訊視圖：此視圖的内容與安全問題顯示視圖相關，用來顯示某特定安全問題的詳細資訊，包括問題介紹、修複建議、測試資料等

圖 2. AppScan 主界面

　　開始一次掃描

　　掃描就是 AppScan 對站點進行測試以發現安全漏洞的過程，首先它會對站點進行一次 Explore（其行為與網絡爬蟲類似）過程，從某一起始 URL 開始通過頁面間的連結不斷探索，直到站點的所有頁面都被通路或者達到某設定的最大值。在 Explore 的同時，AppScan 會分析每一個發現的頁面并确定是否需要對其進行測試。如果需要，AppScan 将根據設定的測試政策（後面章節有對測試政策的詳細介紹）為其建立測試用例，測試用例的數量由測試政策包含的規則集決定。Explore 完成後，AppScan 将根據測試用例對站點進行測試并分析站點的響應資訊以發現安全缺陷。AppScan 引入了 掃描工程 的概念對安全掃描進行管理，通過 掃描工程 使用者可以配置各種參數、儲存掃描結果等，下面将為讀者詳細介紹其建立過程。

首先點選File菜單，在子菜單中選擇New，将彈出 New Scan 對話框（見圖 3）。對話框中列出了 AppScan 預先提供的常用掃描模闆，使用模闆将可以大大簡化掃描建立過程提高工作效率；當然，使用者也可以根據實際情況建立自定義模闆。為了友善我們選擇Predefined Templates下的 demo.testfire.net，此模闆是專門為測試站點 demo.testfire.net 而設立的。

圖 3. New Scan 對話框

　　在下一個視窗中需要選擇安全掃描的類型：如果是 Web 站點掃描選擇Web Application Scan，如果是 Web 服務掃描選擇Web Service Scan。因為我們要對 demo.testfire.net 站點進行測試，是以選擇Web Applicaiton Scan并點選下一步:

圖 4. 選擇掃描類型

　　接下來是各種掃描參數的配置，包括 URL and Servers、Login Management、Test Policy 三部分，因為 AppScan 模闆已經為這些參數設定了合适的值，是以不需要做任何修改直接點選下一步即可。在最後一步，AppScan 列出了掃描建立結束後的四種行為方式，每種方式的意義如下：

　　Start with a full automatic scan: 預設選項，AppScan 将自動開始一次完全的安全掃描，包括探索和測試兩部分

　　Start with automatic Explore only: AppScan 将對待測試網站進行探索，但是不進行任何安全測試

　　Start with Manual Explore: 此選項适用于業務邏輯複雜的站點，使用者需要采用手工方式引導 AppScan 對站點進行探索

　　I will start the scan later: AppScan 不進行任何動作，使用者可以在适當時刻手工啟動安全測試

　　此外，還有一個額外選項 Start Scan Expert when Scan Configuration Wizard is complete，詢問在配置完成後是否運作 Scan Expert。如果選中，AppScan 将啟動 Scan Expert 對 Web 站點進行探查并搜集相關資訊進行縫隙，根據結果對掃描配置參數進行評估并提出修改建議。通過運作 Scan Expert 可以優化掃描配置、提高缺陷發現率。此處選擇Start with a full automatic scan點選Finish，AppScan 将啟動一次全面的安全掃描，圖 6 列出了本次掃描的結果：

圖 5. 結束掃描建立選項

圖 6. 掃描結果

　　掃描配置詳解

　　上一小節中，我們使用 AppScan 對 demo.testfire.net 站點進行安全測試發現了很多問題，深深體會到了 AppScan 在安全缺陷檢測方面的強大功能。但是在建立上述掃描時我們使用了模闆，掃描參數都是預先設定的，讀者可能對其意義及配置方法還不甚了解，本節将對它們進行詳細介紹。掃描配置參數可以在建立掃描過程中設定，也可以在建立後進行設定，其配過程和效果是完全相同的，此處隻研究如何修改已建立的掃描項目。打開已建立的掃描檔案，點選工具欄的Scan Configuration或者選擇Tools菜單的子項Scan Configuration打開掃描配置管理面闆。

　　登入管理

　　為了限制使用者對站點部分功能的使用，絕大多數 Web 應用都實作了使用者認證與授權即通常所說的登陸控制功能，非授權使用者僅可以通路部分功能。AppScan 的安全測試是通過模拟使用者對站點的通路來實作的，如果待測試站點有需要授權才能通路的内容，就必須讓 AppScan 在測試過程中通過網站的認證。AppScan 提供了登入管理來實作此功能，在掃描配置面闆中點選Login Management，面闆右部将顯示登陸管理的詳細資訊（如圖 7 所示），有四種方式管理登陸，分别是：

　　Recorded：推薦方式，需要使用者手工錄制登入過程；當 AppScan 發現需要登陸站點時将自動重放錄制過程實作登入。點選面闆上的紅色的 Record... 按鈕，将彈出 AppScan 的内置浏覽器，在此浏覽器中轉到登入頁面，輸入賬戶資訊完成登入即可，AppScan 将自動記錄登入過程。

　　Prompt: 當 AppScan 發現需要登陸站點時會提醒使用者登入，如果網站的登陸功能使用了圖檔形式的驗證碼（每次登入驗證碼圖檔都會發生變化）或者密碼變化很頻繁等需要選自此種登入方式。

　　Automatic: 當 AppScan 發現需要登陸站點時會使用儲存的賬戶資訊填充登陸頁以實作登入，此方式需要事先錄入并儲存賬号資訊。

　　None： 網站沒有使用者認證與授權功能時選擇此項。

　　因為 AppScan 會掃描所有探測到的需要測試的頁面，這就包括了登出頁面，如果 AppScan 在測試中通路了登出頁面就會造成使用者會話終止，進而影響後續的測試。為防止此類情況的發生就必須配置面闆下方的 Logout Page Detection 參數，為登出頁面設定正确的比對模式，AppScan 在根據此參數的設定跳過對登出頁面的測試。該參數提供了常用的比對模式，使用者需要根據應用的實際情況進行修改。

圖 7. 登入管理配置面闆

　　如果将站點登陸設定為 Recorded 方式，在錄制完成後切換到Details面闆檢視登入的詳細資訊，包括按照通路先後順序的 URL 清單、接收到的系統參數和 Cookie 等。需要注意的一項是 In-Session Detection，此參數用來幫助 AppScan 識别目前登陸狀态。舉例來說，在使用者登入站點後通常會在頁面的某處顯示如 歡迎您，尊敬的XXX先生 的歡迎資訊，而使用者未登入或者已經登出時則無此顯示。是以我們可以将 歡迎您，尊敬的 設定為登入狀态的識别模式，如果頁面中存在比對模式 AppScan 即認為目前正在登入會話中。預設情況下 AppScan 會自動比較登入前後的頁面，找出其差異點作為登入識别模式，開發人員也可以手工指定登入模式。點選In-Session Pattern Selection...按鈕，AppScan 将彈出登入後的頁面， 使用者可以在頁面上選擇文本資訊，也可以檢視頁面的 HTML 源代碼并選擇作為模式的要素（如圖 9 所示）。

圖 8. 登入管理詳細資訊面闆

圖 9. 登入狀态識别模式選擇

　　探索選項

　　探索選項用來配置 AppScan 掃描過程中的行為，在主面闆左端點選Explore Options激活探索選項配置面闆（如圖10所示）。該面闆中需要調整的參數包括 Reduant Path Limit ：限制對相同路徑的通路次數，AppScan 在掃描該路徑時若通路次數達到了參數門檻值即停止掃描，對于采用參數化功能跳轉的應用，必須為此參數設定合理數值。 所謂參數化功能跳轉即在 URI 相同情況下，通過參數控制功能使用（頁面跳轉）的技術。舉例來說，某 Web 應用将所有的賬号管理功能（包括添加賬号、删除賬号、檢視賬号詳細資訊等）放置在路徑 /manage/account/ 下，但不為每種具體功能建立子路徑而是将功能與特定參數的值建立映射關系，如将添加賬戶功能映射到 action=ADD_ACCOUNT，将删除賬戶功能映射到 action=DEL_ACCOUNT。 要通路添加賬戶頁面，需要在發送請求到 /manage/account/ 的同時發送參數 action=ADD_ACCOUNT。此參數設定的正确與否将在很大程度上影響測試效果。

　　Depth Limit： 參數用來控制掃描的最大深度，AppScan 會從網站的入口頁面開始根據頁面上發現的 URL 爬行，當到達頁面與起始頁面的深度超出參數門檻值時，它将停止對目前頁面的掃描傳回上一級。Link Limit：用來控制 URL 的總通路數量，預設設定是沒有任何限制，如果設定了數值，那麼當被通路的 URL 數量到達門檻值時 AppScan 将結束掃描。 Appscan 有兩種可選擇的探索方式，分别是廣度優先（預設設定）和深度優先，可根據應用實際情況選擇合理的設定（如對所提供功能強調前後關聯關系的的應用比較适合深度優先）。

圖 10. 探索選項

　　Parameter與Cookie

　　在主面闆左端點選Parameters and Cookies激活配置面闆，此視圖中列出了 AppScan 測試過程中維護的所有參數，掃描時 AppScan 在每個發送的測試請求中包含清單中的參數及其對應值。AppScan 會自動向此清單中添加 Explore 期間發現的參數和 Cookie，也可以通過點選面闆上的+按鈕手動添加參數（如圖11所示）。添加的參數可分為有三種類型：Parameter、Cookie 和 Custome，因為 Custome 類型的參數配置比較複雜且應用較少，故本文隻簡單介紹 Parameter 的建立。

　　假如我們需要在發送的每次測試請求中包括 categoryID 這個參數，那麼為添加此參數的設定為：

　　Parameter name: categoryID；勾中Track this parameter during scan

　　使 AppScan 在掃描過程中對參數值的變化進行追蹤，有三種方式可供選擇：Login Value 指 AppScan 将儲存登入過程中接收到的值，此值在後續測試過程中不會發生改變；Dynamic 指 AppScan 在每次的測試響應中尋找此參數的值，如果發現則使用新找到的值更新目前值；Fixed Value 表明此參數的值不會發生任何變化，AppScan 将始終使用使用者輸入的值。

　　AppScan 為參數提供了Redundancy Tuning選項，此參數的正确設定可以減少測試備援、提高測試效率。假設我們需要測試如下四個 URL 并且 timezone 參數隻是為了在頁面上顯示時間之用，對應用的功能沒有任何影響:

#

Detail

1

viewProducts.do?timezone=

　　1

　　&amp;filter=IBM

2

　　2

　　&amp;filer=IBM

3

viewProduction.do?

　　timezone=1

4

viewProduction.do?filer=IBM

　　可見，對于 URL 1 和 URL 2，其不同之處僅僅在于 timezone 的值，對于 URL 3 和 URL 4，其不同之處僅僅在于是否包含 timezone 參數，Redundancy Tuning 參數設定如下：

　　When comparing Explore requests, ignore this parameter's value：對于兩個或者兩個以上的 URL，如果其不同之處僅僅在于某參數的值（如 URL 1 和 URL 2）而此參數值對應用的功能沒有任何影響，那麼選中此項使 AppScan 在探索過程中隻探索其中的一個 URL 而将其它的丢棄

　　When comparing Explore requests, ignore this parameter altogether：對于兩個或者兩個以上的 URL，如果其不同之處僅僅在于是否包含某參數（如 URL 3 和 URL 4）而此參數對應用的功能沒有任何影響，那麼選中此項使 Appscan 在探索過程中隻探索其中的一個 URL 而将其它的丢棄

　　Don't retest adjacent parameters when this parameter's value changes：對于兩個或者兩個以上的URL，如果其不同之處僅僅在于某參數的值（如 URL 1 和 URL 2）而此參數值對應用的功能沒有任何影響，那麼選中此項使 AppScan 在測試過程中隻測試其中的一個 URL 而将其它的丢棄

　　Don't retest adjacent parameters when this parameter is added/removed：對于兩個或者兩個以上的URL，如果其不同之處僅僅在于是否包含某參數（如 URL 3 和 URL 4）而此參數對應用的功能沒有任何影響，那麼選中此項使 AppScan 在測試過程中隻測試其中的一個 URL 而将其它的丢棄

圖 11. 添加參數

　　多步驟操作

　　對于複雜應用，要完成某項任務往往需要很多步驟，步驟之間有很強的順序依賴關系。以某系統的轉賬功能為例，使用者受限需要輸入對方的賬号和姓名點選下一步；如果系統驗證賬号和姓名正确則要求輸入轉賬金額，否則傳回上一步，在輸入金額後點選下一步進入确認界面；系統将列出前兩步操作中的所有資訊供使用者确認，如确認無誤點選确認完成轉賬。可見要完成轉賬操作需要三步，這三步之間是前後依賴的，隻有完成了上一步才可以繼續下一步，如果直接通路轉賬金額頁面或者最終确認頁面應用會顯示錯誤資訊。我們知道 AppScan 會測試所有發現的URL，對這些URL的測試時随機的，它并不能保證對存在依賴關系的URL的測試是按照順序的，這就可能造成 AppScan 首先通路後續步驟頁面，進而影響安全測試結果。 為了解決問題，AppScan 引入了多步驟序列的概念。點選主配置面闆左邊的Multi-Step Opetions打開多步驟操作視圖，此視圖中列出了所有已經建立的操作序列，可以将存在的序列導出成單獨檔案，也可以導入曾經被導出的序列檔案；點選紅色的按鈕會彈出 AppScan 内置的浏覽器，在此浏覽器中使用者隻需像平時使用應用一樣完成某項功能即可，關閉浏覽器即完成序列腳本的錄制。在測試過程中，AppScan 會将目前待測試的URL與錄制的序列腳本中的URL進行比較，如果發現待測URL是某個序列中的一步，AppScan 會重放所有前置序列腳本以使對目前頁面的通路合法

圖 12. 多步驟操作

　　政策定制

　　AppScan 會通過預先設定的安全規則建立測試用例，一條安全規則描述了某安全缺陷的資訊，包括缺陷描述、修複建議、确認模式等。AppScan 內建了大規模的測試規則，預設情況下針對一個頁面可能會生成成百上千個測試用例，但是這些用例中往往有很大一部分對于應用本身來說是沒有任何意義的。為了減少測試備援、增加測試的有效性就需要甄選符合應用實際情況的的測試規則，比如針對J2EE站點的安全測試就不需要與.Net相關的測試規則，又如對安全性要求不高的站點（内部應用）隻需要對高危險的安全缺陷進行探測而沒必要測試所有。測試政策是對測試規則的管理，使用者可以根據 Web 應用的實際項目情況選擇合理的測試規則集， 對標明的規則集可以通過Export的方式将其導出為政策檔案，其它使用者可以導入政策檔案以保持組織内部政策規則的一緻性。點選主配置面闆左端的Test Policy打開測試政策視圖（如圖 13 所示），視圖中列出了 AppScan 的所有測試規則，可以通過上面的分組下拉框對其按照不同方式進行分組以友善檢視。

圖 13. 測試政策

　　上面對 AppScan 常用配置做了簡要描述，掃描配置還包括 URL and Servers，Environment Definition，Error Pages，Content-Based Results等項目，限于篇幅不一一介紹，讀者可以參考developerWorks上的相關資源以獲得更多資訊。

　　結束語

　　IBM Rational AppScan 是一款強大的安全缺陷檢測工，提供了掃描、報告和修複建議等功能，對提高 Web 應用安全有巨大作用。