0

asp.netを使用してWebサイトを開発しています。

SQL を使用するインターフェイスのチェックボックスによって駆動されるいくつかのフィルター メカニズムに基づいて、テーブルをクエリする必要がある状況があります。そのため、フィルターにはいくつかの組み合わせがある場合があります。最後に、動的SQLクエリを使用することでこれを実現できることがわかりました。そこで、ストアド プロシージャを作成し、適切なクエリを生成した後、アプリからストアド プロシージャにクエリを渡しました。

私のサンプルストアドプロシージャは次のようになります

CREATE PROCEDURE usp_dynamic(IN query_one VARCHAR(500))
BEGIN
    SET @s = CONCAT('SELECT col1,col2 FROM test_table where',query_one );
    PREPARE stmt FROM @s;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END

そこでいくつか質問があります

1) これは安全ですか? つまり、SQL インジェクションにつながるのでしょうか?

2) ストアド プロシージャは常に最適なクエリ プランにコンパイルされます。動的クエリは、クエリが正しく行われるたびに SP を再コンパイルしますか?

3) パフォーマンスの問題はありますか?

4) このアプローチを使用する際に注意する必要があるその他の事実はありますか?

5)何か問題がある場合、それらを最小限に抑えるためにどのような行動を取ることができますか?

4

2 に答える 2

0

SQL インジェクションは、クライアントから送信された SQL ステートメント、T-SQL ストアド プロシージャで生成された動的 SQL、または CLR ストアド プロシージャから実行された SQL バッチなど、不注意に (パラメーターなしで) 処理される動的 SQL があるとすぐに可能になります。

クライアントから送信される SQL に対するストアド プロシージャのもう 1 つの利点は、ネットワークを移動するバイト数が少ないことです。ネットワーク経由で 50 行のクエリを送信するのではなく、ストアド プロシージャの名前といくつかのパラメーターを渡すだけで済みます。これは、計算に複数のクエリが必要であり、間にロジックが含まれている可能性がある場合、より重要になります。すべてのロジックがデータベースの外部にある場合、これは、データがクライアントまで移動する必要があり、次の瞬間に戻るだけであることを意味する可能性があります。

したがって、ここではパフォーマンスが考慮されます。

動的クエリを改善するには、次のプラクティスに従ってください

于 2015-05-28T08:07:03.383 に答える
0

サーバー上でクエリを作成したからといって、何も変わりません。まったく同じ問題が適用されます。問題は、「動的SQL」自体の使用であり、実行場所ではありません

具体的には：

  1. セキュリティは向上していません。入力として渡すこともでき1=1;drop table users;--ます。
  2. すべての SQL コードはクエリ プランにコンパイルされます。ストアド プロシージャは、より良い計画にはなりません。利点は、実行するクエリが変更されない限り、ストアド プロシージャのプランを再利用できることです。これは、さまざまなクエリを実行するプログラムによって構築された条件ステートメントの場合です。したがって、クエリ プランのメリットも得られません。
  3. パフォーマンスはまったく向上しません。ステートメントを明示的に準備するか、クエリ オプティマイザーにプランを作成させるかにかかわらず、個々のクエリをコンパイルする必要があります。

実際、クライアントから送信されたパラメーター化されたクエリは、より安全でパフォーマンスが向上します。これは、インジェクションが防止され、クエリ オプティマイザーがパラメーター化されたクエリ プランを作成して再利用できるためです。

于 2015-05-28T08:01:37.263 に答える