Inyección y recorrido de rutas, por su huella

Una inyección es un intento de que la aplicación trate como instrucción un dato que un usuario escribió: por ejemplo, que la base de datos lea como parte de su consulta lo que debía ser solo un texto de búsqueda. El recorrido de rutas es pedir un archivo subiendo de directorio, fuera de la carpeta que el sitio quería exponer. Las dos cosas dejan huella en lo que se pide: caracteres de sintaxis donde debería haber un nombre o un número, palabras reservadas de un lenguaje de consultas, secuencias de subida de directorio, o esos mismos caracteres codificados para que parezcan inofensivos.

Pero esa huella dice qué se intentó, nunca qué pasó. Que alguien escriba algo así en un parámetro no demuestra que la aplicación lo ejecutara. La respuesta lo dice: el estado, el tamaño y el tiempo, comparados con lo que es normal para esa misma ruta. Un 403 pequeño y rápido es una puerta cerrada; una respuesta que no se parece a ninguna otra de esa ruta es lo que hay que mirar primero.

Un WAF (cortafuegos de aplicaciones web) mira cada petición contra un conjunto de reglas. Cuando una coincide, anota qué regla fue, qué patrón vio y qué hizo con la petición: bloquearla (la respuesta es una página de rechazo, normalmente un 403 pequeño) o solo registrarla. Los fabricantes no guardan siempre la cadena completa: es habitual que el registro describa el patrón, como hace este.

El orden de lectura es siempre el mismo: primero la ruta y el parámetro (¿qué se intentó tocar?), después la regla (¿qué categoría de ataque es?), después la acción. Tres peticiones seguidas, desde un mismo origen, a la ruta de descargas de archivos y sobre el parámetro del nombre de archivo, no son tres curiosidades: son una persona probando variantes. La tercera es la que más información trae, porque cambió de forma de escribir lo mismo.

Una regla de WAF recién escrita casi nunca se activa cortando desde el primer día: se pone en modo de prueba (detecta y apunta, pero deja pasar) mientras se comprueba cuánto tráfico legítimo la dispara. Es una práctica sana, la misma que con una regla de SIEM, y tiene una consecuencia que el analista debe recordar: mientras una regla está en prueba, todo lo que detecta sigue llegando a la aplicación.

Una alerta del WAF que dice «bloqueado» y otra que dice «solo registrado» no tienen la misma urgencia. La segunda es la que hay que cruzar con la respuesta del servidor. La tabla de reglas dice en qué modo está cada una.

Dos orígenes distintos tienen peticiones que el WAF solo registró. Con los dos pasó lo mismo en el WAF y lo contrario en el servidor: la respuesta de uno es pequeña, rápida y de las que da una aplicación que rechaza una entrada que no esperaba; la respuesta del otro no se parece a ninguna otra de esa ruta. Normalmente una consulta devuelve unas docenas de libros, no medio megabyte, y no tarda segundos.

Esa es la forma de leer una huella de inyección que pudo funcionar: una petición con patrón de ataque, no bloqueada, y una respuesta con tamaño y tiempo muy por encima de lo típico. No prueba por sí sola qué datos salieron, pero convierte el caso en un incidente hasta que alguien de la aplicación demuestre lo contrario.

Ya tienes el cuadro: un origen cuyos intentos se cortaron todos y dos cuya detección solo se registró, uno de ellos con una respuesta enorme. Hay tres respuestas posibles de un analista y solo una sirve para ese origen. Un cierre en falso aquí es el tipo de error que se descubre meses después, cuando la base de clientes aparece a la venta.

La respuesta de un SOC no es técnica sola. Se escala el incidente al responsable de la aplicación y a respuesta a incidentes, se conserva el registro de la aplicación y de la base de datos de esa franja (para saber qué consulta se ejecutó y qué filas devolvió), y se pide pasar la regla de prueba a bloqueo cuando el equipo del WAF compruebe que no cortará tráfico legítimo.