Aplicaciones web

Una inyección SQL aparece cuando la aplicación mete lo que escribe el usuario dentro de una consulta sin separarlo de la instrucción. El síntoma no siempre es un error visible: a veces es que una comilla en un campo cambia el comportamiento, que un ' OR '1'='1 devuelve resultados que no deberían, o que una condición verdadera y una falsa producen respuestas distintas. Reconocerlo es leer el cambio de comportamiento, no esperar un mensaje de error rojo.

En la tienda de Arrecife, un campo de búsqueda devuelve resultados distintos ante una condición verdadera y una falsa que inyectas. Ese contraste es la firma de una inyección, y dirige el paso siguiente: confirmarla de forma controlada, por ejemplo con sqlmap dentro del alcance.

Son dos controles distintos y se confunden todo el rato. La autenticación responde «¿quién eres?»; la autorización, «¿qué puedes ver o hacer?». Una aplicación puede autenticar bien —pide usuario y contraseña, valida el segundo factor— y autorizar mal: una vez dentro, no comprueba que el recurso que pides sea tuyo. El pentester tiene que saber cuál de los dos falla, porque el arreglo es distinto.

En Arrecife inicias sesión como un cliente normal y, cambiando un número en la dirección de un pedido, ves el pedido de otro cliente. La autenticación funcionó; lo que falló es la autorización: la aplicación no comprobó de quién es el recurso.

Encontrar que puedes ver el pedido de otro cliente no es el final: hay que medir hasta dónde llega. ¿Es un pedido suelto o puedes recorrer todos cambiando el número? ¿Se ven datos personales, direcciones, medios de pago? El impacto de un control de acceso roto se mide por el alcance de lo que expone, y eso se demuestra con la mínima evidencia necesaria —sin volcar la base entera, como fija la regla de manejo de datos de la ruta—.

En Arrecife confirmas que el número del pedido es secuencial y que recorriéndolo se expondrían los datos de todos los clientes. Ese es el impacto real que va al informe, probado con una muestra mínima, no con el volcado completo.

Una inyección SQL rara vez se queda en leer datos. Según los permisos de la cuenta de base de datos, puede permitir leer credenciales de otros usuarios, escribir archivos en el servidor o, en el peor caso, ejecutar comandos. El criterio es reconocer hasta dónde llega el fallo sin pasarse de lo necesario para probarlo, porque una inyección que da acceso al servidor conecta esta sala con la explotación y con la escalada.

En Arrecife, la inyección de la tienda permite leer una tabla con credenciales de cuentas internas. Eso cambia el engagement: esas credenciales alimentan la sala de contraseñas y, si se reutilizan, abren otros objetivos. Se documenta el salto, no solo la inyección.

La inyección se confirma de forma controlada y se documenta por su punto de entrada exacto. Abre el laboratorio y lee la salida de la confirmación: nombra la ruta y el parámetro donde la inyección quedó confirmada. Aísla ese punto de entrada.