¿Cómo funciona la inyección SQL a través de la URL?

Question

¿Cómo funciona la inyección SQL a través de la URL?

#1 de Simon (10 votos)
#2 de Gumbo (5 votos)

10

Me pregunto cómo funciona la inyección de SQL a través de la URL con SQL en el parámetro. Supongamos que tengo una base de datos con una tabla llamada mytable . Cuando obtengo una ID del método POST, la puse en esta consulta:

SELECT * FROM 'mytable' WHERE id='POST[id]'

Incluso si el usuario pone SQL como:

SELECT * FROM 'mytable'

Se convirtió en algo como esto:

SELECT * FROM 'mytable' WHERE id='SELECT * FROM 'mytable'

Así que simplemente vuelve:

Tienes un error en tu sintaxis SQL.

Entonces, ¿cómo funciona este tipo de ataque? ¿Cómo puede el atacante cambiar la consulta sin causar un error de sintaxis?

web-application sql-injection

pregunta Anders 03.06.2013 - 19:55

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application sql-injection

¿Cómo puedo identificar que el robot solicita mi página, pero no el navegador del usuario? ¿Qué hace la aplicación Blue Coat Unified Agent?

score 10 · Answer 1

El punto de inyección SQL es modificar la consulta donde está la variable.

Usemos la consulta que escribiste como ejemplo. Si la variable id contiene algo como esto y no se desinfecta correctamente:

' OR 1=1#

Volvería a cada fila porque se ha modificado a esto:

SELECT * FROM 'mytable' WHERE id='' OR 1=1#'

El truco para evitar el error de sintaxis es comentar el resto de la consulta (el carácter # lo hace en esta situación.

score 5 · Answer 2

La explotación de las inyecciones de SQL es el arte de proporcionar parámetros que, cuando se incorporan a una declaración SQL, dan como resultado una sintaxis válida de la declaración SQL mientras se cambia la semántica prevista por el desarrollador a algunas que son rentables para un atacante.

Dependiendo de la DMBS y el tipo de declaración, en el que es posible la inyección, los resultados de una inyección SQL exitosa varían de la divulgación de información (lectura de datos arbitrarios, archivos locales), a través de la manipulación de datos (inserción, eliminación o alteración arbitraria) datos, escribiendo archivos locales), hasta la ejecución de comandos arbitrarios.

El DBMS y la declaración también afectan las técnicas que se pueden utilizar durante la explotación. Si la API de conexión no permite la ejecución de varias declaraciones (llamadas 'consultas apiladas'), las a menudo citadas Robert';DROP TABLE Students; -- no tendrían efecto. En ese caso, también estaría limitado a los efectos secundarios del tipo de declaración particular en el que se produce la inyección : si es un% Declaración SELECT , lo más probable es que solo sea posible leer datos, pero no escribir o eliminar datos.

Y finalmente, también depende de la retroalimentación que se le da al atacante sobre el resultado de la declaración ejecutada. Los mensajes de error, especialmente los generados por una API de conexión o un lenguaje de programación, suelen ser bastante técnicos y detallados y pueden revelar información crítica, por ejemplo, partes de la declaración fallida como "Tiene un error en su sintaxis de SQL cerca de '...'". Tales mensajes pueden proporcionar a los atacantes información útil sobre el contexto en el que se produce la inyección (tipo de declaración, tipo de cláusula, nivel de anidamiento entre paréntesis, etc.).

En su ejemplo, un simple id=' OR '1'='1 resultaría en la siguiente declaración:

SELECT * FROM 'mytable' WHERE id='' OR '1'='1'

Con la última expresión '1'='1' se seleccionarán todas las filas. Una extensión de esto sería utilizar una subconsulta para leer datos arbitrarios de manera ciega:

SELECT * FROM 'mytable' WHERE id='' OR EXISTS (SELECT * FROM users WHERE name='admin' AND password LIKE 'a%') AND '1'='1'

Aquí, todas las filas solo se seleccionarán si existe un usuario admin cuya contraseña comienza con a , de lo contrario no se seleccionaría ninguna fila. Esta técnica se denomina "ciego de base booleana".