¿La inyección SQL es un riesgo hoy en día?

Question

He estado leyendo acerca de los ataques de inyección SQL y cómo evitarlos, aunque parece que nunca puedo hacer que los ejemplos "horribles" que se ofrecen funcionen, p. see this post.

Creé un archivo PHP y una tabla en la base de datos, tuve un valor pasado a través de $_GET e intenté eliminar la tabla haciendo bob'); drop table students; -- y no funcionó. PHP escapa automáticamente del \' y la consulta tiene un error, no hay daño. Mismo problema cuando se trata de replicar de inicio de sesión "ataques" como AND WHERE 1=1 etc.

código

ejemplo:

<?php 
$id = $_GET['id']; 

$sql = "INSERT INTO Users (Username) VALUES ($id)"; 
echo $sql; 
mysql_query($sql) or die(mysql_error()); 

Y me gustaría pasar sql.php?id=1); delete from Users; --

Entonces esto es algo anticuado que utiliza para aplicar en el días de PHP3 o algo así, y hoy en día, incluso los principiantes están protegidos de cosas como citas mágicas?

Estoy usando PHP5 en Ubuntu.

Answer 1

Todo lo contrario. Las comillas mágicas están en desuso en PHP5 y se eliminarán por completo en PHP 5.4, ya que trajeron más confusión al mundo de la programación que lo hicieron bien. Comprobar si las comillas mágicas están activas, y escapando cualquier entrada de SQL escrupulosamente si es necesario, sigue siendo muy, pero muy importante ... No hay razón para sentirse mal, todos hemos estado allí, y mi culo sin saber se ha salvado mediante citas mágicas incontables veces :)

El PHP manual en magic quotes lo explica todo.

Answer 2

No, esto sigue siendo muy relevante.

Como son XSS y CSRF. Nunca subestimes la importancia de un filtrado de entrada adecuado.

Answer 3

Esto es un riesgo muy activo, las citas mágicas intentan darte una solución, pero prefiero desarrollarlas siempre con comillas mágicas. De esta manera, tengo que asegurarme de que realmente escapo de las entradas. Quién sabe si las comillas mágicas estarán activadas o desactivadas en el servidor donde se implementó realmente el script.

Answer 4

No, y cuanto menos te preocupes por la inyección de SQL, es más probable que te golpee.

Answer 5

Heh, está guardado en este caso teniendo magic_quotes_gpc en "on".

You'll be screwed soon.

Answer 6

Esto sigue siendo un gran problema. No puede suponer que magic_quotes está activada en cada instalación de PHP que pueda usar.

Para ver si qotes mágicos esté encendido y limpiar el desorden de comillas mágicas:

if (get_magic_quotes_gpc() !== 0) { $foo = stripslashes($foo); } 

A continuación, la limpieza de sus declaraciones un poco:

$foo = mysql_real_escape_string($foo); 
$sql = "select * from foo where bar='{$foo}'"; 

etc.

De hecho, es mejor que se limite estrictamente a magic_quotes si tiene la capacidad para hacerlo.

Espero que eso te ayude.

Answer 7

Ese ataque en particular no funciona, ya que mysql_query solo ejecutará una sola instrucción.

Aún así puedo abusar de tu código, p. si hice arreglos para que el ID sea SELECT password FROM Users WHERE Username='admin', es posible que tenga una oportunidad de poder lograr que su sistema exponga alguna información interna.

Básicamente, si permite la entrada no filtrada en su SQL, habrá algunas maneras muy creativas de crear datos que no esperaba y de exponer los datos que no pretendía.

Answer 8

Parámetros pasados ​​a las consultas de sql desde las páginas web ofen tienden a ser ID numéricos. Por ejemplo supongamos que usted tiene una url http://foo.com/page.php?section=34 de la que se utiliza el ID de la sección de una consulta como esta:

SELECT content FROM sections WHERE section_id=$section; 

sin comillas escapen al igual que en su ejemplo y lo que voy a poner a continuación del número en el URL pasa a la consulta ... Por lo tanto, el riesgo es real.

Answer 9

