?使用 AppScan 進行掃描

針對大型網站的掃描，我們按照戴明環 PDCA 的方法論來進行規劃和討論，建議 AppScan 使用步驟：計劃（Plan）、執行（Do）、檢查（check）、分析（Analysis and Action）。

在計劃階段：明確目的，進行策略性的選擇和任務分解。

明確目的：選擇合適的掃描策略

了解對象：首先進行探索，了解網站結構和規模

確定策略：進行對應的配置

按照目錄進行掃描任務的分解

按照掃描策略進行掃描任務的分解

執行階段：一邊掃描一遍觀察

進行掃描

先爬后掃（繼續僅測試）

檢查階段（Check）

檢查和調整配置

結果分析（Analysis）

對比結果

匯總結果（整合和過濾）

下面我們針對每個階段，進行具體的闡述。

---

準備階段

AppScan 安裝環境要求和檢查

為了保證更好的掃描效果，安裝 AppScan 的硬件建議配置如下：

表 1. Rational AppScan 安裝配置要求
?

硬件最低需求

處理器	Pentium P4，2.4 GHz
內存	2 GB RAM
磁盤空間	30 GB
網絡	1 NIC 100 Mbps（具有已配置的 TCP/IP 的網絡通信）

?

其中，處理器和內存建議越大越好，而磁盤空間，建議系統盤（一般是 C 盤）磁盤空間至少保留 10G，如果系統盤磁盤空間比較少，可以考慮把用戶文件等保存在其他盤；如默認的用戶文件是：C:\Documents and Settings\Administrator\My Documents\AppScan；可以修改為其他路徑。該路徑可以在菜單欄中依次選擇工具 - 選項 - 一般 - 文件位置部分修改。

圖 1. 設置文件保存路徑
?

?

磁盤要求：修改臨時文件路徑

有時候大家會發現，已經把上面的地址都修改到了其他盤，但是在掃描過程中，還是會發現 C 盤的空間快速被消耗，分析原因，是因為很多臨時文件都保存在 C 盤，AppScan 中有一個隱藏的參數 APPSCAN_TEMP 來設置臨時文件位置。在掃描過程中，如果系統盤空間比較下，可以通過修改系統變量來修改到其他硬盤空間。

臨時文件位置說明：描述正常操作期間 AppScan 將其臨時文件保存到的位置。缺省情況下，AppScan 將其臨時文件存儲在以下位置：

C:\Documents and Settings\All Users\Application Data\IBM\Rational AppScan\temp

如果需要修改此缺省位置，請按照要求編輯環境變量 APPSCAN_TEMP 的路徑。（訪問環境變量的方法是，右鍵單擊我的電腦，然后依次選擇屬性 > 高級 > 環境變量。）

注意：在新位置的路徑中絕不能有任何 Unicode 字符。

修改 AppScan 中的臨時文件：

桌面上鼠標右鍵選擇“我的電腦”，選擇“屬性”

選擇“高級”，“環境變量”

增加一個新的“用戶環境變量”，名字是“APPSCAN_TEMP”，設定路徑，指向您希望保存臨時文件的目錄。

分組類型，切換到“侵入式”類型，下面有“非侵入式”和“侵入式”兩種分類。取消“基礎結構”級別的測試。

侵入式的測試用例，往往因為有比較強的副作用，可能對系統造成傷害，所以一般掃描生產系統的時候，很少選擇。我們可以查看一個 SQL 注入類型的侵入式安全問題，在“輸入以查找”輸入框中輸入“SQL”，然后回車查詢。可以看到測試變體的描述“將參數值設置為 Declare/Case SQL 注入***（嘗試關閉 DB 服務器）”，則掃描過程中，會使用該測試用例去執行嘗試關閉數據庫的命令，如果該測試用例執行通過，則就關閉了數據庫，則整個系統就癱瘓！所以，要很慎重的選擇“侵入式的測試用例”。

圖 3. 查詢測試策



略

其他的在“類型”中，“應用程序”類型表示該問題的存在是因為應用程序不嚴謹，代碼存在安全問題而造成的，修改方法就是修改原代碼；而“基礎結構”類型，則表示該問題是配置問題，建議修改系統配置或者安裝最新的補丁（經常是中間件或數據庫補丁）。

