¿Existe una posibilidad de inyección de SQL incluso cuando se utiliza la mysql_real_escape_string()función?

Considere esta situación de muestra. SQL se construye en PHP así:

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

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

He escuchado a muchas personas decirme que un código como ese sigue siendo peligroso y posible piratear incluso con la mysql_real_escape_string()función utilizada. ¿Pero no puedo pensar en ninguna posible hazaña?

Inyecciones clásicas como esta:

aaa' OR 1=1 --

No funcionan.

¿Conoces alguna posible inyección que atraviese el código PHP anterior?

Considere la siguiente consulta:

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

mysql_real_escape_string()no te protegerá contra esto. El hecho de que use comillas simples ( ' ') alrededor de sus variables dentro de su consulta es lo que lo protege contra esto. Lo siguiente también es una opción:

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

La respuesta corta es sí, sí, hay una manera de moversemysql_real_escape_string() .

¡¡¡PARA CASOS DE BORDES MUY OCULARES

La respuesta larga no es tan fácil. Se basa en un ataque demostrado aquí .

El ataque

Entonces, comencemos mostrando el ataque ...

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");

En ciertas circunstancias, eso devolverá más de 1 fila. Analicemos lo que está sucediendo aquí:

1. Seleccionar un conjunto de caracteres

   mysql_query('SET NAMES gbk');

   Para que este ataque funcione, necesitamos la codificación que el servidor espera en la conexión tanto para codificar 'como en ASCII, es decir, 0x27 como para tener algún carácter cuyo byte final sea un ASCII, \es decir 0x5c. Como resultado, hay 5 dichas codificaciones soportadas en MySQL 5.6 por defecto: big5, cp932, gb2312, gbky sjis. Seleccionaremos gbkaquí.

   Ahora, es muy importante tener en cuenta el uso de SET NAMESaquí. Esto establece el conjunto de caracteres EN EL SERVIDOR . Si usáramos la llamada a la función C API mysql_set_charset(), estaríamos bien (en versiones de MySQL desde 2006). Pero más sobre por qué en un minuto ...

2. La carga útil

   La carga útil que vamos a utilizar para esta inyección comienza con la secuencia de bytes 0xbf27. En gbk, ese es un carácter multibyte no válido; adentro latin1, es la cuerda ¿'. Tenga en cuenta que en latin1 y gbk , 0x27por sí solo es un 'carácter literal .

   Hemos elegido esta carga útil porque, si la solicitamos addslashes(), insertaríamos un ASCII , \es decir 0x5c, antes del 'carácter. Así que terminaríamos con 0xbf5c27, que gbkes una secuencia de dos caracteres: 0xbf5cseguida de 0x27. O, en otras palabras, un carácter válido seguido de un no escapado '. Pero no estamos usando addslashes(). Entonces, al siguiente paso ...

3. mysql_real_escape_string ()

   La llamada a la API C mysql_real_escape_string()difiere addslashes()en que conoce el conjunto de caracteres de conexión. Por lo tanto, puede realizar el escape correctamente para el juego de caracteres que el servidor espera. Sin embargo, hasta este punto, el cliente piensa que todavía estamos usando latin1la conexión, porque nunca le dijimos lo contrario. Le dijimos al servidor que estamos usando gbk, pero el cliente todavía piensa que es así latin1.

   Por lo tanto, la llamada a mysql_real_escape_string()insertar la barra diagonal inversa, ¡y tenemos un 'personaje que cuelga libremente en nuestro contenido "escapado"! De hecho, si tuviéramos que mirar $varen el gbkconjunto de caracteres, veríamos:

   OR 'OR 1 = 1 / *

   Que es exactamente lo que requiere el ataque.

4. La consulta

   Esta parte es solo una formalidad, pero aquí está la consulta representada:

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

Felicitaciones, acabas de atacar con éxito un programa usando mysql_real_escape_string()...

El malo

Se pone peor. PDOel valor predeterminado es emular declaraciones preparadas con MySQL. Eso significa que en el lado del cliente, básicamente realiza un sprintf mysql_real_escape_string()(en la biblioteca C), lo que significa que lo siguiente dará como resultado una inyección exitosa:

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

Ahora, vale la pena señalar que puede evitar esto deshabilitando las declaraciones preparadas emuladas:

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