El ejemplo de las tablas bobby no funcionará con la interfaz mysql porque no hace múltiples consultas en una sola llamada. La interfaz mysqli es vulnerable al ataque de consulta múltiple. La interfaz mysql es más vulnerable al ataque de refuerzo de privilegios:

En su formulario escribo la cuenta: admin contraseña: ' or 1=1 -- para que su inicio de sesión típico sql: select * from users where user_name = '$admin' and password = '$password'. El o hace que esto sea cierto y le permite iniciar sesión.

Answer 10

La regla de oro más simple es suponer que todos los usuarios input pueden estar contaminados. Verifique que los tipos de datos sean los esperados, que las variables estén en los rangos de longitud/tamaño que esperaba, los archivos sean del tamaño y tipos que permita, etc. Se pueden requerir otras comprobaciones de datos no externos, antes de llamar a un administrador importante. -función de nivel, haz una verificación - ($userlevel != ADMIN)?die():important_function();

Siempre hay un pez más grande, o alguien que es un idiota más grande que tú. Evita los supuestos sobre los datos y tienes una ventaja.

Answer 11

Hay muchas maneras diferentes de realizar una inyección SQL y bastantes formas de eludir las precauciones básicas de seguridad.

Esos ataques han estado dentro de las 10 principales vulnerabilidades de aplicaciones web (rango n.º 2) según OWASP. Para obtener más información, consulte Top 10 2007-Injection Flaws.

Answer 12

¿No puede PHP hacer los parámetros de consulta? Si puede (como me sorprendería si no lo hiciera), esa es la única solución que mitiga TODOS los ataques de inyección de SQL.

Answer 13

Las comillas mágicas no tienen en cuenta la codificación de caracteres y, por lo tanto, son vulnerables a los ataques basados ​​en multi-byte caracteres.

En cuanto a que es un riesgo hoy en día, las búsquedas de Google aparecen en innumerables sitios vulnerables. Se notificó una vulnerabilidad de inyección SQL para Bugzilla alrededor del 10 de septiembre. Por lo tanto, sí, los sitios aún están en riesgo.¿Deberían serlo? Las herramientas están ahí para prevenir la inyección, entonces no.

Answer 14

El robo de identidad más grande en la historia se logró en 2007 mediante la explotación de una vulnerabilidad de inyección SQL: ver "SQL injection attacks led to Heartland, Hannaford breaches" (ComputerWorld, 18/08/2009).

OWASP reported in 2007 que los ataques de inyección (de los cuales la inyección SQL es un ejemplo) continúan siendo uno de los problemas de seguridad de software más comunes.

También puede buscar los últimos SQL injection News y encontrar muchos casos reportados cada mes.

Sin embargo, el ejemplo en la caricatura XKCD no es necesariamente el tipo más común de exploit. Dejar caer una tabla ejecutando una segunda instrucción SQL en una solicitud probablemente no le ganaría mucho al atacante en el camino de datos valiosos, sería simplemente vandalismo.

Además, algunas interfaces de consulta no permiten multi-query de forma predeterminada. Es decir, la API del cliente de la base de datos ejecuta una única instrucción dada la cadena SQL, independientemente de los puntos y comas. Esto derrota el ejemplo que se muestra en la caricatura.

nota: método de DOP query() se sabe que el apoyo múltiples consulta por defecto. Por lo tanto, es susceptible al ataque de estilo XKCD.

Como han señalado otras personas, el riesgo más probable es que una inyección SQL altere la lógica de las expresiones SQL y aplique su consulta a filas adicionales además de las que pretendía.

Por ejemplo:

$sql = "UPDATE Users SET PASSWORD = MD5('" . $_POST["password"] . "'||salt) " . 
     "WHERE user_id = " . $_POST["userid"]; 

Lo que sucede cuando envío una solicitud con el parámetro establecido userid a la cadena 123 OR userid=456? Me gustaría restablecer mi propia contraseña (ID de usuario 123), así como la contraseña de ID de usuario 456. Incluso el hash de la contraseña con una sal por usuario no protegería contra esto. Ahora puedo iniciar sesión en cualquiera de las cuentas.

