プリペアドステートメントによるSQLインジェクション？

Question

私が正しく覚えていれば、JeffはStack OverflowポッドキャストでSQL準備文の弱点を説明していると思います。私は彼がどんな種類の弱点を指摘したのか疑問に思いますか？おそらくinappropriate usageか、それとももっと邪悪なものでしたか？

私の覚えていることではあるが、ポッドキャストはそのテーマに深く関わっていない。

Answer 1

私はポッドキャストに耳を傾けませんでしたが、私の経験では唯一の良いことは準備された発言から来ています。これはしばしばアプリケーションのパフォーマンスを向上させ、SQLインジェクションを防ぎます（リンクに2番目の例ではなく、正しく使用されている場合）。

Answer 2

準備されたステートメントに、動的に構成されたパラメーターがある場合は、弱点の原因となる可能性があります。

パラメータを設定するためのテスト済みのクラスで適切なデータベースライブラリを使用する場合は、準備されたステートメントかどうかにかかわらず、SQLインジェクションまで自分自身を開きません。

ステートメントが準備されているか、ストアドプロシージャを使用しているという理由だけで、注射による攻撃から安全であるとは限りません。 SQLインジェクションから保護されているパラメータの入力をサニタイズするデータベースプロバイダコードを使用する場合（使用可能なすべてのパラメータに適用するだけでなく）です。

Answer 3

通常のSQLインジェクション（私たちが一次と呼ぶかもしれません）攻撃には、二次レベルがあります。たとえば、ストアドプロシージャを持つことは珍しくなく、文字列連結を使用してクエリを構築し、それを実行します。検索されたフィールド値の結果がそのような連結に含まれる場合、注入の危険がある。

Answer 4

Prepared Statementsを使用すると、SQL Serverはクエリの実行計画をキャッシュできるため、実行中のクエリのパラメータの一部を変更しても、サーバーが間違ったものを選択する可能性がありますキャッシュされた）実行計画は非常に悪い結果をもたらします。

また、この状況を克服するために使用した実行計画の再評価をエンジンに強制するSQL Server 2008の新機能についても説明しました。

Prepared Statementsでは、私にはこれが唯一の問題です。

ここで、テーブル（名前）にインデックスがある場合は、クエリプランで使用されることになります。まあ、そうではありません。 PraparedStatementはあらかじめコンパイルし、最悪の場合は '％PATTERN％'を期待する必要があるためです。したがって、最適化されません。このことを理解するまでにはしばらく時間がかかりました。私のデータベースに苦しんでいた。 :(

希望します。