Le contournement de l'injection SQL peut-il `mysql_real_escape_string ()` en raison de problèmes d'encodage des caractères?

Utiliser des problèmes de codage de caractères pour contourner l'injection SQL de mysql_real_escape_string()

Bien que la fonction mysql_real_escape_string() protège contre l'injection SQL, elle peut être contournée dans certaines circonstances.

Considérez le code PHP suivant :

<code class="language-php">$login = mysql_real_escape_string(GetFromPost('login'));
$password = mysql_real_escape_string(GetFromPost('password'));

$sql = "SELECT * FROM table WHERE login='$login' AND password='$password'";</code>

Ce code semble sûr, mais il peut être exploité en raison de cas extrêmes dans l'encodage des jeux de caractères.

Méthode d'attaque :

L'attaque s'appuie sur les étapes suivantes :

1. Définir le jeu de caractères : Sélectionnez un encodage (par exemple, gbk) où la même séquence d'octets représente à la fois des caractères non-ASCII et une barre oblique inverse ASCII ('').
2. Construction de la charge utile : Utilisez une charge utile soigneusement construite qui contient des caractères multi-octets non valides, en vous assurant que son dernier octet représente une barre oblique inverse ASCII.
3. appelle mysql_real_escape_string() : Le client pense que la connexion utilise un jeu de caractères différent (par exemple, latin1), donc mysql_real_escape_string() insère une barre oblique inverse avant le guillemet simple, ce qui donne une chaîne syntaxiquement valide.
4. Soumettre la requête : La charge utile échappée devient une partie de l'instruction SQL, permettant à l'attaquant de contourner les protections prévues.

Comment ça marche :

Le problème clé est que le jeu de caractères attendu par le serveur ne correspond pas à ce que pense le client. Bien que mysql_real_escape_string() soit échappé en fonction du codage de connexion défini par le client, il traitera les caractères multi-octets non valides comme des octets simples dans certains cas, y compris les cas où SET NAMES est utilisé à la place de mysql_set_charset().

Conséquences :

Cette attaque peut contourner les instructions préparées simulées de PDO même si les instructions préparées simulées sont désactivées.

Remède :

L'utilisation d'un jeu de caractères non vulnérable, tel que utf8mb4 ou utf8, peut atténuer ce problème. L'activation du mode SQL NO_BACKSLASH_ESCAPES fournit également une protection.

Exemple sûr :

Définissez toujours le jeu de caractères correctement en utilisant mysql_set_charset() ou le paramètre de jeu de caractères DSN de PDO. Les véritables instructions préparées dans MySQLi sont également immunisées contre cette attaque.

Conclusion :

Bien que mysql_real_escape_string() offre généralement une protection solide, il est important d'être conscient des cas extrêmes potentiels comme celui-ci pour garantir une protection complète contre l'injection SQL.

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!