Hay muchas maneras en que se puede perpetrar la inyección SQL.

Answer 15

Como he mencionado varias veces en stackoverflow antes, yo soy un firme partidario de la DOP, simplemente dejar de usar el viejo MySQL moda, hágase y sus clientes un gran favor y aprender DOP (que es muy fácil) y aprovechar las declaraciones preparadas y los parámetros vinculados. Incluso si no necesita declaraciones preparadas en cuanto al rendimiento, aún obtiene los beneficios de seguridad.

Además, recomendaré colgar toda la aplicación en la cara del cliente si las comillas mágicas están activadas. Es solo un drenaje de recursos diseñados para proteger a los tontos y molestar a los inteligentes. (usa más CPU que escapando manualmente, porque codifica todo, incluso cuando no lo necesita)

Answer 16

Oh mi ... La inyección SQL no es un riesgo, es un agujero de seguridad abierto. Principalmente existe en php porque la API hace que quieras interpolar cualquier dato antiguo en tus consultas SQL.

Cuando veo un sitio escrito en PHP o ASP, puedo oler los vectores de inyección SQL que apestan. Las personas intentan proteger sus aplicaciones PHP con mysql_real_escape_string() y intval() y lo hacen de manera similar en otros idiomas. Esto es un error.Es como codificar en C en lugar de en Java o Python, donde en el primero, comete un error y está muerto, pero en el segundo, solo pueden existir defectos semánticos.

Recomiendo encarecidamente a las personas que utilicen ya sea mysqli con declaraciones preparadas, o cualquier otra cosa que sea parametrizada, sustituyendo texto en código y luego interpretarlo es una mala práctica en primer lugar en mi humilde opinión.

En otra nota, las citas mágicas de PHP son simplemente tontas, y afortunadamente, desaprobadas. Solo puede causar más daño que bien. Si dependes de citas mágicas, significa que tu aplicación será propiedad cuando las comillas mágicas estén deshabilitadas. Del mismo modo, puede romper otras aplicaciones que no esperan cadenas escapadas en las entradas.

Answer 17

No hoy todavía, pero es sólo 20:34 GMT

Guardian jobs database attack demonstrates difficulties of database security, 06 Nov 2009

Guardian Jobs website hack may have been an SQL injection and not a 'sophisticated' attack, 27 Oct 2009

Answer 18

Siempre que la construcción de SQL a partir de cadenas, inyección SQL es un peligro real.

También descubrí que tratar de evitar la creación de SQL a partir de cadenas es una tarea inútil. Tarde o temprano, la forma completa de su SQL (no solo las cosas que podrían ser parámetros) debe generarse en tiempo de ejecución.

Answer 19

¡Tengo que desarrollar un servidor que no tenga forma de desactivar magic_quotes! Incluyo esto en cada página para deshacer los efectos de las comillas mágicas, por lo que puedo hacer el correcto escapando sin "doble escape". Aunque puedo saborear vómitos solo por leer esto, no he encontrado una mejor solución.

if (get_magic_quotes_gpc()) { 

    $process = array(&$_GET, &$_POST, &$_COOKIE, &$_REQUEST); 

    while (list($key, $val) = each($process)) { 

     foreach ($val as $k => $v) { 

      unset($process[$key][$k]); 

      if (is_array($v)) { 

       $process[$key][stripslashes($k)] = $v; 

       $process[] = &$process[$key][stripslashes($k)]; 

      } else { 

       $process[$key][stripslashes($k)] = stripslashes($v); 

      } 

     } 

    } 

    unset($process); 

} 

Answer 20

Según OWASP 2017 Top 10, todavía la inyección es el ataque más ocurrido y peligroso.

"inyección SQL es siempre el número uno de riesgo que es un reflejo de cómo muchos incidentes están ahí fuera, así como otros factores que lo mantienen muy alta allí." Troy Hunt - fundador del sitio de incumplimiento haveibeenpwned .com

sólo para recordar, mediante la inyección de SQL podemos volcar toda la base de datos, el control de servidor web mediante la subida de la cáscara web, etc.