Confirmar un resultado sin explotarlo

Una alerta dinámica dice «con esta petición pasó esto». Confirmarla es comprobar que la causa existe: que el dato de fuera llega donde la regla teme y sin la protección que debería tener. Para eso basta casi siempre con tres fuentes: la petición y la respuesta que guardó el escáner, una repetición con valores normales del negocio o con una marca que no hace nada, y el código de la ruta.

Lo que no forma parte de confirmar: sacar datos, encadenar un fallo con otro, demostrar impacto o usar herramientas de explotación automática. Todo eso cambia la naturaleza del encargo, puede tocar datos de personas aunque sea preproducción y no añade nada a la decisión que hay que tomar.

Abre el laboratorio y lee alerta-40018.txt y repeticiones-movimientos.txt. El escáner concluyó que había inyección porque sus valores de prueba cambiaban la respuesta de 200 a 500. Antes de creerlo hay que saber si cualquier valor raro, sin nada de prueba, produce el mismo 500.

La repetición sugiere que el 500 no tiene que ver con la consulta. El código lo cierra: lee codigo-movimientos.txt y sigue el valor de orden hasta la consulta.

La otra alerta tiene dos instancias en la misma página, una por parámetro. Una marca inofensiva con una comilla y un signo menor basta para saber si el valor vuelve codificado (convertido en entidades que el navegador pinta como texto) o tal cual, y en qué contexto: dentro de un texto o dentro del valor de un atributo, donde una comilla sin codificar cierra el atributo.

Lee alerta-40012.txt y repeticiones-oficinas.txt.

El veredicto queda escrito para el comité y para quien lo lea cuando el código cambie. Una buena nota dice qué se repitió, con qué cuenta, en qué entorno y a qué hora, qué se observó y qué dice el código. Una de las dos alertas resultó falsa por la inyección, pero dejó a la vista otro defecto menor; la otra es real en uno de sus dos parámetros.