Esto generalmente dará como resultado una declaración preparada verdadera (es decir, los datos que se envían en un paquete separado de la consulta). Sin embargo, tenga en cuenta que DOP silenciosamente repliegue a emular las declaraciones que MySQL no puede preparar de forma nativa: los que puede se enumeran en el manual, pero cuidado para seleccionar la versión del servidor apropiado).

El feo

Al principio dije que podríamos haber evitado todo esto si hubiéramos usado en mysql_set_charset('gbk')lugar de SET NAMES gbk. Y eso es cierto siempre que esté utilizando una versión de MySQL desde 2006.

Si está utilizando una versión de MySQL anterior, a continuación, un fallo en mysql_real_escape_string()significaban que los caracteres de varios bytes no válidos como los de nuestra carga útil fueron tratados como bytes individuales para escapar de los propósitos , incluso si el cliente había sido informado correctamente de la codificación de la conexión y por lo que este ataque sería Todavía tener éxito. El error se corrigió en MySQL 4.1.20 , 5.0.22 y 5.1.11 .

Pero la peor parte es que PDOno expuso la API de C mysql_set_charset()hasta 5.3.6, por lo que en versiones anteriores no puede evitar este ataque para cada comando posible. Ahora está expuesto como un parámetro DSN .

La gracia salvadora

Como dijimos al principio, para que este ataque funcione, la conexión de la base de datos debe codificarse utilizando un conjunto de caracteres vulnerable. noutf8mb4 es vulnerable y, sin embargo, puede admitir todos los caracteres Unicode: por lo que puede optar por usarlo en su lugar, pero solo ha estado disponible desde MySQL 5.5.3. Una alternativa es utf8, que tampoco es vulnerable y puede soportar todo el plano multilingüe básico de Unicode .

Alternativamente, puede habilitar el NO_BACKSLASH_ESCAPESmodo SQL, que (entre otras cosas) altera el funcionamiento de mysql_real_escape_string(). Con este modo habilitado, 0x27será reemplazado por 0x2727algo en lugar de 0x5c27y, por lo tanto, el proceso de escape no puede crear caracteres válidos en ninguna de las codificaciones vulnerables donde no existían anteriormente ( 0xbf27es decir, todavía es 0xbf27etc.), por lo que el servidor seguirá rechazando la cadena como no válida . Sin embargo, vea la respuesta de @ eggyal para una vulnerabilidad diferente que puede surgir del uso de este modo SQL.

Ejemplos seguros

Los siguientes ejemplos son seguros:

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");

Porque el servidor espera 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");

Porque hemos configurado correctamente el juego de caracteres para que el cliente y el servidor coincidan.

