盤查以參數為基礎的導覽網站

掃描導覽為以參數為基礎的網站時所需配置變更的說明。

依預設,AppScan 的「冗餘路徑限制」為 5 (要求可傳送至相同 URL 的次數上限,請參閱「探索選項」視圖)。在一般網站中,這可防止不必要地重複進行測試。不過,當網站導覽是以參數為基礎時,這個低限將有效防止 AppScan® 徹底掃描網站,而且使用「一般掃描」範本執行的掃描,將幾乎無法發現及測試任何網站。

增加「冗餘路徑限制」,或是將它完全停用,並無法單獨解決此問題。事實上,它可能使 AppScan 陷入無限迴圈,或至少會建立含有過多測試的掃描,而使 AppScan 在執行時發生記憶體不足。這個問題有兩個原因:
  1. 在「探索」階段期間,對要求進行雜湊動作時,AppScan 會將找到的所有參數和 Cookie 併入該要求中。若取消冗餘路徑限制,便會將這些值的所有組合納入考量。

    舉例來說,假設網站區段的每一個頁面,都包含某個 Script 的數百個鏈結,這個 Script 會從資料庫中擷取可銷售項目的其他資訊。這些鏈結包含一個名為 item_id 的參數,它在產生新頁面中並不重要,只用來擷取項目的其他資訊。AppScan 最後會要求此項目資訊頁面的數千個實例,除非能夠將 item_id 從雜湊中排除。

  2. 在「測試」階段中,問題變得更加嚴重。假設要求包含 par1par2 兩個參數,且 AppScan 發現含有這些參數的四個鏈結:
    http: // site.com/content.aspx?par1=a&par2=c
    http: // site.com/content.aspx?par1=a&par2=d
    http: // site.com/content.aspx?par1=b&par2=c
    http: // site.com/content.aspx?par1=b&par2=d

    如果適用於每一個參數的測試有 400 個,AppScan 共會傳送 1600 個測試(當 par2=cpar2=d 時,par1 上 800 個,當 par1=apar1=b 時,par2 上 800 個)!因此,除了從「探索」雜湊中排除這些參數之外,還必須告知 AppScan 每個參數只測試一次:par1 上 400 個測試,par2 上 400 個測試。

因此,衍生自上述以參數為基礎的導覽方式掃描網站的原則如下:
  1. 探索階段:忽略導覽參數以外所有參數的值。
  2. 測試階段:當參數值變更時,請勿建立新測試,但導覽參數除外。

另請參閱:

使用以參數為基礎的導覽網站

以參數為基礎的導覽範本