Entendiendo las solicitudes de ataque HTTP GET

26

He capturado algunos ataques web. Estoy tratando de entender qué propósito logra cada solicitud de ataque.

GET /site/public/timing?<!+XSS="><img+src=xx:x+onerror=alert(14721850.00337)//"> HTTP/1.1" 200 6718

GET /site/public/timing?<sVg/OnLOaD=prompt(14721850.00307)> HTTP/1.1" 200 6718

GET /site/race/registrationAuth/1761?x"+onmousemove=" HTTP/1.1" 302 -

GET /site/registration/create/3269?execution=e1s1'+(select*from(select(sleep(3)))tw)+' HTTP/1.1" 302 -

GET /site/registration/create/3269?execution=e1s1%20waitfor delay'0:0:3'
    
pregunta guest 29.08.2016 - 09:36
fuente

4 respuestas

40

Esto parece ataques automatizados para probar diferentes vulnerabilidades de inyección. Por lo que puedo decir, no hay una carga útil real maliciosa aquí. Los ataques son, en cambio, diseñados para detectar si el sitio es vulnerable. Supongo que los sitios serán atacados con cargas útiles reales si las pruebas son positivas.

Los tres primeros son XSS . Los dos primeros intentarán mostrar un mensaje con el número 14721850.00337 en él. Si multiplicas ese número por 100, obtienes una marca de tiempo de Unix que fue hace tres días. Supongo que se usa para sincronizar el ataque de alguna manera.

Se emplean algunos trucos comunes para engañar a los filtros: mIxeD CAsE, prompt en lugar de alert , / en lugar de espacio.

La cuarta y la quinta prueba de inyección SQL . Intenta hacer que el servidor de la base de datos "duerma" por un tiempo. Eso facilita comprobar si el ataque fue exitoso. Si tarda un par de segundos en obtener una respuesta, funcionó. Creo que el cuarto está dirigido a MySQL y el quinto a MSSQL, pero también podrían funcionar en otros sistemas.

¿Entonces necesitas estar preocupado? Realmente no. Este tipo de ataques automáticos son comunes contra cualquier servidor de Internet. No tiene por qué significar que alguien te está atacando activamente específicamente o que eres vulnerable. Pero aún así, probablemente sea una buena idea probar si los ataques funcionan o no, porque si lo hicieron, puedes estar seguro de que ya han sido explotados.

    
respondido por el Anders 29.08.2016 - 10:29
fuente
11

Todas estas solicitudes parecen provenir de una herramienta de prueba automatizada. Al contrario de lo que dicen algunos comentarios, los retrasos no son maliciosos, solo para probar ciegamente la ejecución del código; Si no puede ver una respuesta, hacerla dormir durante un número determinado de segundos es una prueba confiable.

GET /site/public/timing?<!+XSS=">    <img+src=xx:x+onerror=alert(14721850.00337)//"> HTTP/1.1" 200 6718
GET /site/public/timing?<sVg/OnLOaD=prompt(14721850.00307)> HTTP/1.1" 200 6718

XSS intenta, intenta alertar al 14721850.00307 / 337 para ver si la página es vulnerable.

GET /site/race/registrationAuth/1761?x"+onmousemove=" HTTP/1.1" 302 -

Algo confuso, sin código funcional. Parece que XSS utiliza un controlador de eventos para evitar los filtros

GET /site/registration/create/3269?execution=e1s1'+(select*from(select(sleep(3)))tw)+' HTTP/1.1" 302 -

MySQL v5 attack. A pesar de la instrucción SELECT, solo intenta dejar que el servidor se duerma durante 3 segundos para ver si es vulnerable.

GET /site/registration/create/3269?execution=e1s1%20waitfor delay'0:0:3'

Ataque de Microsoft SQL Server. La misma historia, sin código malicioso, solo un retraso de 3 segundos.

    
respondido por el J.A.K. 29.08.2016 - 11:55
fuente
2

1 & 2: Alguna inyección de XSS

3: muy probablemente un XSS también

4: inyección SQL (volcado de base de datos)

5: inyección de T-SQL (sonda SQL)

Recuerde que algunos bots simplemente lanzan cosas detrás de una url para ver si algo regresa, estos son objetivos no específicos (pruebas fuzz). Los encabezados recibidos se verifican para ver si hay 200 o algún otro código HTTP sin error. Además, al asignar al azar la solicitud GET, el atacante puede ingresar resultados en caché u omitir las medidas de seguridad.

    
respondido por el Yorick de Wid 29.08.2016 - 10:25
fuente
2

No estoy 100% seguro de esto, pero el primero y el segundo parecen ataques de scripting. Ambos intentan inyectar JavaScript que emite una alerta o un mensaje con un número en particular, nada dañino en sí mismo, pero está probando si esto es posible.

El tercero está intentando agregar un evento onmousemove . Creo que está tratando de hacer que el usuario envíe una solicitud cada vez que mueva el mouse. ¿Por qué huele eso como un ataque de denegación de servicio?

El cuarto parece una inyección de SQL: solicita todo a partir de los resultados de otra consulta. No estoy seguro de qué hace esa otra consulta, pero creo que está destinado a esperar tres segundos y no hacer nada.

El quinto es una inyección de SQL ciego . Este le está diciendo a una base de datos de SQL Server que espere tres segundos; si vuelve con éxito, la base de datos puede ser atacada.

    
respondido por el Philip Rowlands 29.08.2016 - 10:25
fuente

Lea otras preguntas en las etiquetas