`mysql_real_escape_string()` est-il vraiment sécurisé contre l'injection SQL, ou existe-t-il des vulnérabilités subtiles ?

Mysql_real_escape_string() est-il parfait ?

Bien qu'il soit couramment utilisé pour se protéger contre les attaques par injection SQL, mysql_real_escape_string() peut être contourné, bien que dans des cas rares et complexes.

L'attaque ingénieuse

Avec un soin attentif charge utile spécialement conçue dans un jeu de caractères très spécifique, mysql_real_escape_string() peut être exploitée. Voici une répartition :

1. Sélection du jeu de caractères : Le jeu de caractères de connexion du serveur doit être défini sur un jeu prenant en charge à la fois une barre oblique inverse ASCII ('') et un caractère dont le dernier octet est un ASCII'. Par exemple, 'gbk' remplit ce critère.
2. Payload : Une charge utile composée de la séquence d'octets '0xbf27' est choisie. Dans 'gbk', c'est un caractère invalide, tandis que dans 'latin1', il représente '¿''.
3. mysql_real_escape_string() : L'implémentation de cette fonction par MySQL reconnaît le jeu de caractères de connexion ( dans ce cas, 'gbk') et applique l'échappement selon ses règles. Cependant, le client pense toujours que la connexion utilise « latin1 ». Par conséquent, lorsqu'il échappe à la séquence d'octets avec 'mysql_real_escape_string()', il insère une barre oblique inverse.
4. La requête : La chaîne résultante contient un caractère ' suspendu : '縗' OU 1=1 /*' dans 'gbk'. Il s'agit de la charge utile malveillante nécessaire à l'attaque.

Les vulnérabilités flagrantes

1. Déclarations émulées PDO :PDO, par défaut, émule les instructions préparées en utilisant mysql_real_escape_string(), le rendant vulnérable à cela attaque.
2. mysql_real_escape_string() Bug : Avant MySQL 4.1.20 et 5.0.22, mysql_real_escape_string() avait un bug qui traitait les caractères multi-octets non valides comme des octets simples, même si le client était informé du bon encodage de connexion, permettant à cette attaque de réussir.
3. PDO Sauvegardes limitées : Le paramètre de jeu de caractères DSN de PDO, introduit dans PHP ≥ 5.3.6, n'est pas systématiquement pris en charge pour toutes les commandes. Cela laisse place à l'exploitabilité.

Dissiper les ombres

1. Jeux de caractères sécurisés : L'utilisation de jeux de caractères invulnérables comme « utf8 » ou « utf8mb4 » atténue cette attaque.
2. NO_BACKSLASH_ESCAPES SQL Mode : L'activation de ce mode modifie le fonctionnement de mysql_real_escape_string(), empêchant la création de caractères valides dans les encodages vulnérables.
3. Versions MySQL modernes et instructions préparées : Versions MySQL 5.1 (tardives) , 5.5 et versions ultérieures, ainsi que les véritables instructions préparées (par exemple, dans MySQLi), sont immunisés contre cela. exploit.

En conclusion, bien que mysql_real_escape_string() soit généralement efficace, il peut être contourné dans des scénarios spécifiques. Les versions modernes de MySQL, une sélection de jeux de caractères appropriée et de véritables instructions préparées garantissent une protection complète contre cette attaque complexe.

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!