Utilisez un problème d'encodage de caractères pour contourner l'injection SQL de mysql_real_escape_string ()

Bien que la fonction mysql_real_escape_string () empêche l'injection SQL, elle peut être contournée dans certains cas.

Considérez le code PHP suivant:

$login = mysql_real_escape_string(GetFromPost('login'));
$password = mysql_real_escape_string(GetFromPost('password'));

$sql = "SELECT * FROM table WHERE login='$login' AND password='$password'";

Ce code semble sûr, mais il peut être exploité en raison du cas de bord de codage des jeux de caractères.

Méthode d'attaque:

Les attaques dépendent des étapes suivantes:

1. Définir le jeu de caractères: Sélectionnez un encodage (par exemple, GBK) où la même séquence d'octet représente à la fois les caractères non ASCII et les backslash ASCII ('\').
2. Construisez la charge utile: Utilisez une charge utile soigneusement construite qui contient des caractères multipyte non valides, garantissant que son dernier octet représente une barre oblique inverse ASCII.
3. appel mysql_real_escape_string () : Le client croit que la connexion utilise un jeu de caractères différent (par exemple, latin1), donc mysql_real_escape_string () sera un seul seul Insérez une barre oblique inverse avant les citations, résultant en une chaîne syntaxiquement valide.
4. soumettre query: la charge utile échappée fait partie de l'instruction SQL, permettant à l'attaquant de contourner la protection attendue.

principe de travail:

Le problème clé est que le jeu de caractères attendu par le serveur ne correspond pas au jeu de caractères considéré par le client. Bien que mysql_real_escape_string () soit échappé en fonction du codage de connexion défini par le client, dans certains cas, il traite les caractères multipyte non valides comme un seul octet, y compris l'utilisation de définir des noms au lieu de MySQL_SET_CHARSET () cas.

en conséquence de:

Cette attaque peut contourner l'instruction de prétraitement simulée de PDO, même si l'instruction de prétraitement simulé est désactivée.

Remède:

Utilisez des jeux de caractères non vulnérables, tels que UTF8MB4 ou UTF8, pour atténuer ce problème. Activer NO_BACKSLASH_ESCAPES Le mode SQL offre également une protection.

Exemple sûr:

Définissez toujours le jeu de caractères correctement en utilisant mysql_set_charset () ou les paramètres de définition de caractères DSN de PDO. De vraies déclarations de prétraitement dans MySQLI sont également à l'abri de cette attaque.

en conclusion:

Bien que mysql_real_escape_string () offre généralement une protection forte, il est important d'être conscient de ces cas de bord potentiels pour assurer une défense complète contre l'injection SQL.