¿Es este un ataque web que debería preocuparme? Intentar ingresar el código para las variables de formulario

4

He creado un script CGI simple que se ejecuta en un servidor web donde un usuario puede iniciar sesión con un nombre de usuario y contraseña. El nombre de usuario y la contraseña se ingresan a través de un formulario html y el formulario envía los datos al servidor web.

Registro los inicios de sesión y esto es lo que encontré que sucedió repetidamente: aproximadamente 10 intentos

Para el nombre de usuario que están ingresando:

  

') declare @q varchar (8000) seleccione @q =   0x57414954464F522044454C4159202730303A30303A313527 exec (@q) -

y para la contraseña:

  

1

Muchas variaciones leves. Aquí hay otro intento:

  

nombre de usuario: John contraseña: 1 declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A313527 exec(@q) --

¿Es este un tipo de comando SQL? ¿Un procedimiento almacenado? ¿Qué crees que están tratando de lograr?

¿Hay algún consejo sobre las medidas que debería introducir para evitar que ocurra este tipo de cosas?

    
pregunta user619818 10.11.2012 - 12:36
fuente

3 respuestas

5

Parece que hay una buena respuesta aquí y aquí .

1 declare @q varchar(8000) select @q = 0x57414954464F522044454C4159202730303A30303A313527 exec(@q) --

Si simplemente cumplimos con lo anterior, podemos tener una idea de lo que está pasando:

declare @q varchar(8000)
select @q = 0x57414954464F522044454C4159202730303A30303A313527
exec(@q)
--
  • Línea 1: declara la variable q como varchar con 8000 caracteres.
  • Línea 2: asigna la cadena codificada a la variable q .
  • Línea 3: ejecuta la variable q .
  • Línea 4: Comentarios del resto de la consulta inyectada.

Según 2 la cadena 0x57414954464F522044454C4159202730303A30303A313527 está WAITFOR DELAY '00:00:15' codificada en hexadecimal. Una técnica de ataque de inyección de SQL ciego cronometrada que le dice al servidor que espere 15 segundos antes de responder. Una vez que se inyecta la carga útil, si el servidor tarda 15 segundos en responder, existe una buena probabilidad de que sea vulnerable a la inyección de SQL. Esto puede verificarse aún más aumentando el tiempo DELAY .

    
respondido por el ethicalhack3r 10.11.2012 - 14:42
fuente
3

No soy un experto, pero parece ser un intento de inyección de SQL. Esperan que lo que ingresen de alguna manera sea ejecutado por su servidor, lo que resultará en que el contenido de las variables @q se ejecute si tienen éxito. Supongo que es un comando sql de alguna manera codificado, esa cadena "0x5741 ....". Pero creo que alguien aquí podría arrojar mucha más luz sobre esto que yo.

Lea sobre las inyecciones de SQL y verifique si su código es lo suficientemente bueno como para ser inmune. Supongo que también podría implementar un mecanismo de bloqueo (para la IP de origen por algún tiempo) si su código ve una cierta cantidad de tales intentos.

    
respondido por el TheUser1024 10.11.2012 - 12:42
fuente
2

Bienvenido a internet. La ejecución de un servidor web público en Internet significa que será atacado. Realmente no hay nada que puedas hacer para prevenirlo. Lo que puede hacer es tratar de evitar que los ataques tengan éxito. Esto implica prácticas de codificación seguras, mantener su software actualizado y tal vez introducir algunos controles de seguridad.

Este ataque en particular, como han mencionado otros, es un intento de inyección ciega de SQL. Inténtalo tú mismo; Si su servidor espera 15 segundos antes de responder, entonces su secuencia de comandos CGI es vulnerable. Hay muchos recursos disponibles sobre prevenir la inyección de SQL , por lo que no voy a aburrirte con los detalles aquí.

Definitivamente recomendaría el uso de algunos controles de seguridad para su sitio. Puede probar controles preventivos como mod_security o controles de detección como un programa de auditoría de registro web. Solo ejecuto un sitio de pasatiempos con una página estática, así que tengo una solución para aficionados: un filtro personalizado fail2ban para mi registro web que detecta un pocos ataques comunes y luego estrangula la conexión a esa IP. Realmente no es nada que recomendaría a un sitio que tenía activos reales para proteger, pero ilustra el punto en el que puede hacer controles de seguridad simples para aumentar las soluciones probadas y comprobadas que todos los demás están usando.

    
respondido por el bonsaiviking 10.11.2012 - 15:50
fuente

Lea otras preguntas en las etiquetas