[解決済み] パラメータ化された文はすべてのSQLインジェクションを止めることができますか？

質問

もしそうなら、なぜ SQL インジェクションの成功例がまだたくさんあるのでしょうか? 一部の開発者がパラメータ化されたステートメントを使用するにはあまりにも間抜けだからでしょうか?

どのように解決するのでしょうか?

私が質問に対するコメントで投稿したリンクは、この問題を非常によく説明しています。 なぜこの問題が続いているのか、私の気持ちを以下にまとめました。

1. 始めたばかりの人は、SQL インジェクションをまったく意識していないかもしれません。

2. SQL インジェクションを認識しているが、エスケープが (唯一の?) 解決策であると考えている人もいます。 Google で検索すると php mysql query と検索すると、最初に表示されるページが mysql_query ページで、エスケープされたユーザー入力をクエリに補間する例があります。 代わりにプリペアド ステートメントを使用することについては (少なくとも私が見た限りでは) 言及されていません。 他の人が言ったように、パラメータ補間を使用するチュートリアルは非常に多いので、それがいまだに使用されていることは驚くことではありません。

3. パラメータ化されたステートメントがどのように機能するかについての理解不足。 値をエスケープするための単なる空想の手段だと考えている人もいます。

4. 他の人は、パラメタライズド ステートメントを認識していますが、遅すぎると聞いたことがあるため、使用していないようです。 多くの人が、パラメタライズド ステートメントがどれほど信じられないほど遅いかを聞いたことがあっても、実際に自分自身でテストしたことはないのではないでしょうか。 Bill Karwinが講演で指摘したように、プリペアドステートメントの使用を検討する際に、パフォーマンスの違いを要因として用いることはほとんどないはずです。 の利点は 一度準備すれば、何度でも実行できる の利点は、セキュリティやコードの保守性の向上と同様に、しばしば忘れ去られているように見えます。

5. パラメータ化されたステートメントをいたるところで使用するものもありますが、テーブルやカラム名、キーワード、条件演算子など、チェックされていない値を補間して使用します。 ユーザーが多くの異なる検索フィールド、比較条件、およびソート順を指定できるような動的検索は、この典型的な例です。

6. ORM を使用する際の誤った安心感。 ORMはまだSQL文の部分を補間することができます - 5を参照してください。

7. プログラミングは大きく複雑なテーマであり、データベース管理は大きく複雑なテーマであり、セキュリティは大きく複雑なテーマです。 安全なデータベースアプリケーションを開発するのは簡単ではありません。

8. stackoverflow の回答の多くは役に立ちません。 人々が動的 SQL とパラメータ補間を使用する質問を書いたとき、代わりにパラメータ化されたステートメントを使用することを提案する回答は、しばしば不足しています。 何度か、プリペアドステートメントを使うようにという私の提案に反論する人がいましたが、たいていの場合、パフォーマンスのオーバーヘッドが受け入れられないと認識されているからです。 これらの質問のほとんどは、パラメータ化されたステートメントの準備にかかる余分な数ミリ秒が、アプリケーションに致命的な影響を与えるような状況であることを、私は真剣に疑っています。