Todos sabemos que debemos usar sentencias preparadas o el reemplazo de las reglas de formato con el fin de evitar la inyección de código sql en nuestras aplicaciones.

Sin embargo, al echar un vistazo a MySQL de la lista de caracteres literales, me di cuenta de que incluye los siguientes caracteres:

  • \0 ASCII NUL (0x00) carácter.
  • \' Una comilla simple (') carácter.
  • \" Una comilla doble (") carácter.
  • \b Un carácter de retroceso.
  • \n Un salto de línea (linefeed) carácter.
  • \r Un carácter de retorno de carro.
  • \t Un carácter de tabulación.
  • \Z ASCII 26 (Ctrl+Z). Véase la nota a continuación de la tabla.
  • \\ Una barra diagonal inversa (\) carácter.
  • \% Un % carácter.
  • \_ Un _ carácter.

Ahora, mientras que el % y _ personajes necesitan ser escapado con el fin de evitar la inyección de no deseados comodines COMO declaraciones, y mientras el ' (comilla simple), \ (barra diagonal inversa), y " (comilla doble), todos necesitan ser escapado con el fin de evitar la inyección de SQL arbitrario – podría tener cualquiera de estos otros personajes sin escape conduce directamente a una vulnerabilidad de inyección SQL que de otra manera no estarían presentes? ¿Alguien tiene alguna ejemplos del mundo real de tal explotar?

Supongamos que estamos construyendo nuestra consulta como:

SELECT * FROM users WHERE username='$user'

Hay ningún valor para $user donde el único sin escape de caracteres literales son \b (retroceso), \0 (NUL), \n (newline), \r (salto de línea), \t (ficha) o \Z (Ctrl+Z), que permite la inyección de SQL arbitrarias en esta consulta?

Quiero saber si el carácter «%» puede conducir a nada más que resultados adicionales en una cláusula LIKE.
La respuesta corta a tu pregunta es, hasta donde yo soy consciente, no a los personajes (aunque sin escape) no va a terminar la cadena literal contexto y colocar el servidor en SQL contexto; por lo tanto la inyección de SQL no puede surgir. Sin embargo, usted debe tener cuidado de que su escape de la metodología es consciente de que el conjunto de caracteres que utiliza el servidor para decodificar la cadena literal de bytes recibidos: si el escape se lleva a cabo en un conjunto de caracteres diferente, es posible que cuidadosamente cadenas para terminar la cadena literal e inyectar SQL arbitrario.
A partir de una como con un % cambios en el plan de consulta para el uso de un análisis completo de la tabla que generalmente es malo para el rendimiento. Así que si todo lo demás se maneja que todavía podría ser utilizado para atacar un sistema. Dependiendo de la interfaz que se utilice, la inyección de una ; puede permitir que usted para ejecutar una segunda consulta. Es una buena política para limitar los permisos del usuario que se ejecuta la consulta. Línea de caracteres de comentario como — en mysql también puede causar problemas. ex: UPDATE usuarios set access_time = x where id = y; si x es -9999 — que podría ser utilizado para la actualización de todos los usuarios access_time.
No veo un comentario de caracteres de la lista. Este es uno de los más comunes que conseguir que figuran en los ataques de inyección SQL.

OriginalEl autor schizodactyl | 2013-01-17

