SSRF, acrónimo de server-side request forgery, es una vulnerabilidad en la que un atacante manipula la aplicación servidor para que esta realice peticiones HTTP (o de otros protocolos) hacia destinos arbitrarios. Esos destinos no son elegidos por el desarrollador, sino impuestos por el atacante a través de parámetros controlados, y pueden incluir recursos internos no expuestos a internet, servicios cloud de metadata, sistemas en la red privada del workload, o incluso protocolos no HTTP cuando el cliente del servidor los soporta. En arquitecturas modernas, donde una aplicación legítima necesita salir a internet para consumir webhooks, APIs externas o servicios de terceros, distinguir una petición saliente lícita de un abuso requiere control explícito de a dónde puede hablar el servidor.
Lo esencial: SSRF convierte al servidor en proxy involuntario del atacante. En cloud, su impacto típico es el robo de credenciales temporales desde endpoints de metadata (AWS IMDS, Azure IMDS, GCP Metadata), lo que abre la puerta a movimiento lateral con permisos del rol de instancia. La defensa pasa por allowlist estricto de destinos, IMDSv2 con hop limit, políticas de egress, validación robusta de URL y workload identity.
Qué es SSRF y por qué importa especialmente en cloud
SSRF se define como la capacidad de inducir al servidor a realizar peticiones de red hacia URLs o hosts que controla el atacante. La aplicación actúa de mediador, ejecutando la conexión con sus propias credenciales de red y, normalmente, con visibilidad a recursos que el atacante no tendría desde fuera. Aquí reside el riesgo estructural: el servidor suele estar dentro de un segmento de red privilegiado, capaz de hablar con bases de datos internas, paneles de administración, servicios de descubrimiento o, en cloud, endpoints de metadata accesibles únicamente desde la propia instancia.
La diferencia con CSRF, vulnerabilidad de nombre parecido, es radical. CSRF (cross-site request forgery) actúa del lado del cliente: el navegador de la víctima envía una petición autenticada hacia un sitio donde ya tiene sesión, inducida por un sitio malicioso. SSRF, en cambio, actúa del lado del servidor: el componente backend realiza la petición, con sus credenciales y desde su red. Por eso CSRF se mitiga con tokens y SameSite cookies, mientras que SSRF requiere control de egress y validación de destinos.
En entornos cloud, SSRF adquiere severidad crítica porque los proveedores exponen un endpoint de metadata accesible solo desde dentro de la máquina virtual. Ese endpoint entrega credenciales temporales del rol asociado a la instancia. Si el atacante consigue que la aplicación lo consulte por él, obtiene esas credenciales y puede operar contra la API del proveedor cloud con los permisos del rol, lo cual frecuentemente significa lectura de buckets, ejecución de funciones, o acceso a bases de datos. SSRF deja de ser una redirección curiosa para convertirse en pivote de compromiso cloud.
Cómo funciona un exploit SSRF clásico
Los escenarios reales más típicos parten de funcionalidades legítimas que aceptan URLs como input. Un primer ejemplo es un fetcher de URL, en el que el usuario pide al servidor que descargue un recurso remoto:
POST /api/preview
{ "url": "https://example.com/articulo" }
El backend hace requests.get(url), devuelve el contenido o lo procesa. Si no valida el destino, el atacante envía:
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }
y obtiene la lista de roles IAM disponibles en la instancia. Un segundo paso consulta el rol concreto y recibe credenciales temporales.
Un segundo escenario son las subidas de imagen por URL. La aplicación permite subir una imagen indicando una URL en lugar de un archivo. El servidor descarga, valida tipo MIME y guarda. El atacante apunta esa descarga a un servicio interno HTTP y, aunque la imagen final sea descartada, el log o el mensaje de error puede filtrar la respuesta del recurso interno.
Un tercer escenario son los webhook customizers. Una plataforma SaaS permite al cliente registrar URLs propias para recibir notificaciones. Si el servidor envía la notificación inmediatamente desde su red, sin restringir destinos privados, el cliente puede registrar como webhook un endpoint interno o de metadata y recibir su contenido en su listener.
En los tres patrones, la mecánica es idéntica: input de URL controlable por usuario, fetch del lado servidor, ausencia de validación de destino.
El gran riesgo SSRF en cloud: instance metadata endpoints
Los proveedores cloud exponen servicios de metadata accesibles desde dentro de cada instancia. Estos endpoints son legítimos y necesarios para que la propia máquina conozca su configuración y obtenga credenciales temporales del rol asignado.
En AWS, el endpoint es http://169.254.169.254/latest/meta-data/. IMDSv1 era accesible sin token, lo que facilitaba enormemente su explotación vía SSRF. IMDSv2, introducido como respuesta a los abusos observados, requiere obtener primero un token de sesión mediante una petición PUT con cabecera específica, y luego usar ese token en peticiones GET. Esa exigencia rompe los escenarios SSRF típicos basados en GET ciego.
En Azure, el Instance Metadata Service responde en http://169.254.169.254/metadata/instance y requiere la cabecera Metadata: true. Esa cabecera es trivial de añadir cuando la aplicación lo permite, pero impide SSRFs basadas en clientes HTTP que no permiten setear cabeceras arbitrarias.
GCP expone el Metadata Server en http://metadata.google.internal/ y requiere la cabecera Metadata-Flavor: Google. Misma lógica defensiva que Azure.
Kubernetes añade otra dimensión. Los pods suelen tener acceso a la API del clúster mediante el ServiceAccount montado, así como a servicios internos descubribles por DNS interno. Un SSRF dentro de un pod puede llegar al API server, listar secretos del namespace, o interactuar con servicios internos.
El caso Capital One de 2019 es la referencia pública mejor documentada del impacto que puede tener una cadena SSRF más IMDS. El compromiso, comunicado oficialmente por la entidad, combinó un acceso al servicio metadata desde un componente vulnerable con el uso posterior de las credenciales obtenidas para acceder a datos almacenados. Las publicaciones posteriores del sector cibernético analizaron extensamente la cadena de ataque, que se ha convertido en arquetipo del riesgo SSRF en cloud.
Tipos de SSRF
No todas las SSRFs entregan al atacante el cuerpo de la respuesta. La clasificación operativa habitual distingue varias variantes.
La SSRF básica devuelve la respuesta al cliente. El atacante ve directamente el contenido descargado por el servidor y puede leer endpoints internos como un proxy convencional.
La SSRF blind, sin respuesta visible, no entrega contenido pero ejecuta la petición. Se detecta y explota observando efectos colaterales: peticiones recibidas en un colaborador externo del atacante, escritos en logs, o cambios de estado en el sistema objetivo. Es la variante más frecuente en arquitecturas modernas.
La SSRF semi-blind se identifica por diferencias en tiempo de respuesta o en mensajes de error según el destino y su comportamiento. Permite inferir si un host interno existe, si un puerto está abierto, o si una ruta devuelve 200 frente a 404, aunque el contenido no sea visible.
Las connection-based explotan únicamente la capacidad de iniciar una conexión TCP, sin necesidad de protocolo HTTP completo. Útiles para mapear puertos internos a través de errores y temporizaciones.
Por último, ciertos clientes HTTP permiten esquemas adicionales más allá de http:// y https://. Esquemas como file://, gopher://, dict:// o ldap:// amplían enormemente la superficie. file:// permite leer archivos del filesystem del servidor. gopher:// se ha usado históricamente para enviar tráfico arbitrario a servicios internos como Redis o memcached, llegando incluso a ejecución remota cuando esos servicios estaban expuestos en localhost sin autenticación.
Bypass técnicas
Cuando la aplicación implementa validaciones, el atacante recurre a técnicas de bypass que aprovechan inconsistencias entre el parser que valida y el cliente HTTP que finalmente conecta.
Las inconsistencias de parseo URL son el clásico. Diferentes librerías interpretan http://attacker.com@169.254.169.254/ o http://169.254.169.254#.attacker.com/ de manera distinta. Si la validación extrae el host con una lógica y el cliente HTTP con otra, el bypass ocurre.
El DNS rebinding consiste en que un dominio bajo control del atacante resuelva primero a una IP pública (que pasa la validación) y, en una segunda consulta DNS instantes después, resuelva a una IP interna como 169.254.169.254. Entre la validación y el fetch real, el destino ha cambiado.
Las redirecciones HTTP pueden saltar validaciones que comprueban solo la URL inicial. El atacante apunta a un dominio público que responde con 302 hacia 169.254.169.254. Si el cliente sigue redirects sin revalidar destino, el ataque tiene éxito.
Las variantes IPv6 de loopback (::1, ::ffff:169.254.169.254) o las representaciones decimales y octales de IPs (2852039166 o 0xa9fea9fe) eluden filtros que comparan literales.
La codificación URL adicional, dominios punto a punto con tilde de fin, mayúsculas y minúsculas, o el uso de localhost frente a 127.0.0.1 frente a [::1] son variaciones que rompen blocklists frágiles.
Defensas en profundidad
La defensa SSRF requiere varias capas, asumiendo que cada una puede fallar individualmente.
La primera es operar siempre con allowlist explícita de destinos, no con blocklist. Una blocklist intentando enumerar IPs privadas, loopbacks, link-local y rangos cloud está condenada al fallo por la enorme cantidad de variantes. Una allowlist que especifica exactamente los dominios externos legítimos del negocio es manejable y robusta.
La segunda es controlar la resolución DNS del lado servidor. La aplicación debe resolver el host, validar que la IP resultante no pertenece a rangos privados, y conectar a esa IP resuelta, evitando que un cambio DNS posterior provoque rebinding.
La tercera es política de red a nivel infraestructura. El segmento donde corren las aplicaciones no debería poder hablar con 169.254.169.254 salvo procesos legítimos del sistema. Las redes cloud modernas permiten denegar egress a metadata desde los workloads de aplicación.
La cuarta es exigir IMDSv2 en AWS con HttpTokens=required y HttpPutResponseHopLimit=1. El hop limit impide que contenedores anidados accedan al metadata del host. La cabecera y el método PUT requeridos rompen SSRFs basadas en GET ingenuo.
La quinta es egress firewall por workload. Cada aplicación debería tener una política de salida que limite a qué destinos puede conectarse, igual que se limita la entrada. Las plataformas de service mesh y las políticas de red Kubernetes facilitan esta granularidad.
La sexta es validación robusta de URLs mediante librerías especializadas, no expresiones regulares ad hoc. Parsear correctamente el host, descartar esquemas no permitidos, normalizar y comparar contra allowlist.
La séptima, y quizá la más estratégica, es adoptar workload identity (IRSA en EKS, Workload Identity en GKE, Managed Identity en AKS) que evita la dependencia de IMDS como fuente de credenciales. Cuando es viable, el endpoint de metadata deja de ser la fuente de secretos.
SSRF en APIs modernas
Las APIs SaaS y las plataformas que ofrecen integraciones flexibles concentran riesgo SSRF estructural. Los webhook customizers permiten al cliente declarar URLs destino para eventos, lo cual es funcionalidad legítima y vendible, pero abre una puerta a apuntar al metadata service interno si la plataforma no segmenta correctamente.
Los servicios de URL preview, comunes en aplicaciones de chat y colaboración, fetchean enlaces para mostrar miniaturas y descripción. Sin allowlist, son SSRFs de manual.
Los generadores PDF que aceptan HTML o URL como input renderizan en un navegador headless que descarga assets. Si el navegador puede pedir recursos arbitrarios, se llega a metadata.
Los servicios de screenshot tienen el mismo perfil. Una integración legítima de pruebas de UI puede convertirse en exfiltración de IMDS si la instancia donde corre tiene credenciales sensibles.
En todos los casos, la solución correcta es ejecutar el componente fetcher en una red sin acceso a metadata, con egress controlado, o usando proveedores especializados que aíslen ese trabajo.
Cómo testear SSRF en una auditoría
En pentest, el primer paso es enumerar inputs que aceptan URLs: campos de avatar, importación de feeds, configuraciones de webhooks, integraciones con servicios externos, parámetros de redirect, generación de informes con assets remotos.
La segunda fase usa out-of-band testing con un colaborador externo controlado. Herramientas como Burp Collaborator generan un dominio único, y cualquier interacción contra él, DNS o HTTP, queda registrada. Inyectando ese dominio en cada input se detecta SSRF blind sin necesidad de respuesta visible.
La tercera fase introduce payloads específicos para cloud según el proveedor objetivo. Si la aplicación corre en AWS, se prueban variantes de 169.254.169.254 con todas las codificaciones, IMDSv2 con token negociation, y rutas conocidas del IMDS. Si es GCP o Azure, se prueban sus respectivos endpoints con cabeceras requeridas.
La cuarta fase prueba bypasses cuando hay validación: redirects, DNS rebinding, IPv6, encoding alternativo.
El tooling OAST se complementa con servidores propios capaces de servir respuestas con redirects o devolver IPs cambiantes para rebinding. En auditorías serias, se mantienen colecciones internas de payloads probados.
Encaje con OWASP Top 10 y cloud security
SSRF apareció por primera vez con entrada propia en OWASP Top 10 2021 como A10, reconocimiento explícito de su crecimiento como vector crítico. Hasta entonces se subsumía dentro de otras categorías.
En frameworks de cloud security, las recomendaciones de los CIS Benchmarks para AWS, Azure y GCP incluyen controles directamente relacionados con SSRF y metadata: exigir IMDSv2, restringir hop limit, denegar acceso de aplicaciones al endpoint metadata desde la red, usar workload identity.
Los servicios CSPM modernos identifican configuraciones que aceptan IMDSv1 y las marcan como hallazgos críticos. La integración con pentest manual es complementaria: el CSPM detecta la configuración insegura, el pentest verifica si una aplicación efectivamente la explota.
Preguntas frecuentes
¿SSRF es lo mismo que CSRF?
No. CSRF se ejecuta en el navegador de la víctima y abusa de sesiones autenticadas en sitios donde la víctima ya está logueada. SSRF se ejecuta en el servidor de la aplicación y abusa de la capacidad del servidor de hacer peticiones de red. Mitigaciones distintas, impactos distintos.
¿IMDSv2 elimina el riesgo SSRF en AWS?
Reduce significativamente, no elimina. IMDSv2 corta las SSRFs basadas en simple GET sin cabeceras controlables, que son la mayoría. Pero si la aplicación ejecuta peticiones HTTP completas con cabeceras y métodos arbitrarios, IMDSv2 sigue siendo accesible. Combinarlo con egress restringido y workload identity es lo correcto.
¿Allowlist o blocklist?
Allowlist siempre. Blocklist enumerando rangos privados pierde frente a la creatividad de codificación, DNS rebinding y nuevas representaciones. Allowlist sobre los pocos dominios externos legítimos es mantenible y robusta.
¿Qué es DNS rebinding?
Un atacante controla un nombre de dominio cuyo DNS responde primero con una IP pública (que pasa la validación) y, segundos después, con una IP interna como 169.254.169.254. Si la aplicación valida en un momento y conecta en otro, el destino ha cambiado entre ambos.
¿Las arquitecturas microservicios son más expuestas a SSRF?
Tienden a serlo. Hay más componentes haciendo peticiones internas, más URLs configurables entre servicios, más superficie de webhooks y más complejidad de egress. La defensa requiere políticas de red por servicio y service mesh con control fino.
¿Cómo detectar SSRF en logs?
Buscando peticiones salientes desde aplicaciones hacia destinos inesperados, especialmente IPs privadas, loopbacks o rangos de metadata. Los logs del egress firewall o del service mesh son la fuente más fiable. Las alertas deben dispararse ante cualquier intento de aplicación de aplicación legítima de hablar con 169.254.169.254 si no está autorizada.
Recursos relacionados
- Qué es CSRF: cross-site request forgery
- Pentesting cloud en AWS, Azure y GCP
- Errores de configuración cloud en AWS y Azure
- Pentesting de APIs REST y GraphQL
- Qué es Burp Suite en pentesting web
- Pentesting de aplicaciones web
- Qué es CORS y seguridad web
Auditoría SSRF cloud-native con Secra
En Secra realizamos auditorías de seguridad que tratan SSRF como vector de primer orden en entornos cloud-native. El servicio combina pentesting de aplicación, validación de cadenas de ataque SSRF más IMDS específicas para AWS, Azure y GCP, revisión de políticas de egress por workload, y verificación de la postura IMDSv2 y workload identity. Entregamos hallazgos accionables priorizados por impacto real sobre las credenciales y recursos cloud expuestos, junto con recomendaciones de hardening operativas. Si necesita validar la exposición SSRF de sus aplicaciones cloud o cerrar la cadena de explotación contra metadata services antes de que un atacante la descubra, contacte con nuestro equipo desde esta página.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.