$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 /*"));

Porque hemos desactivado las declaraciones preparadas emuladas.

$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 /*"));

Porque hemos establecido el conjunto de caracteres correctamente.

$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();

Porque MySQLi hace verdaderas declaraciones preparadas todo el tiempo.

Terminando

Si tu:

• Utilice versiones modernas de MySQL (finales de 5.1, todas 5.5, 5.6, etc.) Y mysql_set_charset() / $mysqli->set_charset()/ Parámetro de conjunto de caracteres DSN de PDO (en PHP ≥ 5.3.6)

O

• No use un juego de caracteres vulnerable para la codificación de conexión (solo usa utf8/ latin1/ ascii/ etc.)

Estás 100% seguro.

De lo contrario, eres vulnerable aunque estés usandomysql_real_escape_string() ...

TL; DR

mysql_real_escape_string()no proporcionará protección de ningún tipo (y además podría bloquear sus datos) si:

• El NO_BACKSLASH_ESCAPESmodo SQL de MySQL está habilitado (que podría estarlo, a menos que seleccione explícitamente otro modo SQL cada vez que se conecte ); y

• sus literales de cadena SQL se citan con comillas dobles ".

Esto se archivó como error n. ° 72458 y se ha corregido en MySQL v5.7.6 (consulte la sección titulada " The Saving Grace ", a continuación).

Este es otro, ¿quizás menos?

En homenaje a la excelente respuesta de @ircmaxell (en realidad, ¡se supone que esto es adulación y no plagio!), Adoptaré su formato:

El ataque

Comenzando con una demostración ...

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');

Esto devolverá todos los registros de la testtabla. Una disección:

1. Seleccionar un modo SQL

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

   Como se documenta en String Literals :

   Hay varias formas de incluir comillas dentro de una cadena:

   • Un " '" dentro de una cadena entre comillas con " '" puede escribirse como " ''".

   • Un " "" dentro de una cadena entre comillas con " "" puede escribirse como " """.

   • Preceda el carácter de comillas por un carácter de escape (" \").

   • Un " '" dentro de una cadena entre comillas con " "" no necesita ningún tratamiento especial y no necesita duplicarse o escapar. Del mismo modo, " "" dentro de una cadena entre comillas con " '" no necesita ningún tratamiento especial.

   Si el modo SQL del servidor incluye NO_BACKSLASH_ESCAPES, entonces la tercera de estas opciones, que es el enfoque habitual adoptado por, mysql_real_escape_string()no está disponible: una de las dos primeras opciones debe usarse en su lugar. Tenga en cuenta que el efecto de la cuarta viñeta es que uno debe conocer necesariamente el carácter que se utilizará para citar el literal para evitar mezclar los datos.

2. La carga útil

   " OR 1=1 -- 

   La carga útil inicia esta inyección literalmente con el "personaje. Sin codificación particular. No hay caracteres especiales. No hay bytes extraños.

3. mysql_real_escape_string ()

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

   Afortunadamente, mysql_real_escape_string()verifica el modo SQL y ajusta su comportamiento en consecuencia. Ver 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);
   }

   Por lo tanto escape_quotes_for_mysql(), se invoca una función subyacente diferente, si el NO_BACKSLASH_ESCAPESmodo SQL está en uso. Como se mencionó anteriormente, dicha función necesita saber qué carácter se usará para citar el literal para repetirlo sin hacer que el otro carácter de cita se repita literalmente.

   Sin embargo, esta función supone arbitrariamente que la cadena se citará utilizando el 'carácter de comillas simples . Ver 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++= '\'';
       }

   Por lo tanto, deja "intactos los caracteres de comillas dobles (y dobla todos los 'caracteres de comillas simples ) independientemente del carácter real que se utilice para citar el literal . En nuestro caso $varpermanece exactamente igual como el argumento de que se proporcionó a mysql_real_escape_string()-Es como si hay escape ha tenido lugar en absoluto .

4. La consulta

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

   Algo formal, la consulta representada es:

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

Como dijo mi amigo erudito: felicidades, usted atacó con éxito un programa usando mysql_real_escape_string()...

El malo

mysql_set_charset()no puede ayudar, ya que esto no tiene nada que ver con los conjuntos de caracteres; ni tampoco mysqli::real_escape_string(), ya que es solo un contenedor diferente alrededor de esta misma función.

El problema, si aún no es obvio, es que la llamada a mysql_real_escape_string() no puede saber con qué carácter se citará el literal, ya que eso le corresponde al desarrollador decidir más adelante. Entonces, en el NO_BACKSLASH_ESCAPESmodo, literalmente no hay forma de que esta función pueda escapar de forma segura de cada entrada para su uso con citas arbitrarias (al menos, no sin duplicar caracteres que no requieren duplicación y, por lo tanto, mezclar sus datos).

El feo

Se pone peor. NO_BACKSLASH_ESCAPESpuede no ser tan poco común en la naturaleza debido a la necesidad de su uso para la compatibilidad con SQL estándar (por ejemplo, consulte la sección 5.3 de la especificación SQL-92 , es decir, la <quote symbol> ::= <quote><quote>producción de gramática y la falta de un significado especial dado a la barra invertida). Además, su uso se recomendó explícitamente como una solución al error ( solucionado hace mucho tiempo) que describe la publicación de ircmaxell. Quién sabe, algunos DBA incluso podrían configurarlo para que esté activado de forma predeterminada como un medio para desalentar el uso de métodos de escape incorrectos como addslashes().

Además, el servidor establece el modo SQL de una nueva conexión de acuerdo con su configuración (que un SUPERusuario puede cambiar en cualquier momento); por lo tanto, para estar seguro del comportamiento del servidor, siempre debe especificar explícitamente el modo deseado después de conectarse.

La gracia salvadora

Siempre que establezca explícitamente el modo SQL para que no incluya NO_BACKSLASH_ESCAPESo cite literales de cadena MySQL usando el carácter de comillas simples, este error no puede criar su cabeza fea: respectivamente escape_quotes_for_mysql(), no se usará, o su suposición sobre qué caracteres de comillas requieren repetición será ser correcto

Por esta razón, recomiendo que cualquiera que use NO_BACKSLASH_ESCAPEStambién habilite el ANSI_QUOTESmodo, ya que forzará el uso habitual de literales de cadena entre comillas simples. Tenga en cuenta que esto no impide la inyección de SQL en el caso de que se utilicen literales entre comillas dobles; simplemente reduce la probabilidad de que eso suceda (porque las consultas normales no maliciosas fallarían).

En PDO, tanto su función equivalente PDO::quote()como su emulador de declaración preparado invocan, lo mysql_handle_quoter()que hace exactamente esto: asegura que el literal escapado se cita entre comillas simples, por lo que puede estar seguro de que PDO siempre es inmune a este error.

A partir de MySQL v5.7.6, este error se ha solucionado. Ver registro de cambios :

Funcionalidad agregada o modificada

• Cambio incompatible:mysql_real_escape_string_quote() se ha implementado unanueva función C API,como reemplazomysql_real_escape_string()porque la última función puede fallar al codificar caracteres correctamente cuando elNO_BACKSLASH_ESCAPESmodo SQL está habilitado. En este caso,mysql_real_escape_string()no puede escapar de los caracteres de comillas, excepto duplicándolos, y para hacerlo correctamente, debe conocer más información sobre el contexto de comillas de la que está disponible. mysql_real_escape_string_quote()toma un argumento adicional para especificar el contexto de cita. Para detalles de uso, vea mysql_real_escape_string_quote () .

   Nota

  Las aplicaciones deben modificarse para usar mysql_real_escape_string_quote(), en lugar de mysql_real_escape_string(), que ahora falla y produce un CR_INSECURE_API_ERRerror si NO_BACKSLASH_ESCAPESestá habilitado.

  Referencias: Véase también el error # 19211994.

Ejemplos seguros

Tomados junto con el error explicado por ircmaxell, los siguientes ejemplos son completamente seguros (asumiendo que uno está usando MySQL más tarde que 4.1.20, 5.0.22, 5.1.11; o que uno no está usando una codificación de conexión 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');

... porque hemos seleccionado explícitamente un modo SQL que no incluye 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");

... porque estamos citando nuestra cadena literal con comillas simples.

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

... porque las declaraciones preparadas para PDO son inmunes a esta vulnerabilidad (y también las de ircmaxell, siempre que esté usando PHP≥5.3.6 y que el conjunto de caracteres se haya configurado correctamente en el DSN; o que la emulación de la declaración preparada se haya deshabilitado) .

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

... porque la quote()función de PDO no solo escapa al literal, sino que también lo cita (en 'caracteres de comillas simples ); tenga en cuenta que para evitar el error de ircmaxell en este caso, debe estar usando PHP≥5.3.6 y haber configurado correctamente el conjunto de caracteres en el DSN.

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

... porque las declaraciones preparadas de MySQLi son seguras.

Terminando

Por lo tanto, si usted:

• usar declaraciones preparadas nativas

O

• usar MySQL v5.7.6 o posterior

O

• en adición al empleo de una de las soluciones en resumen ircmaxell de, el uso de al menos uno de:

  • DOP;
  • literales de cadena entre comillas simples; o
  • un modo SQL establecido explícitamente que no incluye NO_BACKSLASH_ESCAPES

... entonces deberías estar completamente seguro (vulnerabilidades fuera del alcance de la cadena escapando a un lado).

Bueno, realmente no hay nada que pueda pasar por eso, aparte del %comodín. Podría ser peligroso si usara una LIKEdeclaración, ya que el atacante podría poner solo %como inicio de sesión si no lo filtra, y tendría que forzar la contraseña de cualquiera de sus usuarios. Las personas a menudo sugieren usar declaraciones preparadas para que sea 100% seguro, ya que los datos no pueden interferir con la consulta de esa manera. Pero para consultas tan simples, probablemente sería más eficiente hacer algo como$login = preg_replace('/[^a-zA-Z0-9_]/', '', $login);