私の SQL クエリでは、ユーザーが入力したフォームからデータを送信しています。ここに示すように、列名を PDO でパラメーター化することはできません。クエリの列名はフォームのフィールド名に基づいて動的に挿入されるため、これは重要です。
$_POST 配列で送信された列名をデータベースから取り出して一致しないものを捨てるだけで、簡単に検証できます。これは、SQL インジェクションを回避するために行うべきことですか、それともシステム リソースの無駄遣いでしょうか (データベースに依存する要求の実行が事実上 2 倍になるため)。
3 に答える
列のリストをハードコーディングする以外に、次のような列のクエリを許可するデータベース内の別のテーブルを介して列のリストを作成できます。
QuerableSources
SrcTable SrcColumn DescriptToUser
SomeTable SomeColumn Column used for
AnotherTable AnotherColumn Something Else
etc.
次に、たとえば、読みやすくするためにユーザーが「DescriptionToUser」コンテンツを選択するためのコンボボックスを作成し、有効な列とテーブル ソースを制御します。
彼らが探している値に関しては、間違いなくスクラブ/クリーンアップしてSQLインジェクションを防ぎます。
これは、SQL インジェクションを回避するために行うべき良いことですか?
いいえ。
または単にシステム リソースの浪費です
いいえ。
システムテーブルから選択するだけなので無駄にはなりません。
ただし、ユーザーが一部のフィールドへのアクセスを許可されていない場合でも、ある種のインジェクションになる可能性があります。たとえば、サイト管理者によって入力された (架空の) フィールド "user_role" があり、ユーザーが POST でそれを定義できる場合、ユーザーは自分のアクセス権限を変更できます。
そのため、許可されたフィールドをハードコーディング (ホワイトリストに登録) することが唯一の信頼できる方法です。
データベースに依存するリクエストの実行を効果的に2倍にするため
おとこ。クエリ対象のデータベース。それが彼らの唯一の目的です。単純な選択クエリを維持できないデータベースはナンセンスです。クエリは異なります。挿入 1 は、10 選択よりもはるかに重いです。量ではなく質でクエリを区別する必要があります。
クエリの列名は、フォームのフィールド名に基づいて動的に挿入されます。
挿入/更新クエリの場合はまったく当てはまりますが、SELECT クエリの場合は設計が悪いことの大きな兆候です。WHERE/ORDER BY 句で可変フィールド名を使用することはできますが、テーブル名句のフィールドセットを変更する必要がある場合は、データベースの設計が間違っています。
列名をハードコーディングして高速化できます。プルされたテーブルの説明をキャッシュすることもできるため、テーブル スキーマが変更されるたびにコードを更新する必要はありません。