使用 AppScan 進行掃描

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

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

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

準備階段

AppScan 安裝環境要求和檢查

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

表 1. Rational AppScan 安裝配置要求

 
          1 
        
          2 
        
          3 
        
          4 
        
          處理器 　　　　 　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 字符。cookie

修改 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 頁面：

 
     
      
       
          1 
        

          2 
        

          3 
        
 
        
          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 地址，過濾緣由都是「路徑限制」：

 
          1 
        
          2 
        
          3 
        
          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 認爲是冗餘頁面呢 ?

簡單說：

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

Appscan 是根據「?」號來分隔的，若是 ? 號前面的內容都相同，則就被認爲是冗餘頁面，因此上面的頁面就是冗餘頁面了。

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

 
     
      
       
          1 
        
 
        
          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 等頁面，只有文本內容不一樣，頁面架構徹底相同的頁面：如

 
          1 
        
          2 
        
          3 
        
          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 中的測試，是針對頁面的每一個參數進行的，並且一個參數值的變化會要求從新測試其餘的參數，因此該設置，能夠大大減小測試用例數。

 
          1 
        
          2 
        
          3 
        
          4 
        
          5 
        
          6 
        
          7 
        
          8 
        
          9 
        
          10 
        
          11 
        
          12 
        
          13 
        
          14 
        
          15 
        
          16 
        
          17 
        
          18 
        
          19 
        
          20 
        
          選框   　　　　　　　　　　　　　　　　　　　　　　　　選中時 ... 
         
          只要添加或除去此參數  
          / 
          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 論壇功能：

 
      
       
        
           1 
         

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

對於這樣的頁面，訪問後發現頁面結構相同，只是文本內容不一樣，則應該使用「冗餘路徑限制」參數，控制掃描次數，沒有必要屢次掃描。

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

 
           1 
         
           2 
         
           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 請求。
分析發現存在大量的「僞靜態頁面」，如：

 
          1 
        
          2 
        
          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.發現

 
          1 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          service

目錄下存在大量以下類型的頁面，都是 menu 參數值不一樣，訪問之後發現出現的是頁面中有不一樣的超連接：　

 
     
      
       
          1 
        

          2 
        

          3 
        
 
        
          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 在多個目錄下出現，並且每次出現都有兩種格式，即沒有參數和有固定的三個參數，每次的參數值都相同。如：

 
     
      
       
          1 
        

          2 
        

          3 
        
 
        
          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 個小時內完成。