了解被測試網站

在對網站進行測試之前，我們經常需要先大概了解下這個網站，比如該網站使用了哪些技術，提供什么類型的業務（功能），網站規模等。這些都和我們的掃描設置相關。如下圖，就是我們經常使用的一個調查表，了解被測試系統的基本特點。

表 2. 記錄被測網站特點
?

應用系統名稱	訪問地址	應用系統架構（JEE/.Net/PHP…）	URL 數量	登陸方式	備注

?

其中，用戶經常迷惑的是 URL 數量，有些時候，用戶很難評估出一個系統的大概頁面數量，而按照 AppScan 的工作原理，掃描是針對頁面的每個參數的，如果頁面越多，參數越多，則掃描要運行的時間也就越長，掃描保存成的接過文件也是越大，更需要進行分解。如果一個掃描任務，本身的已訪問 URL 數超過 5000，評估的要運行的安全測試用例數超過 50，000，則建議進行掃描配置的分析，并根據分析結果，決定是否需要進一步的任務分解和分工。

那么，如果可以了解到網站具體有哪些頁面呢？這里我們就可以利用 AppScan 的探索（頁面爬行）能力。

在掃描配置里面設置了主 URL 以后，工作菜單中中依次選擇掃描 - 僅探索。對網站進行探索。一般會讓探索工具運行 10 到 30 分鐘，看該網站具體存在哪些頁面，哪些參數等。這個就可以切換到“應用程序數據”視圖來查看。

我們一般關心這幾個視圖：

• 已訪問的 URL()：AppScan 已經探索到并且進行了分析的頁面
• 已過濾掉的 URL()：AppScan 已經發現，同時根據掃描配置，認為不需要進行安全掃描的頁面。
• 中斷鏈接 URL()：AppScan 發現了，但是無法訪問到或者訪問出錯的頁面，如 404 頁面不存在，或者 500 服務器錯誤等。

偽靜態頁面

可以選擇左邊“我的應用程序數據”中的 URL 樹下的每一個節點，察看該節點已訪問的 URL，已過濾掉的 URL 等。

如在已訪問的 URL() 中，我們發現大量類似如下結構的 HTML 頁面：?

http://www.Test.com//focus/satisfy/file5.html http://www.Test.com//focus/satisfy/file6.html http://www.Test.com/m-zone/news/dgdd/quanbu/bylb/file5.html

其共同特征，都是以 html 為后綴名，最后的文件名格式都是 file+ 數字格式；這種類型的頁面經常存在新聞，論壇等。如果訪問這些頁面，發現頁面結構相同，差異的都是里面的文本內容，如提供不同的新聞內容等，這些頁面就是所謂的“偽靜態頁面”，其實是網站發布系統動態產生的，由于結果相似，在安全掃描中，沒有必要針對這些頁面每次都進行掃描。如針對每個目錄下面存在的 file+ 數字格式的頁面，我們就可以設置正則表達式來過濾，比如，在掃描配置 - 排除路徑和文件中

排除所有該類型的頁面；.*file\d+.html

增加“例外”，對該類型的頁面只掃描 file1.html 和 file20.html

經常存在的其他類似頁面，還有 news1.html、content200.html 等類型，采用方法類似。

業務類型的“冗余路徑”

和“偽靜態頁面”對應的有另外一種動態頁面，這些頁面按照默認的掃描規則，會被自動過濾，但是根據真實的業務場景，這些頁面確實不能被過濾的，如訪問 demo.testfire.net 時候在“已過濾 URL”內會顯示有如下的 URL 地址，過濾原因都是“路徑限制”：?

http://www.Test.com/default.aspx?content=inside_community.htm http://www.Test.com/default.aspx?content=inside_press.htmhttp://www.Test.com/default.aspx?content=inside_executives.htm

選擇 URL 地址，鼠標右鍵“在瀏覽器中顯示”，會發現這里顯示的頁面內容完全不一樣，和上面的“偽靜態頁面”正好相反，這些參數相同，參數值不同的動態頁面，是真正的業務頁面，是不能過濾掉；如果過濾，則會很多后續的業務頁面無法發現。那這些頁面為什么會被過濾了呢？按照什么樣的規則被過濾掉的？

