混合分析的示例

以下是混合分析的一些示例。

在此報告截屏中，DAST 和 SAST 都發現了跨站點腳本編制漏洞。

如果我們查看 DAST 的“關于此問題”報告，問題是在參數“uid”中發現的，所用的方法是移除 ASP.NET_SessionID cookie 并將 '1234"/>alert(1558)</script>' 注入參數“uid”的值中。Appscan 將測試標記為漏洞，因為它已成功嵌入到響應的腳本中，而且一旦頁面被裝入到用戶的瀏覽器后就會執行。這意味著應用程序易受到以下 URL 上跨站點腳本編制攻擊：http://demo.testfire.net/bank/login.aspx。

如果我們查看 SAST 的“關于此問題”報告，代碼可發現 C:\WebTest\Default.aspx.cs（http://demo.testfire.net/bank/login.aspx 的源代碼頁）上存在相同漏洞。

因為 URL、實體和問題類型匹配，所以它被認為是直接相關。

混合分析的最佳做法

但因為測試方法各有不同，所以相關百分比可能相對較低。每類分析的挑戰和優點均不同，如下表中所述。

**

粗體文本指示優點。

**

對于最佳相關規則：

1. 對 SAST 問題進行預過濾以對確定可疑問題施以最高嚴重性設置。
2. 在發布到 AppScan? Enterprise 之前保存部分評估或配置要自動應用的過濾器。
3. 通過 DAST，確保盡可能的探索應用程序，并使用對應用程序有意義的最完善的安全測試策略。
4. 確保用兩種方法分析相同版本的 Web 應用程序。

靜態分析發現項目和動態分析問題之間的差異

了解發現項目和問題之間的差異，以便使報告有意義。

了解動態分析問題在報告中的顯示方式

動態安全問題的報告包含邏輯問題。對于每個邏輯問題，可能存在一個或多個已在其中識別了該問題的變體（變量，或稍微不同的方式）。

例如，對于特定 HTTP 請求，將在該請求上執行若干變更并發送回 web 服務器。這些測試中的許多測試都是相同的（發送的有效內容除外）。在某些情況下，它可能是單引號；在其他情況下，它可能是括號等。如果這些測試是肯定的，那么它們最有可能具有相同的根源并被一起分組在一個問題下。

這將減少完成掃描之后所需的分類工作量。許多問題都具有與其相關聯的 10 個或更多變體，因此，它會減少報告中用戶要處理的項數。此外，在修復過程中，如果向開發者指定問題，它也可用 – 他們可以看到如何檢測到此漏洞的若干示例，所有示例都位于同一個位置。

了解靜態分析發現項目在報告中的顯示方式

在 AppScan? Source 中，會為發現項目指定嚴重性和分類。分類本質上是在特定發現項目中的“置信度”。用于導入和組織 AppScan Source 靜態分析發現項目的方法在應用時與針對動態分析問題的方法基本上相同。在許多情況中，多個發現項目將應用于相同的邏輯問題中；將應用相同的根源和修復。

這些發現項目將在報告中分組在一起，每個 AppScan Source 發現項目將視為相同邏輯問題的一種變體。在處理期間，一個發現項目將產生一個變體，可能存在完全重復的這類極少數情況除外，在種這情況下，將廢棄重復。在導入期間將顯示統計信息，以對處理發現項目的方式和將發現項目映射到問題的方式的分類進行說明。這不僅可將相關發現項目組織在一起，而且還可以減少對這些問題進行分類所需的總體工作量。

在 AppScan Enterprise Server 中，將對問題（而非個別發現項目）進行管理（假設如果問題屬于“誤報”，那么該問題的所有變體也都屬于誤報，并假設如果問題“已修復”，那么該問題的所有變體也已修復）。