1

パラメータをハード値に置き換えることで、SQL Server クエリのパフォーマンスが大幅に向上するという問題が発生しています。例えば：

SELECT * FROM Table1 WHERE RowNumber >= 101 AND ID < 200

次のものよりも大幅に高速です。

DECLARE @Start int = 101;
DECLARE @End Start int = 200;

SELECT * FROM Table1 WHERE RowNumber >= @Start AND RowNumber < @End

最初のものは約 2 秒で実行され、2 番目のものは 15 秒で実行されます。私の質問は、ハード値が数値であり、文字列のみをパラメータ化する場合、ハード値を使用しても安全ですか? RowNumber 列は既に非クラスター化インデックスとしてインデックス化されているため、これはインデックスの問題ではないと思います。私はすべての SQL インジェクション手法に精通しているわけではありませんが、SQL インジェクション攻撃を回避するために、何年もの間、すべての入力値にパラメーターを使用してきました。パラメータを使用することで、このようなパフォーマンスが低下する可能性があることにまったく気づきませんでした。

パラメータを使用したパフォーマンスの低下に関する SO に関する質問もいくつか見ましたが、問題の解決方法に関する決定的な回答は見当たりませんでした。

4

3 に答える 3

3

何よりも、「私はすべての SQL インジェクション手法に精通しているわけではありません」というステートメントを考えると、常に安全にプレイし、パラメーター化されたクエリを続行する必要があります。

私はユーザー グループで SQL インジェクション攻撃に関する講演を行っていますが、すべてを知っているとは思いません。私は攻撃が行われるさまざまな方法について多くのことを知っていると思っていましたが、話の後に一人の男が私のところに来て、彼が働いていた会社で起こった攻撃について教えてくれました。OCR マシンによって読み取られた紙のフォーム。以前は、そのような形の攻撃を考えたことはありませんでした。

攻撃はあらゆる種類の奇妙な方法で発生し、できる限りのことを考えたとしても、他の誰かが常にシステムを攻撃する別の方法を考えることができます.

于 2012-08-10T15:50:05.633 に答える
0

SQL Server は、一部の定数式を早い段階で評価して、クエリのパフォーマンスを向上させます。これをコンスタント フォールディングと呼びます。

上記のクエリでは、クエリをコンパイルする前に定数が評価され、オプティマイザーは何もする必要はありません。ただし、パラメーターの場合、オプティマイザーは実行時に毎回コンパイルする必要があります。

于 2012-08-10T15:50:13.043 に答える
0

コメント ( //または/ ) とスペースは SQL インジェクション (攻撃) を行うため、数値フィールドは危険です。

多くのサイトでは、ユーザーとパスワードが一致する場合、ユーザーは予約されたエリアに入ることができます。

パスワードに数値フィールドを使用するクレイジーなサイトを考えてみましょう:

 .....  Where User='James' and Pass=123

Javascript でユーザー入力を検証する場合でも、post 値を変更するのは非常に簡単です。したがって、123 の代わりに以下の部分を「注入」できます。 

             123  or 1=1

すべてのレコードが返されます。多くのサイトがこの状況を検出しますが、ユーザー フィールドが「ユーザー」または「ユーザー名」であることは非常に一般的です。そのため、「user」やその他の一般的なフィールド名を構造の下で試すことができます

            12  or 1=1  and User='James'

この場合、目的のレコードのみが返されます。

数値フィールドの簡単な解決策は、一重引用符を使用することです。

                  Select User='James' and Pass='123'

私は、SQL Server、MySQL、および SQLite がこの構文を受け入れることを確認しました。電子メール、名前などのために、文字列で単一引用符を使用しないようにするのは困難です。

于 2013-01-26T04:12:28.667 に答える