使用AppScan進行掃描

使用 AppScan 進行掃描

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

在計劃階段：明確目的，進行策略性的選擇和任務分解。
1. 明確目的：選擇合適的掃描策略
2. 瞭解對象：首先進行探索，瞭解網站結構和規模
3. 確定策略：進行對應的配置
4. 按照目錄進行掃描任務的分解
5. 按照掃描策略進行掃描任務的分解
執行階段：一邊掃描一遍觀察
1. 進行掃描
2. 先爬後掃（繼續僅測試）
檢查階段（Check）
1. 檢查和調整配置
結果分析（Analysis）
1. 對比結果
2. 彙總結果（整合和過濾）

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

準備階段

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；可以修改爲其他路徑。該路徑可以在菜單欄中依次選擇工具 - 選項 - 一般 - 文件位置部分修改。

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

有時候大家會發現，已經把上面的地址都修改到了其他盤，但是在掃描過程中，還是會發現 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 注入的問題，則在掃描規則中，我們就可以選擇這兩種類型的規則，其他規則都排除。

具體的掃描規則定製，可以在掃描配置 - 測試 - 測試策略中選擇：

在測試策略中，有多種不同的分組模式，最經常使用的是“嚴重性”，“類型”，“侵入式”、“WASC 威脅分類”等標準，根據不同分組選擇的掃描策略，最後組成一個共同的策略集合。

根據我們這次掃描的目標，關心的是跨站點腳本執行和 SQL 注入的問題，而且不考慮“基礎結構”級別的安全問題。則就可以首先選擇一個默認的掃描策略，然後全部置空，再選擇

跨站點腳本執行和 SQL 注入，最後再去除這兩種掃描策略中和基礎結果相關的安全問題。

方法如下：

選擇缺省的掃描策略，或者把當前的掃描策略，切換到按照“類型”分類，取消掉“基礎結構”和“應用程序”兩種類型。說明：則把掃描策略置空，沒有選擇任何的掃描策略，指所有分佈類型選擇“類型”分類，是因爲類型分類裏面含有的類型，只有兩種類型，可以快速全部都取消掉。

分組類型，切換到“WASC 威脅分類”，選擇“SQL 注入”和“跨站點腳本編制”。
分組類型，切換到“類型”，發現這時候“基礎結構”和“應用程序”兩種類型的掃描策略都是選擇上的模式，而且是虛線，說明這兩種類型下均有部分掃描策略被選擇了。
我們不關心“基礎結構”級別的安全問題，所以在這裏取消“基礎結構”。

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

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

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

瞭解被測試網站

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

表 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.htm

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

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

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

簡單說：


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

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

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


http://www.Test.com/default.aspx?content=business.htmhttp://www.Test.com/default.aspx?content=business_lending.htmhttp://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 參數，默認的參數值是“請輸入您要搜索的問題”：

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

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

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


選框  
　　　　　　　　　　　　　　　　　　　　　　　　選中時 ...

只要添加或除去此參數 /cookie，便再次探索
URL。   　在探索階段，如果兩個 URL 的唯一區別在於一個包括此參數，而另一個不包括此參數，那麼將其視爲不同 URL，並且對兩者都進行探索。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　例如，如果是以下兩個
URL，兩者都將進行探索：

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?thisParam=Value

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　如果您取消選中此複選框，那麼在此情況下，將僅發送一個請求，而其他請求將被廢棄。

只要此參數 /cookie
的值更改，便再次探索 URL。   　在探索階段，如果兩個 URL 的唯一區別在於此參數 /cookie
的值，那麼將其視爲不同 URL，並且對兩者都進行探索。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　例如，如果是以下兩個
URL，兩者都將進行探索：

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?thisParam=Value1

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?thisParam=Value2

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　如果您取消選中此複選框，那麼在此情況下，將僅發送一個請求，而其他請求將被廢棄。

只要添加或除去此參數 /cookie，便重複所有相鄰參數
　　 　在測試階段，如果兩個 URL 的唯一區別在已添加或除去了此參數，那麼將其視爲不同 URL，並且再次測試相鄰參數。

 /cookie測試　　　　　　　　　　　　　　　　　　　　　　例如，如果是以下兩個
