Quelle est la différence entre les addslashes de PHP et MySQL (i) _escape_string? [dupliquer]

Question

  

Possible en double:    mysql_real_escape_string VS addslashes

S'ils ne le font pas exactement les mêmes, quelle est la différence? Le séparateur pour les valeurs dans une requête MySQL est le ' est pas? Ou peut-être le " mais qui est aussi échappé avec addslashes.

Dans d'autres moteurs de base de données que je comprends (et certainement à l'intérieur d'une enveloppe db comme AOP), mais pourquoi tant de gens si adament sur l'utilisation de MySQL (i) _escape_string au lieu de addslashes?

Answer 1

Tout d'abord: ne pas utiliser mysql_escape_string, il est dépréciée (pour une raison)

Si vous devez soutenir une application héritée qui se connecte à la base de données à travers l'extension mysql (qui a été désapprouvée), utilisez mysql_real_escape_string à la place. interrupteur Sinon immédiatement à mysqli, où les déclarations préparées et des paramètres liés fournir un mécanisme plus robuste pour échapper à l'entrée d'utilisateur.

Cela dit, la réponse peut être trouvée en lisant la description de mysql_real_escape_string et href="http://php.net/manual/en/function.addslashes.php" rel="nofollow noreferrer"> addslashes :

Différence # 1

addslashes ne sait rien au sujet de codages de connexion MySql. Si vous passez une chaîne contenant octets représentant un codage autre que le codage utilisé par la connexion MySql, il échappera heureusement tous les octets ayant les valeurs des caractères ', ", \ et \x00. Cela peut ne pas être le même que tous les caractères ', ", \ et \x00 si vous utilisez un codage autre que codages 8 bits et UTF-8. Le résultat sera que la chaîne reçue par MySql sera corrompu.

Pour déclencher ce bug, essayez d'utiliser iconv pour convertir votre variable UTF-16 puis échapper avec addslashes. Voyez ce que votre base de données reçoit.

Ceci est une raison pour laquelle addslashes ne doit pas être utilisé pour échapper.

Différence # 2

Contrairement à addslashes, mysql_real_escape_string échappe aussi des personnages \r, \n et \x1a. Il semble que ces caractères doivent être échappés aussi bien quand on parle à MySql, sinon une requête malformée peut être le résultat

Ceci est l'autre raison pour laquelle addslashes ne doit pas être utilisé pour échapper.

Answer 2

Chris Shiflett montre un monde réel cas où SQL à l'aide addslashes() échapper échoue, et mysql_real_escape_string() est le seul chemin à parcourir.

  

Comment cette aide? Si je veux   tenter une attaque par injection SQL   contre une base de données MySQL, comportant   guillemets simples se sont échappés avec une barre oblique inverse   est une vraie corvée. Si vous utilisez   addslashes (), cependant, je suis de la chance.   Tout ce que je besoin de faire est quelque chose inject   comme 0xbf27 et addslashes () modifie   cela devienne 0xbf5c27, valide   caractère multi-octet suivi d'un   simple citation. En d'autres termes, je peux   avec succès inject une seule citation   malgré votre Évasion. C'est parce que   0xbf5c est interprété comme un seul   caractère, pas deux. Oops, il va   la barre oblique inverse.

     

....

     

En dépit de l'utilisation de addslashes (), je suis en mesure de se connecter avec succès sans connaître un nom d'utilisateur valide ou mot de passe. Je peux simplement exploiter la vulnérabilité d'injection SQL.

     

Pour éviter ce type de vulnérabilité, l'utilisation mysql_real_escape_string (), des déclarations préparées, ou l'une des plus grandes bibliothèques d'abstraction de base de données.

c'est certes un cas limite rare, mais une démonstration de pourquoi les gens sont si catégoriques sur l'utilisation des fonctions d'échappement spécifiques de la base de données. Seule la bibliothèque de base de données peut savoir avec certitude quel genre de fuite est nécessaire. , emballages différents jeux de caractères et de saveurs SQL (comme serveur MS SQL) ont besoin de différents Escaping. Ignorant ce fait est la façon dont les vulnérabilités sont nés.

Answer 3

Ils sont identiques que vous devez utiliser aucun d'eux, parce que vous devez utiliser des espaces réservés plutôt que de construire SQL à partir des données non fiables.

Voir http://bobby-tables.com/php.html pour savoir comment faire la bonne façon.

Answer 4

Il est avant tout un problème de charset. Qu'est-ce que addslashes() ne serait suffisant pour échapper à des données entremêlés avec des commandes SQL, si les données ont été purement ASCII . Mais en plus UTF-8 variations codant, MySQL dans une certaine configuration permet également de jeux de caractères sociaux comme UCS2 (UTF-16) ou GB / chinois Big5 | charsets. Là, il est insuffisant pour échapper à tout le code ascii brut de ' en \'. Et puis le chemin de MySQL d'échapper à des chaînes n'a jamais été très beaucoup SQL-conformes aux standards pour commencer. Il pourrait être dépréciée dans les prochaines versions du serveur MySQL.