在 AppScan 中，默認情況下是有一個“冗余路徑限制”（在“掃描配置 - 探索選型 - 冗余路徑限制”），默認對于冗余的頁面，最多掃描 5 次，關鍵的問題是，什么頁面被被 Appscan 認為是冗余頁面呢 ?

圖 4. 冗余路徑設置
?

?

簡單說：?

http://www.Test.com/default.aspx?content=inside_community.htm http://www.Test.com/default.aspx?content=inside_press.htm

Appscan 是根據“?”號來分隔的，如果 ? 號前面的內容都相同，則就被認為是冗余頁面，所以上面的頁面就是冗余頁面了。

遇到這樣情況的頁面，最多被訪問 5 次。而這 5 次，具體是使用了哪些參數，是隨機的，具體訪問到的頁面也會在“應用程序數據”視圖的“已訪問的 URL”中查看：?

http://www.Test.com/default.aspx?content=business.htm http://www.Test.com/default.aspx?content=business_lending.htm http://www.Test.com/default.aspx?content=inside_contact.htm

可是，在本例中 content 參數值不同的時候，其實根據業務邏輯，不應該算作“冗余頁面的”，而按照配置，也會被自動過濾了，遇到這種情況，就需要考慮增加“冗余路徑限制”，如設置為 20 或者 50。以可以更多次訪問這些頁面。

這些情況經常存在于跳轉參數等情況。

順便備注下，“冗余路徑限制”，功能設置的目的是為了處理類似論壇 BBS 等頁面，只有文本內容不同，頁面架構完全相同的頁面：如?

http://www.Test.com/showthread.php?id=1 http://www.Test.com/showthread.php?id=2 http://www.Test.com/showthread.php?id=3

而我們在測試 demo.testfire.net 時候會發現每次的安全測試結果都可能有差別，一個很大的原因就是每次訪問的頁面是不同的，就是這個設置的影響。

分析重復的“腳本參數”

在上面的步驟中，分析了“偽靜態頁面”，對其應該通過“排除路徑或者文件名”的方法設置排除規則；而對于“業務類型的冗余路徑”，則需要通過增加“冗余路徑顯示”個數等的方法進行擴充，以掃描到這些 URL。我們在這個步驟來分析另外一種參數，腳本參數。

在“我的應用程序數據”樹狀結構下，鼠標選擇目錄以后，在右邊視圖中選擇“腳本參數”，然后查看是否存在不同頁面（URL) 存在相同或者類似參數的情況：如下圖，在不同 URL 中，都存在 kbKey 參數，默認的參數值是“請輸入您要搜索的問題”：

圖 5. 腳本參數
?

?

訪問這些 URL，發現每個頁面內都包含了一個搜索功能，這就是為什么在不同頁面都發現了該參數。而從業務角度，這些搜索頁面在一個 URL 中進行測試以后，沒有必要在另外一個頁面也進行測試。而且該參數值的變化，可以認為是冗余頁面，沒有必要進行下一步的重新探索和測試。這可以通過上圖中，選擇該參數后，鼠標右鍵，選擇“添加到‘參數和 Cookie’選項卡中的列表”來實現。選擇后彈出下面的頁面：

圖表 6　添加參數定義（根據參數來設置冗余路徑）
?

?

在該頁面中，點擊“其他選項－冗余調整”，取消選擇任何一個選擇框，則表示無論是否含有該參數，無論該參數值是否發生變化，都不認為是新頁面，沒有必要重新測試，而且不應該因為該參數的變化去影響其他參數的測試。

我們知道，AppScan 中的測試，是針對頁面的每個參數進行的，而且一個參數值的變化會要求重新測試其他的參數，所以該設置，可以大大減少測試用例數。

關于更多的設置說明，可以參照下面的解釋：

表 3. 設置說明
?

?

?

查看每個目錄頁面個數

如果一個掃描任務，本身的已訪問 URL 數超過 5000，評估的要運行的安全測試用例數超過 20，000，則建議進行掃描配置的分析，并根據分析結果，決定是否需要進一步的任務分解和分工。