URL，將爲相鄰參數生成兩組完整的測試，每個 URL 一組。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?adjacentParam=<test_this>

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?adjacentParam=<test_this>&thisParam=Value

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　如果您取消選中此複選框，將爲相鄰參數僅生成一組測試。

只要此參數 /cookie
的值更改，便重複所有相鄰參數      在測試階段，如果兩個 URL 的唯一區別在於此參數 /cookie
的值，那麼將其視爲不同 URL，並且再次測試相鄰參數。

/cookie測試　　　　　　　　　　　　　　　　　　　　　　　例如，如果是以下兩個
URL，將爲相鄰參數生成兩組完整的測試，每個 URL 一組。

...page.jsp?adjacentParam=<test_this>&thisParam=Value1

...page.jsp?adjacentParam=<test_this>&thisParam=Value2
如果您取消選中此複選框，將爲相鄰參數僅生成一組測試。

查看每個目錄頁面個數

如果一個掃描任務，本身的已訪問 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 數據庫，或用戶確認後沒有發現線索，則就可以在掃描配置 - 測試 - 測試策略中取消選擇該策略。
執行“計劃階段”的檢查，看是否還存在“僞靜態頁面”，“業務類型的冗餘路徑”等，如果存在，則調整掃描配置。

分析階段

在分析階段，結合業務特點，檢查是否掃描範圍，分析掃描結果，並針對掃描出來的問題，進行分析，產生多種類型的報告等。

掃描結果檢查

掃描結束後，建議切換到“應用程序數據”視圖中，對頁面進行分析，檢查是否核心頁面都被測試到了。重點檢查如下部分：

交互式 URL：一些頁面，必須輸入正確的信息，纔可以跳轉到下一個頁面，比如查詢手機欠費的頁面，必須輸入正確的 11 位手機號碼；查詢身份信息的頁面，必須輸入 18 位的身份證號纔可以進入後續頁面。如果沒有配置，AppScan 怎麼知道輸入這些信息？所以如果存在“交互式”URL，可以選擇該 URL 以後，鼠標右鍵，選擇手動探索，在 AppScan 瀏覽器中訪問這些頁面，輸入對應的數據，則 AppScan 會自動記錄這些輸入，並填充到掃描配置 - 自動錶單填充中。
中斷鏈接：看哪些頁面在掃描過程中，訪問出錯或者無法訪問，如針對 time out 的頁面，就可能是因爲網絡原因，掃描過程中沒有及時響應，可以選擇“重試所有中斷鏈接”重新進行訪問。

報告分析

我們需要對報告進行對比分析或者報告彙總合併，方法如下：

增量分析：在實際工作中，經常對一個網站進行定期掃描，那麼我們可以使用報告對比功能，對比兩次產生的結果，檢查哪些問題已經修改，哪些是新發現的安全隱患。方法是選擇報告 - 增量分析。
報告彙總和合並：而如果我們在執行階段，按照業務或者目錄進行了分解，最後可能需要對多份掃描結果進行合併和彙總，合併過程中重複的問題只記錄一次，如掃描任務 A 和任務 B 都發現了 apply.jsp 的 ID 參數存在 XSS 安全隱患，則合併後只記錄一次。報告的合併需要使用到 AppScan 企業版，其具有 AppScan 標準版的掃描功能和強大的報告彙總功能，可以產生儀表盤，報告的對比分析，趨勢分析等。可以把 AppScan 標準版的報告發布到 AppScan 企業版中，方法是菜單欄中依次選擇文件 - 導出 - 將結果發佈到 AppScan Enterprise。

案例分析

工作中遇到一個案例，使用 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

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

　　7.發現


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

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

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


http://www.Test.com//rdwd/jfmz/jifen/index.htmlhttp://www.Test.com//rdwd/jfmz/jifen/index.html?queryType=common&applyArea=010

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

    &kbKey= 請輸入您要搜索的問題

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

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

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

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

使用AppScan進行掃描