Web サービスを呼び出して、動的に生成された SQL の文字列を渡しています。この文字列にはユーザー入力が含まれます。現在、単純な文字列連結を使用して構築されているため、SQL インジェクション攻撃に対して脆弱です。アプリケーションからコマンドを実行していないため、通常のパラメーター化された SQL ソリューションを使用できません。
私の最初の試みは、パラメーター化された SqlCommand オブジェクトを構築することでした。ただし、最終的な SQL ステートメントを抽出する方法はないようです。私の 2 番目の試みはsp_executesqlを使用することでしたが、元のコードと同じ問題があるようです: SQL コマンドをユーザー入力と連結することです。
では、独自の入力サニタイズ ロジックを作成せずに SQL を生成するにはどうすればよいでしょうか (つまり.Replace("'", "''")、組み込みクラスやサードパーティ製の優れたライブラリを利用できますか?
私が質問を理解しているように...どうすれば、独自の入力サニタイズロジックを書くことに頼らずにSQLを生成できますか. 使用を検討すべきいくつかの SQL インジェクション軽減手法があります。これらには、バックエンドに基づくセキュリティ ベースのものもあれば、データベース エンジンによって強制されるビジネスおよびアプリケーション開発ルールもあります。
バックエンド セキュリティ: 常に「最小権限」ルールを適用します。DBMS にアクセスするアプリケーションには、権限の低いデータベース アカウントを設定します。サーバー側のサニテーション: サーバー側。ユーザーが提供したデータを検証する – 安全でない可能性のあるソースから取得したデータと同様に、クライアント側の入力検証が役立つ場合があります
クライアント側: ユーザーに SQL エラー メッセージを返さないでください。SQL エラー メッセージには、対象のテーブルやそのコンテンツに関するクエリや詳細など、攻撃者にとって有用な情報が含まれているためです。これは、Java で例外処理を使用して簡単に防ぐことができます。
クライアント側: 問題のある文字が含まれている可能性があるテキスト入力フィールドを、Base64 などの双方向関数を使用して英数字バージョンにエンコードします。
クライアント側: SQL インジェクションを防ぐために積極的にコードを記述します。2 段階のプロセスですべての入力データをフィルター処理します。まず、ユーザー入力コレクション (Web フォームなど) にホワイトリスト フィルタリングを適用します。フィールドに関連する文字、文字列形式、およびデータ型のみを許可します。文字列の長さを制限します。次に、SQL クエリを生成する前に、データ アクセス層でブラック リスト フィルタリングまたはエスケープを適用する必要があります。SQL メタ文字とキーワード/演算子をエスケープします。
クライアント側または中間層側: 動的に生成されたデータベース オブジェクト名 (テーブル名など) を厳密なホワイト リスト フィルタリングで検証します。
クライアント側 引用符付き/区切り記号付きの識別子は避けてください。ホワイトリスト、ブラックリスト、およびエスケープのすべての作業が非常に複雑になるためです。
開発: セキュリティを確保し、SQL インジェクションを回避する安全な API を開発者に提供するプロセスを実施します。開発者に頼って複雑な防御コーディング手法を実装する代わりに、これを行ってください。
API: コンパイル時にデータベース スキーマを分析し、SQL クエリ構築クラスのカスタム セットのコードを記述する API または中間層を開発します (これらは IDE に統合され、SQL クエリを構築するために開発者によって直接呼び出されます)。その結果、汎用テンプレートに基づくツリー状の構造が作成され、テーブルと列の定義に従って SQL クエリの可能なバリエーションがマッピングされます。クラスには、SQL ステートメント、テーブル列、および where 条件の 3 つの主なタイプがあります。これらのクラスには、データベース スキーマのデータ型をマッピングする厳密に型指定されたメソッドがあります。攻撃面が減少します。提案された API は、質問で指定したとおりにクエリを実行せず、SQL を生成するだけです。提案された API は、入力値の送信時に、そのマッピングに対してデータ型をチェックします。2番、クエリは、JDBC の PreparedStatement インターフェイスとバインドされた変数を使用して、DBMS 固有のドライバーによって事前にコンパイルされます。いずれかのステップでエラーが発生すると、クエリの実行が妨げられます。
開発者が使用する提案された API 設計は、サーバー側の検証、SQL エラーのインターセプトに対処します。動的入力は PreparedStatement インターフェイスを介して別の保護されたデータ チャネル (バインドされた変数) を介して挿入されるため、強力な型指定が直接適用されますが、テキスト入力のエンコードと 2 段階の入力検証は必要ありません。オブジェクト名はユーザーによって入力されず、定期的に検証されます。ただし、提案された API には、権限の低いデータベース アカウントを提供する必要があります。
提案された API では、データベースとの対話の直前に保護が適用されるため、データ入力エントリ ポイントを識別する必要はありません。セグメント化されたクエリは完全にサポートされています。各クエリの変更が API によって検証されるため、セキュリティが確保されます。バインドされた変数を使用して動的入力が指定されるため、ホワイト フィルタリングとブラックリストは不要です。
提案された API では、列の長さ (varchar フィールドなど) を DB クラスに (名前やデータ型と同様に) 格納できるため、ソリューションは入力データの境界検証を実行できるため、保護レベルと全体的な精度が向上します。
同様の API 設計の Java ベースのプロトタイプが進行中であり、現在も研究が進められています。