技術的な問題というよりは、リスク評価の問題です。
だから私はSQLインジェクションからの保護についてたくさん読んでいます。大部分が保護されていない大規模な Web アプリケーションがあり、この問題から保護するためにいくつかの改善を行う必要があるとします。動的クエリを使用して大量の SQL 対話を読み取りますが、少数 (100 人未満の登録ユーザー) で読み取ります。
私の質問は...パラメーター化されたクエリを使用してメインのログイン スクリプト (公開されている唯一のユーザー入力) を既に保護している場合、サイトの残りの部分に対して同じ作業を行う必要があるでしょうか? つまり、潜在的な攻撃者がログインできない場合、彼は他にどれだけの損害を与えることができるでしょうか?
もちろん、私の登録ユーザーが悪意を持っているとは限りません。
ユーザーを絶対に信用しないでください！
たとえあなたがそうしても（そして誰もサインアップできない）、例えばCSRFの可能性は常にあります。攻撃者は、そのシステムのユーザーを、画像のある一見無害なページに誘導します。その画像には次のコードが含まれます。
<img src="http://yourserver.com/profile?user_id='; DROP TABLE users" />
私のハッキングスキルは事実上ジルチですが、何が起こるか想像できます:)
正当なユーザーがシステムを攻撃しようとしないことを保証するものは何ですか?
私の銀行がそう考えていないことを嬉しく思います。SQLインジェクション攻撃を使用するだけで、誰かが私のアカウントを空にしていたでしょう。
その場合でも、事故には注意が必要です。パラメータ化されたクエリを使用する場合、誰か'が値に を使用しても問題は発生しません。
これにより、パラメーターでタイプ セーフが可能になります。
それはより良いプログラミングの習慣を生み出します。
実行計画のキャッシュを許可します。 (それがなければ、異なるパラメーターを持つすべてのクエリは完全に異なるクエリのように見えます。これらのクエリのプランのキャッシュが妨げられるだけでなく、キャッシュがいっぱいになり、実際に再利用できるプランが破棄されます。)
安全性が向上するだけでなく、信頼性も向上します。実験と使い捨てのコードを除いて、パラメーター化されたクエリを使用しないことを容認したプロジェクトは思い浮かびません。