私はそれを信じるように導かれました：
$selection = mysql_query($dblink, "SELECT * FROM table WHERE name='$idValue' ");
$idValueの値で簡単に危険にさらされる可能性があります 'を閉じます 次に、
$idValue = "z'; DELETE * FROM table WHERE name IS NOT NULL";
複数のステートメントが無効になっているとおっしゃっていますが、それほど恐ろしいことではありませんが、次のように、テーブル内のデータを直接編集するのではなく、許可されていないデータを返すことです。
$idValue = "z' OR name IS NOT NULL OR name = 'x";
MySQLiには可能性があります このアプローチはprepared statementsで使用できること 、これにより、変数が単なる変数としてのステータスの外で動作するのを防ぐことができます。例：
mysqli->prepare("SELECT * FROM tables WHERE name = ? LIMIT 1");
mysqli->bind_param("s",$idValue);
mysqli->execute();
bind_paramについての私の理解 つまり、変数にはすべてのMySQLキーワードとキー文字がエスケープされているため、セキュリティ違反と不正な行の返送が防止されます。
これは、MySQLが持っていない選択です。 。プリペアドステートメントは、改善に役立ちます インジェクションセキュリティですが、防止はしません インジェクション攻撃だけですが、プログラマーによるより広範な戦略の一部として、より多くを使用する必要があります。
ボディアーマーを着用しても無敵にはなりませんが、生存の可能性が大幅に向上します。 MySQLiは特効薬ではなく、PDOでもありませんが、全体的なセキュリティレベルを向上させます。
MySQLも非推奨であり、Christopherが述べているように、MySQLが維持されなくなったということは、他のテクノロジーが開発を続けるにつれて、MySQLの穴と問題の数が増えるだけであることを意味します。
概要
MySQL iを作成する場合 MySQLステートメントを記述したのと同じ方法でステートメントを作成すると、インジェクションからの追加の保護はなくなります。ただし、MySQLiはプリペアドステートメントを提供します SQLインジェクションに対する防御を大幅に強化するアプローチですが、基盤となるデータベースインターフェイス自体を変更しても、プリペアドステートメントを使用して自分でコーディングすることを選択しない限り、固有の利点や保護は得られません。 。