El SSRF (Server Side Request Forgery o falsificación de petición en servidor) es un tipo de ataque que engaña a tu servidor para que haga peticiones HTTP a recursos internos que jamás deberían ser accesibles desde fuera. Imagina que alguien convierte tu propio backend en un proxy involuntario para escanear tu red interna, leer credenciales del servicio de metadatos de tu cloud o incluso pivotar hacia bases de datos que ni siquiera tienen IP pública.
Suena a ciencia ficción, pero el SSRF ocupa su propia categoría en el OWASP Top 10 desde la edición 2021 (A10:2021) y fue protagonista de una de las brechas de seguridad más sonadas de la última década: el caso Capital One en 2019.
Lo peor del asunto es que muchas aplicaciones web tienen funcionalidades legítimas que hacen peticiones a URLs externas —importar una imagen, previsualizar un enlace, conectar con una API— y ahí es exactamente donde el atacante mete la cuña. Tu servidor, obediente, hace la petición sin rechistar.
Cómo funciona un ataque SSRF paso a paso
El mecanismo es absurdamente simple. El atacante localiza un endpoint de tu aplicación que acepta una URL como parámetro y la procesa en el lado del servidor. Puede ser un campo de "importar imagen desde URL", un webhook, un generador de PDFs que renderiza contenido remoto o cualquier funcionalidad que haga un fetch, curl o equivalente en backend.
Donde tú esperas que el usuario ponga https://ejemplo.com/foto.jpg, el atacante introduce algo como http://169.254.169.254/latest/meta-data/ (el endpoint de metadatos de AWS) o http://localhost:6379/ para hablar directamente con tu Redis. Tu servidor, que tiene acceso a la red interna, ejecuta la petición y devuelve la respuesta al atacante. Así de fácil.
Los tipos principales de server side request forgery son:
- SSRF básico (in-band): la respuesta del recurso interno se devuelve directamente al atacante en la respuesta HTTP.
- SSRF ciego (blind/out-of-band): el servidor hace la petición, pero la respuesta no se muestra al atacante. Aquí se recurre a técnicas como DNS exfiltration o callbacks a servidores controlados (herramientas como Burp Collaborator o interactsh son habituales).
- SSRF semi-ciego: no ves el contenido de la respuesta, pero sí puedes inferir información por el código de estado, el tiempo de respuesta o mensajes de error.
El caso Capital One y por qué SSRF en cloud es devastador
Si quieres entender la magnitud real de un ataque SSRF en cloud, el caso Capital One (2019, sin CVE asignado públicamente pero ampliamente documentado) es el ejemplo canónico. Una atacante explotó un SSRF en un WAF mal configurado de la entidad financiera para acceder al servicio de metadatos de instancia de AWS (169.254.169.254). Desde ahí obtuvo credenciales temporales del rol IAM asociado a la instancia EC2, lo que le permitió acceder a buckets S3 con datos de más de 100 millones de clientes.
Este caso expuso un problema estructural: los servicios de metadatos de los proveedores cloud (AWS, GCP, Azure) son accesibles mediante peticiones HTTP simples desde cualquier proceso que corra dentro de la instancia. Si tu aplicación es vulnerable a falsificación de petición en servidor, el atacante puede pedir esas credenciales como quien pide la hora. AWS respondió implementando IMDSv2, que requiere un token previo obtenido con un PUT (lo que dificulta enormemente el SSRF), pero la adopción no es universal y los otros proveedores han seguido caminos similares con distintos niveles de protección.
Otros CVEs relevantes de SSRF incluyen:
- CVE-2021-26855 (ProxyLogon): la cadena de vulnerabilidades en Microsoft Exchange que comenzaba con un SSRF y que fue explotada masivamente por grupos APT. Permitía acceder al backend de Exchange sin autenticación.
- CVE-2023-42793: SSRF en JetBrains TeamCity que permitía bypass de autenticación y ejecución remota de código.
- CVE-2024-21893: SSRF en Ivanti Connect Secure, explotado activamente y añadido al catálogo KEV de CISA.
Si te interesa cómo otros ataques a nivel de servidor pueden encadenarse con técnicas como esta, el artículo sobre CSRF y cómo ejecuta acciones en tu nombre complementa bien esta lectura —de hecho, SSRF y CSRF comparten filosofía: ambos abusan de la confianza depositada en un actor legítimo.
Vectores de ataque y técnicas de bypass
Bloquear el SSRF no es tan sencillo como filtrar "localhost" y "127.0.0.1" de las URLs entrantes. Los atacantes llevan años perfeccionando técnicas de bypass que harían llorar a más de un desarrollador:
| Técnica | Ejemplo | Qué hace |
|---|---|---|
| Representaciones alternativas de IP | http://0x7f000001/, http://2130706433/ | Hex y decimal de 127.0.0.1 |
| IPv6 localhost | http://[::1]/ | Elude filtros que solo buscan IPv4 |
| DNS rebinding | Dominio que alterna entre IP pública e interna | Pasa la validación inicial y redirige después |
| Redirecciones HTTP | URL externa que responde 302 hacia http://169.254.169.254/ | El filtro valida el dominio externo, pero el servidor sigue la redirección |
| URL encoding | http://localhost%2523@attacker.com/ | Confunde parsers de URL mal implementados |
| Protocolos alternativos | gopher://, file:///etc/passwd, dict:// | No todo SSRF va por HTTP |
El protocolo gopher:// merece mención especial: permite construir peticiones TCP arbitrarias, lo que significa que un SSRF con soporte gopher puede hablar con Redis, memcached, SMTP o cualquier servicio TCP interno enviando comandos directamente. Herramientas como Gopherus automatizan la generación de payloads para estos escenarios.
Y hablando de cadenas de ataque, un SSRF puede servir como punto de entrada para acceder a paneles de administración internos que no tienen autenticación porque "solo son accesibles desde la red interna". El mismo razonamiento peligroso que lleva a no proteger correctamente las dependencias de software, como se explica en el artículo sobre dependency confusion y ataques a través de paquetes npm y PyPI.
Cómo protegerte: defensas que funcionan
La defensa contra server side request forgery requiere múltiples capas. Ninguna medida individual es suficiente —los bypasses que hemos visto lo demuestran—, pero combinadas reducen la superficie de ataque drásticamente.
- Validación estricta de URLs en servidor: parsea la URL, resuelve el DNS y valida que la IP resultante no sea privada (RFC 1918), de loopback, link-local (169.254.x.x) ni de cualquier rango reservado. Haz esta validación después de resolver el DNS, no antes, para evitar DNS rebinding.
- Allowlist sobre denylist: si tu aplicación solo necesita conectarse a dominios concretos (por ejemplo, la API de un proveedor), mantén una lista blanca. Las listas negras siempre se quedan cortas.
- IMDSv2 en AWS (o equivalente): si corres en cloud, activa IMDSv2 y desactiva la v1. En GCP, usa la cabecera
Metadata-Flavor: Googleobligatoria. En Azure, elMetadata: trueheader. Esto no previene el SSRF, pero limita enormemente lo que el atacante puede obtener. - Segmentación de red: tu aplicación web no debería poder hablar con la base de datos de producción directamente por IP. Usa security groups, VPCs y firewalls internos para limitar qué puede conectarse con qué.
- Desactivar protocolos innecesarios: si usas librerías HTTP, asegúrate de que solo permiten
http://yhttps://. Bloqueagopher://,file://,dict://y cualquier otro protocolo que no necesites. - No devolver respuestas raw: si tu funcionalidad necesita procesar una URL externa (por ejemplo, descargar una imagen), no devuelvas el contenido tal cual al usuario. Procesa el recurso (valida que sea realmente una imagen, por ejemplo) y sirve tu propia copia.
Para auditar tu propia infraestructura, herramientas como Burp Suite, SSRFmap y el módulo SSRF de Nuclei te permiten testear estos vectores de forma automatizada. Si buscas un kit más amplio de herramientas gratuitas, revisa nuestra guía de herramientas de ciberseguridad gratuitas.
Preguntas frecuentes
¿Cuál es la diferencia entre SSRF y CSRF?
El CSRF (Cross-Site Request Forgery) engaña al navegador del usuario para que haga una petición no deseada. El SSRF engaña al servidor para que haga una petición no deseada. En CSRF el vector es el usuario autenticado; en SSRF el vector es el propio servidor y su acceso privilegiado a la red interna.
¿Puede un WAF protegerme contra ataques SSRF?
Un WAF puede detectar patrones conocidos de SSRF (peticiones a IPs internas, protocolos sospechosos), pero no es una solución completa. Las técnicas de bypass como DNS rebinding o redirecciones HTTP pueden eludir la mayoría de WAFs. La protección debe implementarse a nivel de aplicación y de red, no solo en el perímetro.
¿Las aplicaciones en cloud son más vulnerables al SSRF?
No necesariamente más vulnerables al SSRF en sí, pero las consecuencias suelen ser peores. Los servicios de metadatos de instancia (IMDS) exponen credenciales temporales que pueden dar acceso a toda la infraestructura cloud. Un SSRF en un servidor on-premise escanea la red interna; un SSRF en cloud puede otorgar acceso a decenas de servicios gestionados con un solo request.
¿Qué lenguajes o frameworks son más susceptibles al SSRF?
El SSRF no es un problema del lenguaje, sino del diseño de la aplicación. Dicho esto, lenguajes como PHP (con file_get_contents y wrappers de protocolo) y Python (con requests siguiendo redirecciones por defecto) facilitan el error si el desarrollador no implementa validaciones. Frameworks modernos como Django o Laravel no incluyen protección SSRF nativa —es responsabilidad del desarrollador.
El siguiente paso
Abre tu código fuente ahora mismo y busca todas las funciones que aceptan una URL como entrada y hacen una petición del lado del servidor: curl_exec, file_get_contents, requests.get, http.get, fetch en backend. Haz una lista. Para cada una, pregúntate: ¿estoy validando la IP resuelta contra rangos internos? ¿Estoy siguiendo redirecciones ciegamente? ¿Permito protocolos que no sean HTTP/HTTPS? Si la respuesta a cualquiera de esas preguntas es "no" o "no lo sé", ya tienes tu primera tarea de seguridad para mañana. Si además corres en AWS, GCP o Azure, verifica que tu servicio de metadatos use la versión protegida —esa sola acción habría evitado el desastre de Capital One.
