Maison > développement back-end > tutoriel php > mysql_real_escape_string() peut-il être contourné ?

mysql_real_escape_string() peut-il être contourné ?

Barbara Streisand
Libérer: 2025-01-04 13:16:40
original
782 Les gens l'ont consulté

Can mysql_real_escape_string() Be Bypassed?

Injection SQL contournant mysql_real_escape_string()

Malgré la croyance largement répandue selon laquelle l'utilisation de mysql_real_escape_string() est suffisante pour empêcher les injections SQL, il existe des scénarios dans lesquels cette défense peut être contournée .

Le vecteur d'attaque

Une de ces attaques implique une combinaison de conditions spécifiques :

  • Utilisation d'un codage de caractères vulnérable (par exemple, gbk, cp932)
  • Définition incorrecte du jeu de caractères de connexion sur le client
  • Exploitation un cas extrême où les caractères multi-octets non valides sont traités comme des octets simples pour s'échapper

Le processus d'attaque

  1. Établissez une connexion à la base de données et définissez le codage de caractères du serveur sur un codage vulnérable (par exemple, « SET NAMES gbk »).
  2. Construisez une charge utile contenant une séquence de caractères multi-octets non valide, ce qui la fera être interprétée à tort comme un seul octet ("xbfx27 OR 1=1 /*').
  3. Utilisez mysql_real_escape_string() pour "échapper" à la charge utile, ce qui insérera de manière incorrecte une barre oblique inverse avant l'apostrophe.
  4. Exécutez une requête SQL en utilisant la charge utile échappée, contournant efficacement la protection prévue.

Vulnérable Scénarios

Cette attaque est particulièrement préoccupante dans les scénarios suivants :

  • Utilisation de versions MySQL antérieures à 4.1.20, 5.0.22 ou 5.1.11
  • Émulation instructions préparées dans les versions PDO avant 5.3.6

Stratégies d'atténuation

Pour atténuer cette vulnérabilité, il est crucial de :

  • Utiliser MySQL versions 5.1 et ultérieures
  • Définissez correctement le jeu de caractères de connexion à l'aide de mysql_set_charset() ou équivalent
  • Désactiver instructions préparées émulées dans les versions PDO antérieures à 5.3.6
  • Envisagez d'utiliser des codages de caractères non vulnérables tels que utf8mb4 ou utf8

Conclusion

Alors que mysql_real_escape_string() propose Protection indispensable contre les injections SQL, elle n'est pas infaillible. Il est crucial de comprendre et d'aborder les mécanismes de contournement potentiels pour garantir la sécurité de vos applications de base de données.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

source:php.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Derniers articles par auteur
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal