範例追蹤結果

下列範例追蹤結果顯示流經應用程式區段（具 SQL 注入漏洞）的污染資料流程。

這個範例中所掃描的程式碼不會驗證或淨化來自未受信任來源的資料，使得鎖定應用程式資料庫的攻擊者有機可乘。

在這個範例追蹤中，doPost servlet 方法會呼叫 request.getParameter。這個方法會從 HTTP POST 內文讀取未受信任的資料（使用者名稱），但是不會檢查資料的有效性，也不會淨化資料。接著，這個未經驗證或遭受污染的資料會傳遞至 changePassword 方法。這個方法最終會將受到污染的資料傳遞至 statement.execute 方法，在這裡的漏洞就會遭到利用。

追蹤包括下列資訊：
  • request.getParameter("username") 已標示為來源 ()。其傳回值是未信任資料的來源。
  • statement.execute( ) 將其第一個參數標示為接收槽 ()，因為受污染的資料（其包含惡意 SQL 指令）可能會傳遞至 sql 參數，卻沒有經過驗證或淨化。
  • string.Builder( ).append( ) 已標示為污染傳播者 ()，因為它會作為導管，將受污染的資料從一個點（第一個參數）傳遞至另一個點（傳回值）。
  • 污染資料的流程以紅色標示。污染從 request.getParameter 開始，並且將受污染的資料傳遞至 username 變數。然後資料會流經污染傳播者，直到附加至 SQL 陳述式並且由 statement.execute 方法執行。
  • 追蹤中的每個節點會提供在其中發生追蹤的程式碼行號，以及感興趣的程式碼 Snippet。例如，來源 () 在第 90 行發生。
  • 在追蹤的左側，藍色直條會指出可以實作修正以移除安全漏洞的位置。在這個範例中，新增資料驗證及/或消毒應該緊靠接收槽，在接收槽中，污染的資料會附加至 SQL 陳述式。更好的解決方案是以備妥陳述式形式，適當地執行這個 SQL 查詢。
  • 在這個範例中，左側的深藍色直條會強調顯示通用於多個問題追蹤的方法。這稱為修正程式群組，表示程式碼中的某個位置，如果將其解決，可以能解決多個問題。因此，應該首先調查修正程式群組。在這個追蹤範例中，針對此特定問題，應該調查呼叫 append ( ) 的位置。
    在掃描報告中，問題會由修正程式群組列出（可行時）。在每個修正程式群組中，將先列出問題類型，接著列出每個類型的個別問題，以及每個問題的追蹤。修正建議有兩種類型：
    • 如果修正適用於屬於應用程式程式碼的方法，則修正程式碼的實作。
    • 如果修正適用於呼叫第三方程式碼的位置，則修正程式碼的用法。