「mysql_real_escape_string()」は SQL インジェクションに対して本当に安全ですか? それとも微妙な脆弱性があるのでしょうか?

mysql_real_escape_string() は完璧ですか?

mysql_real_escape_string() は SQL インジェクション攻撃を防ぐために一般的に使用されていますが、まれで複雑なケースではありますが、回避することができます。

独創的攻撃

非常に特殊な文字セットで慎重に作成されたペイロードを使用すると、mysql_real_escape_string() が悪用される可能性があります。内訳は次のとおりです:

1. 文字セットの選択: サーバーの接続文字セットは、ASCII バックスラッシュ ('') と最終バイトが ASCII ' である文字の両方をサポートするものに設定する必要があります。たとえば、'gbk' はこの基準を満たします。
2. ペイロード: バイト シーケンス '0xbf27' で構成されるペイロードが選択されます。 「gbk」では無効な文字ですが、「latin1」では「¿」を表します。
3. mysql_real_escape_string(): MySQL のこの関数の実装では、接続文字セット (この場合は 'gbk')、その規則に従ってエスケープを適用します。ただし、クライアントは依然として接続が「latin1」を使用していると信じています。したがって、「mysql_real_escape_string()」でバイト シーケンスをエスケープすると、バックスラッシュが挿入されます。
4. クエリ: 結果の文字列にはフリーハング ' 文字が含まれます: '縗' OR 'gbk' の 1=1 /*'。これは、攻撃に必要な悪意のあるペイロードです。

明らかな脆弱性

1. PDO エミュレートされたステートメント:PDO は、デフォルトで、次を使用して準備されたステートメントをエミュレートします。 mysql_real_escape_string()、これに対して脆弱になりますAttack.
2. mysql_real_escape_string() バグ: MySQL 4.1.20 および 5.0.22 より前では、mysql_real_escape_string() には、クライアントが無効なマルチバイト文字を単一バイトとして扱うバグがありました。正しい接続エンコーディングが通知されるため、この攻撃が可能になります。 success.
3. PDO の制限された安全対策: PHP 5.3.6 以降で導入された PDO の DSN 文字セット パラメーターは、すべてのコマンドで一貫してサポートされているわけではありません。これにより、悪用の余地が残されます。

影の除去

1. 安全な文字セット: 'utf8' や 'utf8mb4' などの攻撃を受けにくい文字セットを使用すると、影が軽減されます。これ
2. NO_BACKSLASH_ESCAPES SQL モード: このモードを有効にすると、mysql_real_escape_string() の機能が変更され、脆弱なエンコーディングで有効な文字が作成されなくなります。
3. 最新の MySQL バージョンおよびプリペアドステートメント: MySQL バージョン 5.1 (late)、5.5 以降、および真の準備済みステートメント (MySQLi など) は、このエクスプロイトの影響を受けません。

結論として、mysql_real_escape_string() は一般的に効果的ですが、効果的である可能性があります。特定のシナリオでは回避されます。 MySQL の最新バージョン、適切な文字セットの選択、および真のプリペアド ステートメントにより、この複雑な攻撃に対する完全な保護が保証されます。

以上が「mysql_real_escape_string()」は SQL インジェクションに対して本当に安全ですか? それとも微妙な脆弱性があるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。