ユーザー入力を適切に処理しないレガシーコードの更新に取り組んでいます。このコードは最小限のサニタイズを実行しますが、すべての既知の脅威を網羅しているわけではありません。
新しいコードでは、パラメーター化されたクエリを使用しています。私が理解しているように、クエリはプリコンパイルされており、入力は実行できないデータとして単純に扱われます。その場合、衛生管理は必要ありません。そうですか？
別の言い方をすれば、このレガシーコードでクエリをパラメータ化する場合、現在行っているサニタイズを削除しても大丈夫ですか？または、パラメーター化に加えて、サニタイズのいくつかの追加の利点を逃していますか？
SQLクエリパラメータがSQLインジェクションに対する優れた防御策であることは事実です。埋め込まれた引用符やその他の特殊文字は、いたずらをすることはできません。
ただし、SQLクエリの一部のコンポーネントはパラメータ化できません。たとえば、テーブル名、列名、SQLキーワード。
$sql = "SELECT * FROM MyTable ORDER BY {$columnname} {$ASC_or_DESC}";
したがって、SQLクエリに補間する前に検証する必要がある動的コンテンツの例がいくつかあります。値をホワイトリストに登録することも良い手法です。
また、列のデータ型で許可されているが無意味な値を持つこともできます。このような場合、SQL制約で検証するよりも、アプリケーションコードを使用して検証する方が簡単なことがよくあります。
クレジットカード番号を保存するとします。クレジットカード番号には有効なパターンがあり、ライブラリは無効な番号から有効な番号を認識します。
または、ユーザーが自分のパスワードを定義するときはどうですか？十分なパスワード強度を確保するか、ユーザーが2つのパスワード入力フィールドに同じ文字列を入力したことを検証することをお勧めします。
または、ある数量の商品を注文する場合は、その数量を整数として保存する必要がありますが、ゼロより大きいことを確認し、1000より大きい場合は、ユーザーに次のことを再確認する必要があります。彼らはそれを正しく入力しました。
パラメータ化されたクエリはSQLインジェクションを防ぐのに役立ちますが、クロスサイトスクリプティングに対しては効果がありません。これを防ぐには、HTMLエンコーディングやHTML検出/検証などの他の手段が必要です。気になるのがSQLインジェクションだけの場合は、パラメーター化されたクエリでおそらく十分です。
クロスサイトスクリプティングの防止や、フィールドの正しいコンテンツ（電話番号に名前がない）が必要な場合など、サニタイズと検証を行う理由はさまざまです。パラメータ化されたクエリにより、SQLインジェクションに対して手動でサニタイズまたはエスケープする必要がなくなります。
これに関する私の以前の回答の1つを参照してください。
正解です。SQLパラメータは実行可能コードではないため、心配する必要はありません。
ただし、それでも少し検証を行う必要があります。たとえば、varchar（10）を期待していて、ユーザーがそれより長いものを入力した場合、例外が発生します。
要するにいいえ。入力のサニタイズとパラメーター化されたクエリの使用は相互に排他的ではなく、独立しています。どちらも使用できません。一方を単独で使用することも、両方を使用することもできます。さまざまな種類の攻撃を防ぎます。両方を使用するのが最善のコースです。
マイナーな点として、動的SQLを含むストアドプロシージャを作成すると便利な場合があることに注意することが重要です。この場合、入力がパラメーター化されているという事実は、SQLインジェクションに対する自動防御ではありません。これはかなり明白な点に思えるかもしれませんが、入力がパラメーター化されているため、SQLインジェクションについて心配するのをやめることができると考える人に出くわすことがよくあります。