Existe-t-il une possibilité d'injection SQL même lors de l'utilisation de la mysql_real_escape_string()fonction?

Considérez cet exemple de situation. SQL est construit en PHP comme ceci:

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

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

J'ai entendu de nombreuses personnes me dire qu'un code comme celui-ci est toujours dangereux et qu'il est possible de pirater même avec la mysql_real_escape_string()fonction utilisée. Mais je ne peux penser à aucun exploit possible?

Injections classiques comme celle-ci:

aaa' OR 1=1 --

ne fonctionnent pas.

Connaissez-vous une injection possible qui passerait par le code PHP ci-dessus?

Considérez la requête suivante:

$iId = mysql_real_escape_string("1 OR 1=1");    
$sSql = "SELECT * FROM table WHERE id = $iId";

mysql_real_escape_string()ne vous protégera pas contre cela. Le fait que vous utilisez des guillemets simples ( ' ') autour de vos variables dans votre requête est ce qui vous protège contre cela. Ce qui suit est également une option:

$iId = (int)"1 OR 1=1";
$sSql = "SELECT * FROM table WHERE id = $iId";

La réponse courte est oui, oui, il existe un moyen de se déplacermysql_real_escape_string() .

Pour les CAS TRÈS OBSCURES !!!

La réponse longue n'est pas si simple. C'est basé sur une attaque démontrée ici .

L'attaque

Commençons donc par montrer l'attaque ...

