「mysql_real_escape_string()」は本当に SQL インジェクションを防ぐのでしょうか?

mysql_real_escape_string() は SQL インジェクション防止に十分ですか?

mysql_real_escape_string() を採用することで SQL インジェクションを防ぐことができると多くの人が信じていますが、実際には、バイパス

欠陥

次のような特定の場合:

mysql_query('SET NAMES gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

サーバーの予期される文字の不一致により問題が発生します。セットとクライアントの認識。 「SET NAMES」を使用してサーバー上の文字セットを変更すると、mysql_real_escape_string() は ' を ASCII のようにエスケープする可能性がありますが、サーバーはそれをプレーンテキストとして想定します。これにより不一致が生じ、フリーハング ' とインジェクションが可能になります。

悪い

PDO のプリペアド ステートメントのデフォルト エミュレーションも、この抜け穴につながる可能性があります。エミュレーションを無効にすることが推奨されますが、サポートされていないクエリに対してエミュレーションにフォールバックすると、完全な保護が妨げられる可能性があります。

The Ugly

MySQL 4.1.20 より前では、バグにより無効なマルチバイト文字が許可されていました。ペイロードに見られるものと同様、正しいクライアント文字セットであっても単一バイトとしてエスケープされます。

節約猶予

utf8mb4 や utf8 などの影響を受けない文字セットを使用するか、NO_BACKSLASH_ESCAPES SQL モードを有効にすると、これに対する保護が提供されます。

結論

mysql_real_escape_string() の使用は多くの状況で引き続き有効ですが、潜在的なエッジ ケースを認識することが重要です。包括的な SQL インジェクション保護には、列挙型フィールドやプリペアド ステートメントなどの安全な手法を、適切な文字セットやモード構成とともに使用することが不可欠です。

以上が「mysql_real_escape_string()」は本当に SQL インジェクションを防ぐのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。