2 Comentarios

  1. 4

    Teniendo en cuenta las siguiente líneas de mysql_real_escape_string() manual :

    MySQL sólo requiere que la barra invertida y el carácter de cita, se referia a la cadena de la consulta se escapó. mysql_real_escape_string() cotizaciones de otros personajes para hacerlos más fáciles de leer en los archivos de registro.

    La inyección de SQL en MySQL no debe ser posible con estos caracteres especiales solo por sí mismos : \b \0 \n \r \t \Z .

    Sin embargo Literales de Cadena manual se establece el siguiente, pero los motivos especificados ( o no ) no se refiere a la inyección de SQL :

    Si desea insertar los datos binarios en una columna de cadena (como un BLOB columna), debe representar ciertos caracteres por secuencias de escape. La barra invertida («\») y el carácter de cita, se referia a la cadena debe ser escapado. En ciertos entornos de cliente, también puede ser necesario para escapar de NUL o Control+Z. El mysql cliente trunca citado cadenas que contengan caracteres NUL si no se escapó, y Control+Z puede ser tomado para FIN DE ARCHIVO en Windows si no se escapó.

    Además , en una prueba sencilla , independientemente del tiempo de los enumerados anteriormente, los caracteres especiales se escapó o no , MySQL dio mismos resultados . En otras palabras MySQL ni siquiera la mente :

    $query_sql = "SELECT * FROM `user` WHERE user = '$user'";

    La consulta de arriba trabajado de manera similar para que no se escapó y se escapó de las versiones de los anteriormente mencionados personajes como poner a continuación :

    $user = chr(8);     // Back Space
    $user = chr(0);     // Null char
    $user = chr(13);    // Carriage Return
    $user = chr(9);     // Horizontal Tab
    $user = chr(26);    // Substitute
    $user = chr(92) .chr(8);    // Escaped Back Space
    $user = chr(92) .chr(0);    // Escaped Null char
    $user = chr(92) .chr(13);   // Escaped Carriage Return
    $user = chr(92) .chr(9);    // Escaped Horizontal Tab
    $user = chr(92) .chr(26);   // Escaped Substitute

    Tabla de prueba y los datos utilizados en la prueba simple :

    -- Table Structure
    
    CREATE TABLE IF NOT EXISTS `user` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `user` varchar(10) CHARACTER SET utf8 NOT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8;
    
    -- Table Data
    
    INSERT INTO `user` ( `user` ) VALUES
    ( char( '8' ) ),
    ( char( '0' ) ),
    ( char( '10' ) ),
    ( char( '13' ) ),
    ( char( '9' ) ),
    ( char( '26' ) );

    OriginalEl autor Uours

  2. 3

    No hay ningún tipo de personajes.

    Hay dos declaraciones erróneas en tu pregunta que te llevan a confundir:

    1. Todos sabemos que debemos usar … el correspondiente reemplazo de reglas con el fin de evitar la inyección de código sql en nuestras aplicaciones.

    Esto está mal comunicado. No sustitución, pero formato. Es cosa esencial. Los reemplazos no protegen contra las inyecciones, mientras que el formato no. Tenga en cuenta que cada parte distinta de la consulta requieren diferentes formato que ser inútil para cualquier otra parte. Decir, no hay otro personaje, esencial para la inyección de protección – un acento grave (`). Pero no la lista es porque no tiene nada que ver con los literales de cadena.

    1. ‘(comilla simple), \ (barra diagonal inversa), y » (comilla doble), todos necesitan ser escapado con el fin de evitar la inyección de

    Esto está muy mal comunicado. Escapar de no evitar las inyecciones! Estos caracteres deben ser escapado con el fin de cadenas de formato y no tiene absolutamente nada que ver con las inyecciones. Si bien es cierto que correctamente formateado parte de la consulta es invulnerable contra de la inyección. Pero la verdad es que tengas que formatear dinámico de consulta de las partes sólo para el bien de ella, a seguir reglas de sintaxis – no, porque de lo de las inyecciones. Y usted tendrá su consulta impenetrable como una consecuencia.

    Ahora usted puede ver por qué su última declaración,

    ¿por qué todos estos personajes son lo suficientemente vulnerable para ser escapado a través de mysql_real_escape_string, ya que no es inmediatamente obvio para mí.

    está mal puesto:

    Es el formato de cadena normas requieren de estos personajes, no lo de «vulnerabilidad». Algunos de ellos se escapó solo por conveniencia, algunos para mejorar la legibilidad, algunos por razones obvias de escapar de un delimitador. Eso es todo.

    Para responder a preguntas recientes de comentarios:

    Realmente quiero una respuesta a esto, como PHP mysql_real_escape_string no cita a estos literales.

    De nuevo: aunque en la mente de promedio de usuario de PHP mysql_real_escape_string() está fuertemente conectado con lo que asustar a la inyección, en realidad no es así. No hay «peligroso» personajes de la historia. Ni una sola. Hay algún servicio de caracteres con un significado especial. Ellos tienen que ser escapado en algunas circunstancias, depende del contexto.

    Por lo tanto, no hay ninguna conexión entre los personajes de escapar de esta función, y lo de «peligro». El momento de empezar a pensar que mysql_real_escape_string()‘s objetivo es escapar de «peligroso» de los personajes, que son, de hecho, convertirse en un peligro. Mientras que el tiempo que usted está usando esta función sólo para escapar de las cadenas (y de hacerlo de manera incondicional) – se puede considerar a sí mismo seguro (por supuesto, si usted no olvides formato todos los demás literales demasiado, con sus respectivas reglas de formato)

    Quiero saber si el carácter «%» puede conducir a nada más que resultados adicionales en una cláusula LIKE.

    No.

    Mientras que realmente le agradezco que se haya tomado el tiempo para responder a esto, es claro que puede ser la inserción de malformatted cadenas en una consulta sql si no escapar de estos personajes, el malentendido pensar que yo tenía era un artefacto de mi texto y no se trata de una incomprensión. He reformulado la pregunta un poco y en negrita la pregunta en el post original. Reconozco que la razón por la que las cadenas de formato no es para evitar la inyección, pero para representar correctamente los datos en la base de datos, sin embargo SÓLO me interesan los aspectos de seguridad de esta pregunta.

    OriginalEl autor Your Common Sense

Dejar respuesta

Please enter your comment!
Please enter your name here