サンプル・トレースの結果

次のサンプル・トレースの結果は、SQL インジェクションの脆弱性が含まれるアプリケーションのセクションを通過する汚染されたデータの流れを示します。

このサンプルでスキャンされたコードは、アプリケーションのデータベースを標的とするアタッカーに対してドアを開けたままにしている、信頼できないソースからのデータを検証もサニタイズもしません。

このサンプル・トレースでは、doPost サーブレット・メソッドが request.getParameter を呼び出します。このメソッドは、HTTP POST 本文から信頼できないデータ (ユーザー名) を読み取りますが、データの妥当性の確認も、データのサニタイズも行いません。この未検証の (汚染された) データは、次に changePassword メソッドに渡されます。最終的にこのメソッドから、脆弱性が悪用されるおそれのある汚染されたデータが statement.execute メソッドに渡されます。

トレースには、次の情報が含まれます。
  • request.getParameter("username") は、ソース () としてマークされます。その戻り値は、信頼できないデータの発生元です。
  • statement.execute( ) は、その最初のパラメーターから、汚染されたデータ (悪意のある SQL コマンドを含む) が検証もサニタイズもされずに sql パラメーターに渡されるおそれがあるため、シンク () としてマークされます。
  • string.Builder( ).append( ) は、汚染されたデータをあるポイント (最初のパラメーター) から別のポイント (戻り値) に渡すコンジットとして機能するため、汚染伝播元 () としてマークされます。
  • 汚染されたデータの流れは、赤色でマークされます。汚染は request.getParameter から始まり、汚染されたデータが username 変数に渡されます。次にデータは、汚染伝播元を通過して SQL ステートメントに追加され、statement.execute メソッドによって実行されます。
  • トレース内の各ノードは、トレースが発生するコード内の行数を、対象のコード・スニペットとともに提供します。例えば、ソース () では、90 行で発生します。
  • 残りのトレースで、青色のバーは、セキュリティー脆弱性を除去するための修正を実装できる場所を示します。この例では、汚染されたデータが SQL ステートメントに追加されるシンクの近くにデータ検証および / またはサニタイズを追加する必要があります。より良いソリューションとして、この SQL クエリーを準備済みステートメントとして適切に実行することが挙げられます。
  • この例では、左の暗い青色のバーは、複数の問題をトレースするための共通のメソッドをハイライトしています。これは修正グループと呼ばれ、対処すれば複数の問題を解決できる可能性があるコード内の場所を示します。このため、修正グループは最初に調査すべきです。このトレース例では、この特定の問題について append ( ) が呼び出される場所を調査すべきです。
    スキャン・レポートでは、可能であれば修正グループ別に問題が一覧表示されます。各修正グループ内では、最初に問題のタイプ、次に各タイプの個別の問題と各問題のトレースが一覧表示されます。推奨される修正には 2 つのタイプがあります。
    • 修正がアプリケーション・コードの一部であるメソッドに対するものである場合、コードの実装を修正します。
    • 修正がサード・パーティーのコードを呼び出す場所に対するものである場合、コードの使用法を修正します。