PHP の addslashes() は依然として SQL インジェクションの脆弱性を引き起こす可能性がありますか?

PHP のaddlashes() による SQL インジェクション悪用

PHP のaddlashes() 関数は、次の点に関しては mysql_real_escape よりも安全性が低いことが知られています。 SQL インジェクションの脆弱性を防止します。 addslashes() はその制限についてしばしば批判されますが、どのように攻撃が成功するかを理解することが重要です。

シナリオ例

サニタイズを試みる次のコードを考えてみましょう。ユーザー入力:

$input = addslashes($_GET['input']);
$query = "SELECT * FROM users WHERE username='$input'";

このコードの問題は、addslashes() がマルチバイト文字を正しく処理します。攻撃者がバックスラッシュ () 文字で終わるマルチバイト文字を含むユーザー名を指定した場合、addslashes() はシーケンスの途中にバックスラッシュを挿入し、その有効性を破壊します。これにより、次の一重引用符をエスケープするのではなく、SQL クエリ内でバックスラッシュがエスケープ文字として解釈される可能性があります。

この脆弱性を悪用する可能性のある悪意のある入力の例は次のとおりです。

%E4%B8%80' OR 1=1 --

addslashes() はこれを次のように変換します:

%E4%B8%80\' OR 1=1 --

エスケープされたバックスラッシュ () は、マルチバイト シーケンスにより、攻撃者が任意の SQL コマンドを実行できるようになります (この場合、認証をバイパスします)。

一般的な警告

この脆弱性は、addslashes() が次のような可能性があるために発生します。後続の一重引用符文字をエスケープするのではなく、有効なマルチバイト文字を作成するように騙されます。これは、使用されている文字エンコーディングに 0x5c (バックスラッシュ文字の 16 進コード) で終わる有効なマルチバイト文字が含まれている場合に発生します。 UTF-8 はこの条件を満たしていませんが、Latin1 などの他のエンコーディングは満たしています。したがって、入力サニタイズにaddslashes()を使用する場合は、この潜在的な脆弱性を認識し、mysql_real_escape.

のようなより堅牢な代替手段の使用を検討することが重要です。

以上がPHP の addslashes() は依然として SQL インジェクションの脆弱性を引き起こす可能性がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。