我們在“我的應用程序數據”樹狀結構下，鼠標選擇目錄以后，在右邊視圖中選擇“已訪問的 URL()”，記錄 URL 數目，如果該目錄 URL 數目比較大（超過 500）則可以考慮為該目錄單獨建立一個掃描任務，只掃描該目錄下面的鏈接。

?

執行階段

根據在“計劃階段”確定的掃描策略，和進行的掃描設置，重新進行探索（掃描菜單依次選擇：重新掃描 - 重新探索）；后繼續分析頁面數和測試用例數目，如果控制頁面數 5000 個以內，測試用例數 20，000 個以內，則可以直接進行掃描；如果沒有，建議繼續分析，優化掃描配置。

分階段測試

AppScan 的掃描過程分為“探索”和“測試”兩個階段，默認情況下，使用的是完全掃描模式，即是邊探索邊測試的。如果網站比較大，建議考慮先探索后測試的模式。

如當 URL 達到 5000，需要進行的測試達到 50000 的時候，可以暫停掃描，手工停止探索，選擇“繼續僅測試”。對已經發現和分析的頁面進行測試，測試完畢，再來選擇“繼續僅探索”，即：

繼續僅探索 --- 繼續僅測試—繼續僅探索 - 僅測試的一個循環過程。

在這個過程，一個階段結束以后，建議查看下 .Scan 文件的大小，如果大小超過了 500M，則建議考慮任務分解，可以根據目錄把一個掃描任務分解為多個，或者根據掃描策略來進行分解。

該方法是利用了 AppScan 掃描過程中，探索測試可以分離，而且支持掃描過程中斷后繼續掃描的特性。

按照業務分解掃描任務

在實際工作中，我們掃描的一個大型網站，往往包含多個頻道，而每個頻道可能需要的掃描配置都不同，這些配置甚至互相沖突。如一個網站的提供了 BBS 論壇功能：

?

http://www.Test.com/WWW.TEST.COM/showthread?channel=1&thread=1001 http://www.Test.com/WWW.TEST.COM/showthread?channel=30&thread=2001

?

對于這樣的頁面，訪問后發現頁面結構相同，只是文本內容不同，則應該使用“冗余路徑限制”參數，控制掃描次數，沒有必要多次掃描。

同時，該網站的一個服務頻道存在如下的頁面：

?

http://www.Test.com/default.aspx?content=inside_executives.htm http://www.Test.com/default.aspx?content=privacy.htm

?

即上面提到的業務類型的“冗余路徑”，應該多次掃描，配置上要求增大“冗余路徑限制”參數。

在這種情況下，就很有必要根據業務分別建立掃描任務，每個任務采用不同的掃描配置。

?

檢查階段

在掃描執行過程中，需要檢查，看是否存在下面的情況：

提示網絡連接不上，或者提示部分頁面無法打開。則檢查是否是掃描速度過快，服務器不能承受不了，根據情況修改掃描配置 - 連接 - 通信和代理，增加“超時”數，并考慮減少“并發線程數”，以允許更長時間的等待頁面影響并減少對服務器的訪問連接數。

發現掃描出的安全問題，包含我們不關心的安全隱患，則取消掉這些規則。如發現了一個安全隱患，類型是“SQL 注入文件寫入（需要用戶驗證）”，該問題是需要用戶根據提示來檢查的，并且是針對 SQL 數據庫的，如果我們使用的數據庫不是 SQL 數據庫，或用戶確認后沒有發現線索，則就可以在掃描配置 - 測試 - 測試策略中取消選擇該策略。

執行“計劃階段”的檢查，看是否還存在“偽靜態頁面”，“業務類型的冗余路徑”等，如果存在，則調整掃描配置。

案例分析

工作中遇到一個案例，使用 AppScan 掃描掃描了 3*24 小時，掃描的 scan 文件已經達到 9G；掃描還在持續進行中，總體進度完成了 30%，可以想象掃描速度已經很緩慢，還需要多長時間才可以完成掃描？掃描完成以后如此大的結果文件是否可以成功打開和修改保存 ?

按照我的經驗，如果掃描結果文件大于 1G，那就很有必要立即停止掃描，進行配置分析。我們的分析過程如下：

