PHP のaddslashes() は、マルチバイト文字であっても SQL インジェクションに対して本当に安全ですか?

PHP の addslashes() とその SQL インジェクションの脆弱性

PHP 関数 addslashes() は、SQL インジェクション攻撃に対する保護手段としてよく使用されますが、特にマルチバイト文字を扱う場合にセキュリティを損なう可能性がある制限があります。 この記事では、addslashes() が適切な保護を提供できないシナリオについて検討します。

マルチバイト文字エンコーディングの問題

入力データにマルチバイト文字が含まれている場合、addslashes() はバックスラッシュを誤って挿入し、エスケープ シーケンスを破壊し、脆弱性を作成する可能性があります。これは、addslashes() がマルチバイト文字のエンコードを正確に処理できない可能性があるために発生します。

例:

$input = "⭐' OR 1=1 --";
$escapedInput = addslashes($input); // Escapes as ⭐\' OR 1=1 --

ここでは、マルチバイトのスター文字に続く一重引用符がエスケープされず、システムが SQL インジェクションに対して無防備なままになっています。

エンコーディング固有の脆弱性

この問題は、addslashes() が EUC-JP や Shift-JIS などのマルチバイト文字エンコーディングを正しく解釈できない可能性があることに起因します。 これらのエンコーディングの特定の文字シーケンスには、末尾に 0x5c バイトが含まれている可能性があり、addslashes() が単一引用符をエスケープする代わりにマルチバイト文字を作成するという誤解を招く可能性があります。

ベストプラクティス: addslashes()

を超えて

addslashes() は基本的な保護を提供しますが、特にマルチバイト文字セットの場合、SQL インジェクションを防ぐための信頼できるソリューションではありません。 堅牢なセキュリティを実現するには、mysqli_real_escape_string() (MySQLi の場合) などのより高度なテクニック、または理想的にはプリペアド ステートメントを利用します。 プリペアド ステートメントは、SQL インジェクションの脆弱性を防ぐために推奨されるアプローチです。

以上がPHP のaddslashes() は、マルチバイト文字であっても SQL インジェクションに対して本当に安全ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。