Access-Control Bypass (X-Forwarded-For)

Muchas aplicaciones restringen ciertas rutas "solo a localhost" o "solo a IPs internas" comprobando la dirección de origen. El error frecuente es fiarse de la cabecera X-Forwarded-For (o X-Real-IP, X-Client-IP, Forwarded...), que la añade un proxy pero que el cliente controla por completo. Si el control de acceso lee esa cabecera en lugar de la IP real de la conexión, basta falsificarla:

curl http://<ip>/admin -H 'X-Forwarded-For: 127.0.0.1'

Así se alcanzan paneles internos, endpoints de gestión o funciones "de localhost" desde fuera.

Otras cabeceras y trucos

Cuando el WAF o el back valida varias cabeceras, se prueban todas (a la vez o por separado), apuntando a 127.0.0.1, localhost, ::1 o la IP interna del servidor:

X-Forwarded-For: 127.0.0.1
X-Real-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Forwarded-Host: localhost
Forwarded: for=127.0.0.1

Si lo que devuelve es un 403/401 sobre una ruta concreta, entran en juego los trucos de 403 bypass: variar la ruta (/admin/, /admin/., /admin%2f, /./admin, /Admin, /admin..;/), cambiar el método (POST/HEAD donde GET está bloqueado) o añadir extensiones (/admin.json). Herramientas como ffuf con una lista de cabeceras, o extensiones de Burp, automatizan el barrido.

Requisitos

Que la aplicación (no el proxy) tome una decisión de autorización a partir de una cabecera controlable por el cliente. Un proxy bien configurado sobrescribe X-Forwarded-For con la IP real y descarta la del cliente, lo que anula el truco. El bypass abre la puerta a lo que proteja esa ruta (un LFI, una API de administración), no es RCE por sí mismo.

Cómo detectarlo. El indicio está en los propios logs: peticiones a rutas restringidas (/admin, endpoints internos) que llegan con un X-Forwarded-For: 127.0.0.1/::1 desde una IP de conexión externa. Un proxy bien configurado nunca deja pasar esa contradicción, así que su aparición es la firma del ataque. Registrar siempre la IP real de la capa TCP junto a la cabecera facilita cazarlo; un mismo origen probando muchas combinaciones de cabeceras o variantes de ruta contra /admin delata el barrido.

Defensa. No usar cabeceras controlables por el cliente para autorizar; validar contra la IP de la conexión (la capa TCP) o filtrar en el firewall/reverse proxy, que debe reescribir X-Forwarded-For y no confiar en la que llega. Relacionado con LFI / path traversal y fuga de información en APIs como lo que suele haber tras la puerta.