和用戶討論，確認關心的安全問題，根據這些安全問題制定測試策略；討論后確定選擇“SQL 注入”和“跨站點腳本編制”兩種類型的安全隱患。

確定網站范圍，被掃描應用是典型運營商門戶網站，重點要掃描門戶網站自身和其上面提供的“網上營業廳”服務。

分析被測網站，使用 AppScan 配置了網站主頁面，然后選擇“僅探索”運行 20 分鐘后，發現 30，000 多個頁面。停止探索，開始分析頁面。

分析發現該網站同一個鏈接，存在 http、https 訪問的不同情況，而且兩種訪問方式訪問到的頁面內容相同，則過濾掉 https 的請求，集中測試 http 請求。

分析發現存在大量的“偽靜態頁面”，如：

http://www.Test.com//focus/satisfy/file5.html http://www.Test.com//focus/satisfy/file6.html

在掃描配置 - 排除路徑和文件中：

排除所有該類型的頁面；.*file\d+.html

增加“例外”，對該類型的頁面只掃描 file1.html 和 file20.html

同時，發現了 swf 文件，應該不準備掃描 Flash，所以在“排除文件類型”中，設置根據后綴名排除 swf 文件。

發現

http://www.Test.com/service

目錄下存在大量如下類型的頁面，都是 menu 參數值不同，訪問以后發現出現的是頁面中有不同的超鏈接：

http://www.Test.com/service/Business.do?menu=Query http://www.Test.com/service/Business.do?menu=Open http://www.Test.com/service/Business.do?menu=Service

確認該頁面是業務類型的“冗余路徑”，應該全面掃描，則需要把“冗余路徑設置”調整為比較大的參數，同時該頻道是網上營業廳頻道，也要求用戶先登錄。所以針對該目錄建立一個單獨的掃描任務，只掃描該目錄和其下子目錄。

分析發現 index.jsp 在多個目錄下出現，而且每次出現都有兩種格式，即沒有參數和有固定的三個參數，每次的參數值都相同。如：

http://www.Test.com//rdwd/jfmz/jifen/index.html http://www.Test.com//rdwd/txl/rdwdznyd/index.html&kbKey= 請輸入您要搜索的問題 http://www.Test.com//rdwd/jfmz/jifen/index.html?queryType=common&applyArea=010 http://www.Test.com//rdwd/txl/rdwdznyd/index.html?queryType=common&applyArea=010 &kbKey= 請輸入您要搜索的問題

訪問上面的頁面，發現內容相同，則說明是否帶這三個參數不會影響探索發現更多的頁面，則可以設置這三個參數每次是否出現，是否有不同值都可以認為是同一個頁面。

設置方法：掃描配置中依次選擇“參數和 Cookie”來實現。然后增加 queryType，applyArea，kbKey 三個參數，均設置為“是否有參數”、“參數是否變化”不影響測試的模式。

切換到“應用程序視圖”，分析“中斷鏈接”，發現一些頁面存在“范圍內容超過最大容量的”的情況，在 IE 瀏覽器中直接訪問，發現這些頁面存在死循環，頁面內容無限遞增。則在掃描配置 - 排除路徑和文件中排除這些頁面。

根據以上設置，建立了兩個掃描任務，均掃描“SQL 注入”和“跨站點腳本編制”。重新探索后，頁面總數減少到 4000 多，測試用例數減少到接近 50，000，兩個掃描任務均在 8 個小時內完成。

?

總結

AppScan 作為一種自動化的掃描設置工具，我們了解其工作原理后，需要根據被測系統的業務特點和網站結構特點，優化配置，從而可以快速的針對性掃描。

常用的設置是可以利用其“探索”功能，快速得到結構，然后分析是否存在“偽靜態頁面”，業務上的“冗余路徑”頁面，“參數重復”頁面等，在掃描配置中對應設置。

同時，如果設置后網站規模還是比較大，則可以根據業務分解為多個掃描任務，從而分而攻之，快速掃描，并結合企業版等工具，綜合匯總分析.

總結

以上是生活随笔為你收集整理的如何更有效使用 Rational AppScan 扫描大型网站，第 2 部分: 案例分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。