L'injection SQL peut-elle contourner `mysql_real_escape_string()` à l'aide de la manipulation des jeux de caractères ?

Injection SQL qui échappe à mysql_real_escape_string()

Malgré son utilisation généralisée, mysql_real_escape_string() n'est pas à l'abri des attaques par injection SQL.

L'attaque

Exigence : La connexion à la base de données doit utiliser un jeu de caractères vulnérable comme big5, cp932, gb2312, gbk ou sjis.

Étapes :

1. Définissez l'encodage :Définissez le serveur encode dans un jeu de caractères vulnérable à l'aide de SET NOMS.
2. Construisez la charge utile : Créez une charge utile qui inclut un caractère multi-octets non valide, par exemple 0xbf27, dans le jeu de caractères vulnérable.
3. Échapper à l'aide de mysql_real_escape_string (): Échapper à la charge utile en utilisant mysql_real_escape_string(), qui insérera une barre oblique inverse avant l'octet initial, c'est-à-dire 0x27.
4. Interrogez la base de données : Utilisez la charge utile échappée dans une requête.

Résultat : En raison de la non-concordance de codage client-serveur, la requête contient un guillemet simple non échappé, ce qui entraîne une requête SQL réussie. injection.

Le laid

Bogue dans mysql_real_escape_string() : Dans les versions antérieures de MySQL, les caractères multi-octets non valides étaient traités comme des octets simples à des fins d'échappement, même si le client était conscient du codage de la connexion.

Vulnérabilité PDO : Déclarations préparées émulées dans Les PDO sont construits à l'aide de mysql_real_escape_string() et sont donc vulnérables à cette attaque.

La grâce salvatrice

Pratiques sûres :

• Utilisez un jeu de caractères non vulnérable comme utf8 ou latin1.
• Définissez correctement le jeu de caractères sur le client et serveur.
• Désactiver les instructions préparées émulées dans PDO.

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!