mysql_query('SET NAMES gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

Dans certaines circonstances, cela renverra plus d'une ligne. Décortiquons ce qui se passe ici:

1. Sélection d'un jeu de caractères

   mysql_query('SET NAMES gbk');

   Pour que cette attaque fonctionne, nous avons besoin du codage que le serveur attend sur la connexion à la fois pour coder 'comme en ASCII ie 0x27 et pour avoir un caractère dont l'octet final est un ASCII \ie 0x5c. Comme il se trouve, il y a 5 ces codages pris en charge par MySQL 5.6 par défaut: big5, cp932, gb2312, gbket sjis. Nous allons sélectionner gbkici.

   Maintenant, il est très important de noter l'utilisation d' SET NAMESici. Cela définit le jeu de caractères SUR LE SERVEUR . Si nous utilisions l'appel à la fonction API C mysql_set_charset(), tout irait bien (sur les versions de MySQL depuis 2006). Mais plus sur pourquoi dans une minute ...

2. La charge utile

   La charge utile que nous allons utiliser pour cette injection commence par la séquence d'octets 0xbf27. Dans gbk, c'est un caractère multi-octets invalide; dans latin1, c'est la chaîne ¿'. Notez que dans latin1 et gbk , 0x27en soi, est un 'caractère littéral .

   Nous avons choisi cette charge utile car, si nous l'appelions addslashes(), nous insérions un ASCII, \c'est 0x5c-à- dire avant le 'caractère. Nous finirions donc avec 0xbf5c27, qui gbkest une séquence de deux caractères: 0xbf5csuivi de 0x27. Ou en d'autres termes, un caractère valide suivi d'un caractère non échappé '. Mais nous n'utilisons pas addslashes(). Passons à l'étape suivante ...

3. mysql_real_escape_string ()

   L'appel de l'API C mysql_real_escape_string()diffère de addslashes()par le fait qu'il connaît le jeu de caractères de connexion. Il peut donc effectuer correctement l'échappement pour le jeu de caractères attendu par le serveur. Cependant, jusqu'à présent, le client pense que nous utilisons toujours latin1la connexion, car nous ne l'avons jamais dit autrement. Nous avons dit au serveur que nous utilisons gbk, mais le client pense toujours que c'est le cas latin1.

   Par conséquent, l'appel à mysql_real_escape_string()insère la barre oblique inverse, et nous avons un 'caractère suspendu gratuit dans notre contenu "échappé"! En fait, si nous regardions $vardans le gbkjeu de caractères, nous verrions:

   縗 'OU 1 = 1 / *

   C'est exactement ce dont l'attaque a besoin.

4. La requête

   Cette partie n'est qu'une formalité, mais voici la requête rendue:

   SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1

Félicitations, vous venez d'attaquer avec succès un programme en utilisant mysql_real_escape_string()...

Le mauvais

Ça s'empire. PDOpar défaut pour émuler des instructions préparées avec MySQL. Cela signifie que du côté client, il effectue essentiellement un sprintf à travers mysql_real_escape_string()(dans la bibliothèque C), ce qui signifie que ce qui suit se traduira par une injection réussie:

$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

Maintenant, il convient de noter que vous pouvez empêcher cela en désactivant les instructions préparées émulées:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Cela se traduira généralement par une véritable instruction préparée (c'est-à-dire que les données sont envoyées dans un paquet distinct de la requête). Cependant, sachez que PDO se repliera silencieusement sur des instructions d'émulation que MySQL ne peut pas préparer nativement: celles qu'il peut sont listées dans le manuel, mais attention à sélectionner la version de serveur appropriée).

Le moche

J'ai dit au tout début que nous aurions pu empêcher tout cela si nous avions utilisé à la mysql_set_charset('gbk')place de SET NAMES gbk. Et c'est vrai à condition d'utiliser une version MySQL depuis 2006.

Si vous utilisez une version de MySQL plus tôt, alors un bogue dans mysql_real_escape_string()signifie que les caractères multi - octets invalides tels que ceux de notre charge utile ont été traités comme les octets pour échapper à des fins même si le client avait été correctement informé de l'encodage de connexion et donc cette attaque serait réussir encore. Le bogue a été corrigé dans MySQL 4.1.20 , 5.0.22 et 5.1.11 .

Mais le pire, c'est que PDOl'API C n'a pas été mysql_set_charset()exposée avant la 5.3.6, donc dans les versions précédentes, elle ne peut pas empêcher cette attaque pour chaque commande possible! Il est maintenant exposé en tant que paramètre DSN .

La grâce salvatrice

Comme nous l'avons dit au début, pour que cette attaque fonctionne, la connexion à la base de données doit être codée à l'aide d'un jeu de caractères vulnérable. utf8mb4n'est pas vulnérable et peut néanmoins prendre en charge tous les caractères Unicode: vous pouvez donc choisir de l'utiliser à la place, mais il n'est disponible que depuis MySQL 5.5.3. Une alternative est utf8, qui n'est pas non plus vulnérable et peut prendre en charge l'ensemble du plan multilingue de base Unicode .

Alternativement, vous pouvez activer le NO_BACKSLASH_ESCAPESmode SQL, qui (entre autres) modifie le fonctionnement de mysql_real_escape_string(). Avec ce mode activé, 0x27sera remplacé par 0x2727plutôt que 0x5c27et donc le processus d'échappement ne peut pas créer de caractères valides dans aucun des encodages vulnérables où ils n'existaient pas auparavant (c'est 0xbf27-à- dire est toujours 0xbf27etc.) - donc le serveur rejettera toujours la chaîne comme invalide . Cependant, voir la réponse de @ eggyal pour une vulnérabilité différente qui peut résulter de l'utilisation de ce mode SQL.

Exemples sûrs

Les exemples suivants sont sûrs:

mysql_query('SET NAMES utf8');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

Parce que le serveur attend utf8...

mysql_set_charset('gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

Parce que nous avons correctement défini le jeu de caractères afin que le client et le serveur correspondent.

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

Parce que nous avons désactivé les instructions préparées émulées.

$pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=gbk', $user, $password);
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

Parce que nous avons correctement défini le jeu de caractères.

$mysqli->query('SET NAMES gbk');
$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "\xbf\x27 OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

Parce que MySQLi fait tout le temps de véritables instructions préparées.

Emballer

Si vous:

• Utiliser les versions modernes de MySQL (fin 5.1, tous 5.5, 5.6, etc.) ET mysql_set_charset() / $mysqli->set_charset()/ PDO paramètre de jeu de caractères DSN (en PHP ≥ 5.3.6)

OU

• N'utilisez pas de jeu de caractères vulnérable pour le codage de connexion (vous utilisez uniquement utf8/ latin1/ ascii/ etc)

Vous êtes sûr à 100%.

Sinon, vous êtes vulnérable même si vous utilisezmysql_real_escape_string() ...

TL; DR

mysql_real_escape_string() volonté fournira aucune protection (et pourrait en outre communiquer vos données) si:

• Le NO_BACKSLASH_ESCAPESmode SQL de MySQL est activé (ce qui pourrait être le cas, sauf si vous sélectionnez explicitement un autre mode SQL à chaque connexion ); et

• vos littéraux de chaîne SQL sont indiqués entre guillemets ".

Cela a été classé comme bug # 72458 et a été corrigé dans MySQL v5.7.6 (voir la section intitulée " La grâce qui sauve ", ci-dessous).

Ceci est un autre, (peut-être moins?) CAS DE BORD obscur !!!

En hommage à l'excellente réponse @ ircmaxell (vraiment, c'est censé être de la flatterie et non du plagiat!), J'adopterai son format:

L'attaque

Commençant par une démonstration ...

mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"'); // could already be set
$var = mysql_real_escape_string('" OR 1=1 -- ');
mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

Cela renverra tous les enregistrements de la testtable. Une dissection:

1. Sélection d'un mode SQL

   mysql_query('SET SQL_MODE="NO_BACKSLASH_ESCAPES"');

   Comme documenté sous String Literals :

   Il existe plusieurs façons d'inclure des guillemets dans une chaîne:

   • Un « '» à l'intérieur d'une chaîne entre guillemets « '» peut s'écrire « ''».

   • Un « "» à l'intérieur d'une chaîne entre guillemets « "» peut s'écrire « ""».

   • Faites précéder le caractère de citation d'un caractère d'échappement (« \»).

   • Un " '" à l'intérieur d'une chaîne entre guillemets " "" ne nécessite aucun traitement spécial et n'a pas besoin d'être doublé ou échappé. De la même manière, " "" à l'intérieur d'une chaîne entre guillemets " '" ne nécessite aucun traitement spécial.

   Si le mode SQL du serveur inclut NO_BACKSLASH_ESCAPES, alors la troisième de ces options - qui est l'approche habituelle adoptée par mysql_real_escape_string()- n'est pas disponible: l'une des deux premières options doit être utilisée à la place. Notez que l'effet de la quatrième puce est que l'on doit nécessairement connaître le caractère qui sera utilisé pour citer le littéral afin d'éviter de fusionner ses données.

2. La charge utile

   " OR 1=1 -- 

   La charge utile lance cette injection littéralement avec le "personnage. Pas d'encodage particulier. Pas de caractères spéciaux. Pas d'octets bizarres.

3. mysql_real_escape_string ()

   $var = mysql_real_escape_string('" OR 1=1 -- ');

   Heureusement, mysql_real_escape_string()vérifie le mode SQL et ajuste son comportement en conséquence. Voir libmysql.c:

   ulong STDCALL
   mysql_real_escape_string(MYSQL *mysql, char *to,const char *from,
                ulong length)
   {
     if (mysql->server_status & SERVER_STATUS_NO_BACKSLASH_ESCAPES)
       return escape_quotes_for_mysql(mysql->charset, to, 0, from, length);
     return escape_string_for_mysql(mysql->charset, to, 0, from, length);
   }

   Ainsi, une fonction sous-jacente différente,, escape_quotes_for_mysql()est invoquée si le NO_BACKSLASH_ESCAPESmode SQL est utilisé. Comme mentionné ci-dessus, une telle fonction doit savoir quel caractère sera utilisé pour citer le littéral afin de le répéter sans provoquer la répétition littérale de l'autre caractère de citation.

   Cependant, cette fonction suppose arbitrairement que la chaîne sera citée en utilisant le 'caractère guillemet simple . Voir charset.c:

   /*
     Escape apostrophes by doubling them up
   
   // [ deletia 839-845 ]
   
     DESCRIPTION
       This escapes the contents of a string by doubling up any apostrophes that
       it contains. This is used when the NO_BACKSLASH_ESCAPES SQL_MODE is in
       effect on the server.
   
   // [ deletia 852-858 ]
   */
   
   size_t escape_quotes_for_mysql(CHARSET_INFO *charset_info,
                                  char *to, size_t to_length,
                                  const char *from, size_t length)
   {
   // [ deletia 865-892 ]
   
       if (*from == '\'')
       {
         if (to + 2 > to_end)
         {
           overflow= TRUE;
           break;
         }
         *to++= '\'';
         *to++= '\'';
       }

   Ainsi, il laisse les "caractères entre guillemets intacts (et double tous les 'caractères entre guillemets ) quel que soit le caractère réel utilisé pour citer le littéral ! Dans notre cas, il $varreste exactement le même que l'argument qui a été fourni à mysql_real_escape_string()- c'est comme si aucune fuite n'avait eu lieu du tout .

4. La requête

   mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

   Quelque chose d'une formalité, la requête rendue est:

   SELECT * FROM test WHERE name = "" OR 1=1 -- " LIMIT 1

Comme l'a dit mon confrère: félicitations, vous venez d'attaquer avec succès un programme en utilisant mysql_real_escape_string()...

Le mauvais

mysql_set_charset()ne peut pas aider, car cela n'a rien à voir avec les jeux de caractères; pas plus mysqli::real_escape_string(), car c'est juste un wrapper différent autour de cette même fonction.

Le problème, s'il n'est pas déjà évident, est que l'appel à mysql_real_escape_string() ne peut pas savoir avec quel caractère le littéral sera cité, car il appartient au développeur de décider plus tard. Donc, en NO_BACKSLASH_ESCAPESmode, il n'y a littéralement aucun moyen que cette fonction puisse échapper en toute sécurité à chaque entrée pour une utilisation avec des guillemets arbitraires (au moins, non sans doubler les caractères qui ne nécessitent pas de doubler et donc de fusionner vos données).

Le moche

Ça s'empire. NO_BACKSLASH_ESCAPESpeut ne pas être si rare dans la nature en raison de la nécessité de son utilisation pour la compatibilité avec le SQL standard (par exemple, voir la section 5.3 de la spécification SQL-92 , à savoir la <quote symbol> ::= <quote><quote>production de grammaire et le manque de signification particulière donnée à la barre oblique inverse). De plus, son utilisation a été explicitement recommandée comme solution de contournement au bogue (corrigé depuis longtemps) décrit par la publication d'ircmaxell. Qui sait, certains administrateurs de base de données peuvent même le configurer pour qu'il soit activé par défaut afin de décourager l'utilisation de méthodes d'échappement incorrectes comme addslashes().

De plus, le mode SQL d'une nouvelle connexion est défini par le serveur en fonction de sa configuration (qu'un SUPERutilisateur peut modifier à tout moment); ainsi, pour être certain du comportement du serveur, vous devez toujours spécifier explicitement le mode souhaité après la connexion.

La grâce salvatrice

Tant que vous définissez toujours explicitement le mode SQL pour qu'il n'inclue pas NO_BACKSLASH_ESCAPESou ne cite pas les littéraux de chaîne MySQL en utilisant le caractère guillemet simple, ce bogue ne peut pas escape_quotes_for_mysql()afficher sa tête laide: respectivement , ne sera pas utilisé, ou son hypothèse sur les caractères guillemet nécessitant une répétition sera être correct.

Pour cette raison, je recommande que toute personne utilisant NO_BACKSLASH_ESCAPESégalement active le ANSI_QUOTESmode, car cela forcera l'utilisation habituelle des littéraux de chaîne entre guillemets simples. Notez que cela n'empêche pas l'injection SQL dans le cas où des littéraux entre guillemets sont utilisés - cela réduit simplement la probabilité que cela se produise (car les requêtes normales et non malveillantes échoueraient).

Dans PDO, sa fonction équivalente PDO::quote()et son émulateur d'instructions préparé font appel à mysql_handle_quoter()- ce qui fait exactement cela: il garantit que le littéral échappé est cité entre guillemets simples, de sorte que vous pouvez être certain que PDO est toujours à l'abri de ce bogue.

Depuis MySQL v5.7.6, ce bug a été corrigé. Voir le journal des modifications :

Fonctionnalité ajoutée ou modifiée

• Changement incompatible: une nouvelle fonction API C,,mysql_real_escape_string_quote()a été implémentée en remplacementmysql_real_escape_string()car cette dernière fonction peut échouer à coder correctement les caractères lorsque leNO_BACKSLASH_ESCAPESmode SQL est activé. Dans ce cas,mysql_real_escape_string()ne peut pas échapper les caractères de citation, sauf en les doublant, et pour le faire correctement, il doit connaître plus d'informations sur le contexte de citation que celles disponibles. mysql_real_escape_string_quote()prend un argument supplémentaire pour spécifier le contexte de citation. Pour les détails d'utilisation, voir mysql_real_escape_string_quote () .

   Remarque

  Les applications doivent être modifiées pour utiliser mysql_real_escape_string_quote(), au lieu de mysql_real_escape_string(), ce qui échoue maintenant et produit une CR_INSECURE_API_ERRerreur si NO_BACKSLASH_ESCAPESest activé.

  Références: Voir aussi bogue n ° 19211994.

Exemples sûrs

Pris ensemble avec le bogue expliqué par ircmaxell, les exemples suivants sont entièrement sûrs (en supposant que l'on utilise MySQL plus tard que 4.1.20, 5.0.22, 5.1.11; ou que l'on n'utilise pas un codage de connexion GBK / Big5) :

mysql_set_charset($charset);
mysql_query("SET SQL_MODE=''");
$var = mysql_real_escape_string('" OR 1=1 /*');
mysql_query('SELECT * FROM test WHERE name = "'.$var.'" LIMIT 1');

... car nous avons explicitement sélectionné un mode SQL qui ne comprend pas NO_BACKSLASH_ESCAPES.

mysql_set_charset($charset);
$var = mysql_real_escape_string("' OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

... parce que nous citons notre chaîne littérale avec des guillemets simples.

$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(["' OR 1=1 /*"]);

... parce que les instructions préparées par PDO sont immunisées contre cette vulnérabilité (et ircmaxell aussi, à condition que vous utilisiez PHP ≥5.3.6 et que le jeu de caractères ait été correctement défini dans le DSN; ou que l'émulation des instructions préparées ait été désactivée) .

$var  = $pdo->quote("' OR 1=1 /*");
$stmt = $pdo->query("SELECT * FROM test WHERE name = $var LIMIT 1");

... parce que la quote()fonction de PDO échappe non seulement au littéral, mais le cite également (en guillemets simples '); notez que pour éviter le bogue d'ircmaxell dans ce cas, vous devez utiliser PHP≥5.3.6 et avoir correctement défini le jeu de caractères dans le DSN.

$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "' OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

... car les instructions préparées par MySQLi sont sûres.

Emballer

Ainsi, si vous:

• utiliser des instructions natives préparées

OU

• utiliser MySQL v5.7.6 ou version ultérieure

OU

• en plus d'utiliser l'une des solutions du résumé d'ircmaxell, utilisez au moins l'une des solutions suivantes:

  • AOP;
  • littéraux de chaîne entre guillemets simples; ou
  • un mode SQL défini explicitement qui n'inclut pas NO_BACKSLASH_ESCAPES

... alors vous devriez être complètement en sécurité (vulnérabilités en dehors de la portée de la chaîne s'échappant).

Eh bien, il n'y a vraiment rien qui puisse passer par là, à part le %caractère générique. Il pourrait être dangereux si vous utilisiez une LIKEinstruction car l'attaquant pourrait utiliser la même %connexion si vous ne filtrez pas cela et devrait simplement forcer le mot de passe de l'un de vos utilisateurs. Les gens suggèrent souvent d'utiliser des instructions préparées pour le rendre sûr à 100%, car les données ne peuvent pas interférer avec la requête elle-même de cette façon. Mais pour des requêtes aussi simples, il serait probablement plus efficace de faire quelque chose comme$login = preg_replace('/[^a-zA-Z0-9_]/', '', $login);