SQL インジェクション攻撃を防ぐには「mysql_real_escape_string()」と「mysql_escape_string()」で十分ですか?

mysql_real_escape_string() および mysql_escape_string() のセキュリティ上の懸念

mysql_real_escape_string() および mysql_escape_string() はアプリケーションに適切ですかセキュリティ?

ユーザー入力をサニタイズするためのこれらの関数が普及しているにもかかわらず、SQL 攻撃や潜在的なエクスプロイトに対する保護の限界に関する懸念は依然として残っています。

SQL インジェクションは依然として脅威です:

mysql_real_escape_string() は主に意図されています標準の SQL インジェクションを防止します。ただし、高度なインジェクション技術に対して提供される保護は限定的です。

次のコードを考えてみましょう:

$sql = "SELECT * FROM users WHERE username = '" . mysql_real_escape_string($username) . "'";

攻撃者は、次のようにテーブル名または列名を悪用してインジェクションを実行する可能性があります。

$username = "'); DROP TABLE users; --";

LIKE SQL 攻撃:

LIKE SQLこの関数では注射も脆弱です。たとえば、攻撃者は次の可能性があります。

$data = '%';
$sql = "SELECT * FROM users WHERE username LIKE '" . mysql_real_escape_string($data) . "%'"; # Can retrieve all results

Unicode 文字セットの悪用:

文字セットの悪用により、正しい HTML 設定にもかかわらず、攻撃者に広範な制御が与えられる可能性があります。

LIMIT フィールド悪用:

LIMIT フィールドをエスケープすると、攻撃者が未承認のデータを取得できる可能性もあります:

$sql = "SELECT * FROM users LIMIT '" . mysql_real_escape_string($limit) . "'"; # Can retrieve all results

堅牢な代替手段としての準備されたステートメント:

データベースセキュリティの理想的なソリューションは、プリペアドステートメントの使用です。準備されたステートメントはサーバー側で SQL クエリを実行し、予期しない SQL が実行されるのを防ぎます。次の例を考えてみましょう。

$statement = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$statement->execute(array($username));

プリペアド ステートメントを使用すると、SQL サーバーの保護メカニズムを活用し、既知および未知の悪用から保護されます。

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