¿Qué es el SSRF y por qué el servicio de metadatos de la nube es un objetivo?
Respuesta breve
El SSRF engaña a un servidor para que realice peticiones HTTP (u otras) a un destino elegido por el atacante, abusando de la posición de red del servidor para alcanzar servicios internos tras el cortafuegos. En la nube es especialmente grave porque el servicio de metadatos de instancia (por ejemplo, 169.254.169.254) puede devolver credenciales IAM, convirtiendo un SSRF en un compromiso de la cuenta en la nube.
La falsificación de petición del lado del servidor (SSRF) ocurre cuando una aplicación toma una URL o dirección de la entrada del usuario y realiza una petición a ella desde el servidor. Piensa en una función que obtiene una imagen remota, valida un webhook o importa un documento desde un enlace. El atacante proporciona una URL que el desarrollador nunca pretendió, y el servidor — situado dentro de la frontera de confianza — realiza la petición en nombre del atacante.
Por qué la posición del servidor es el premio
El servidor puede alcanzar cosas que el atacante no puede: paneles de administración internos, bases de datos, otros microservicios y direcciones de enlace local, todo tras el cortafuegos. El SSRF convierte efectivamente al servidor vulnerable en un proxy hacia la red interna, permitiendo el escaneo de puertos internos y el acceso a API internas no autenticadas. Las formas que adoptan estas peticiones —direcciones de enlace local, trucos de esquema, evasiones de codificación— están catalogadas en colecciones de payloads de SSRF.
El giro de los metadatos en la nube
Las instancias en la nube exponen un servicio de metadatos de instancia en una dirección de enlace local (AWS/GCP/Azure usan 169.254.169.254). Devuelve la configuración de la instancia — y, lo más crítico, credenciales IAM temporales del rol asociado a la instancia. Un SSRF que alcance ese punto puede leer esas credenciales y usarlas contra la cuenta en la nube, escalando un único error web a un compromiso amplio de la nube. Este es el camino detrás de varias grandes brechas.
Mitigaciones
- IMDSv2 (AWS) requiere un token de sesión obtenido mediante una petición
PUTcon un límite de saltos, que un simpleGETde SSRF no puede realizar — bloqueando la vía de robo de credenciales. - Usa listas de permitidos para los destinos salientes en lugar de listas de bloqueo; las listas de bloqueo pasan por alto el DNS rebinding, las redirecciones, IPv6, las codificaciones de IP en decimal/octal y
0.0.0.0. - Resuelve y valida la IP de destino después de la resolución DNS, desactiva los esquemas de URL innecesarios y aísla el componente que realiza la petición en un segmento de red restringido.
Los entrevistadores buscan la definición «el servidor realiza peticiones elegidas por el atacante», la escalada de metadatos/credenciales IAM, IMDSv2, y la idea de que las listas de bloqueo son frágiles, por lo que se prefieren las listas de permitidos.
Posibles preguntas de seguimiento
- ¿Cómo mitiga IMDSv2 el SSRF basado en metadatos?
- ¿Por qué incluir 'localhost' en una lista de bloqueo es una defensa SSRF incompleta?
- ¿Cómo puede usarse el SSRF para el escaneo de puertos internos?