Qué es SSRF (Server-Side Request Forgery): riesgos, ejemplos y mitigación
SSRF (Server-Side Request Forgery) es una vulnerabilidad web que permite a un atacante manipular al servidor de la aplicación para que haga peticiones HTTP hacia destinos arbitrarios, internos o externos, en nombre del propio servidor. El atacante no ataca la red directamente: se esconde detrás del servidor comprometido y lo usa como proxy involuntario.
SSRF aparece en el OWASP Top 10 desde 2021 con entrada propia (A10), lo que refleja su presencia creciente en entornos cloud y microservicios. Si ya tienes base de hacking web, esta guía te explica cómo funciona en profundidad, qué impacto real puede tener y cómo defenderla.
Por qué existe SSRF: la raíz del problema
El patrón que genera SSRF es sencillo: la aplicación recibe una URL (o parte de ella) como entrada controlada por el usuario y, sin validarla bien, hace una petición a esa URL desde el propio servidor.
Escenarios típicos donde aparece:
- Funciones de preview de URLs o de importación de imágenes remotas.
- Webhooks configurables por el usuario.
- Integraciones con APIs externas donde el endpoint lo elige el cliente.
- Conversores de HTML a PDF que renderizan URLs arbitrarias.
- Funciones de «compartir» que hacen fetch de la URL destino para generar una vista previa social.
El servidor suele tener acceso privilegiado a la red interna: puede llegar a servicios que no están expuestos al exterior (bases de datos, paneles de administración, endpoints de metadatos de nube…). El atacante usa ese acceso a su favor.
Cómo funciona SSRF: ejemplo paso a paso
Imagina una aplicación de comercio electrónico que comprueba el stock de un proveedor externo. El parámetro url se pasa directamente al backend:
GET /producto/disponibilidad?url=https://proveedor.com/api/stock/123 HTTP/1.1
Host: tienda.ejemplo.com
El servidor hace un curl o equivalente interno hacia esa URL y devuelve el resultado. Un atacante intercepta la petición con Burp Suite y modifica el parámetro:
GET /producto/disponibilidad?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/rol-produccion HTTP/1.1
Host: tienda.ejemplo.com
Si el servidor corre en AWS y no hay protección, responde con las credenciales IAM temporales del rol de producción. El atacante ya tiene acceso completo a la cuenta de AWS.
Otro ejemplo clásico: apuntar al loopback para acceder a servicios internos:
url=http://localhost:8080/admin
url=http://192.168.1.1/router-admin
url=http://interno.empresa.local/api/usuarios
El servidor hace estas peticiones desde su propio contexto de red, donde esos servicios sí son accesibles y, con frecuencia, no piden autenticación porque se asume que solo el propio host llega ahí.
Para profundizar en las técnicas de interceptación y manipulación de peticiones, consulta nuestra guía de Burp Suite.
Impacto real: qué puede hacer un atacante
El impacto de SSRF va mucho más allá de leer archivos internos. Según OWASP (A10:2021), las consecuencias más graves incluyen:
- Acceso a servicios internos no expuestos: bases de datos Redis, ElasticSearch o paneles de administración sin autenticación.
- Robo de credenciales de cloud: el endpoint
http://169.254.169.254/(AWS, GCP, Azure) devuelve tokens IAM, secretos de configuración y datos de identidad del servidor. - Port scanning interno: variando la IP y el puerto en la URL, el atacante puede mapear qué servicios están abiertos en la red interna (tiempo de respuesta frente a conexión rechazada).
- Lectura de archivos locales: con el esquema
file://si el cliente HTTP del backend lo soporta (file:///etc/passwd). - Movimiento lateral: desde el servidor comprometido como pivote hacia el resto de la red corporativa.
- Bypass de WAF y controles perimetrales: el tráfico sale desde dentro, no desde el exterior.
«SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list.»
Tipos de SSRF
SSRF básico (in-band)
La respuesta de la petición interna se devuelve directamente en la respuesta HTTP al atacante. Es el caso más fácil de explotar y detectar: el atacante ve el contenido del servicio interno directamente en la respuesta de la aplicación.
SSRF ciego (blind / out-of-band)
La aplicación hace la petición interna pero no devuelve la respuesta al atacante. La explotación es más difícil, pero sigue siendo posible:
- Se usa un servidor de escucha externo (Burp Collaborator, Interactsh) para detectar si la petición llega, confirmando la vulnerabilidad.
- La exfiltración de datos se hace a través de canales secundarios: codificando la respuesta en subdominios DNS (
dato.tuservidor.com) o por tiempo de respuesta. - Basta para confirmar que existen servicios internos (port scan ciego).
Más del 50% de los SSRF en entornos reales son ciegos, lo que complica bastante identificarlos en un pentest.
Ejemplo práctico en laboratorio (PortSwigger Academy)
Aviso: practica únicamente en entornos autorizados. PortSwigger Web Security Academy ofrece laboratorios gratuitos y legales.
El laboratorio «Basic SSRF against the local server» de PortSwigger ilustra el caso más común:
- Abre el laboratorio en portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost.
- Localiza la funcionalidad de comprobación de stock. Intercepta la petición con Burp Suite.
- El parámetro
stockApicontiene una URL completa al servicio de stock. - Modifica su valor a
http://localhost/admin. - El servidor devuelve el panel de administración interno, que en condiciones normales solo es accesible desde localhost.
- Desde ahí, elimina el usuario carlos completando el objetivo del laboratorio.
Para más contexto sobre el entorno y herramientas de pentesting web, revisa nuestra guía completa de hacking web y el curso de hacking web.
Cómo prevenir SSRF: defensas reales
SSRF es una de las vulnerabilidades peor defendidas porque los desarrolladores recurren a listas negras que se saltan con facilidad. Estas son las defensas que de verdad funcionan:
1. Allow-list estricta de destinos (la defensa más efectiva)
No valides lo que no está permitido: define explícitamente qué dominios o IPs puede consultar el servidor. Cualquier cosa fuera de esa lista se rechaza. Si el servidor solo necesita llamar a api.proveedor.com, permite únicamente ese dominio y ninguno más.
// Pseudocódigo — validación de allow-list
const DOMINIOS_PERMITIDOS = ["api.proveedor.com", "cdn.ejemplo.com"];
const url = new URL(inputDelUsuario);
if (!DOMINIOS_PERMITIDOS.includes(url.hostname)) {
throw new Error("Destino no permitido");
}
2. Bloquear rangos privados y el endpoint de metadatos
Si no puedes implementar allow-list, al menos bloquea en el código, no únicamente en el firewall:
127.0.0.0/8— loopback10.0.0.0/8,172.16.0.0/12,192.168.0.0/16— redes privadas RFC 1918169.254.169.254— IMDS (Instance Metadata Service) de AWS/GCP/Azurefd00::/8— ULA IPv6- Esquemas no-HTTP:
file://,gopher://,dict://,ftp://
3. Resolver la URL y revalidar la IP resultante
Un error frecuente es validar el hostname antes de resolver DNS, pero el atacante puede usar su propio servidor DNS para que mivuln.attacker.com resuelva a 192.168.1.1 (DNS rebinding). La solución: resolver el nombre a IP antes de validar y bloquear según la IP resuelta, no el nombre.
4. Deshabilitar redirecciones HTTP
Un atacante puede apuntar a una URL externa que redirige a una IP interna. El cliente HTTP debe seguir como máximo 0 redirecciones, o verificar cada destino intermedio con la misma allow-list.
5. Normalizar y parsear la URL antes de validar
Muchos bypasses explotan URLs malformadas. Usa siempre un parser de URL robusto (el propio del lenguaje) y trabaja sobre la URL normalizada. Nunca uses expresiones regulares caseras para validar URLs.
6. Segmentación de red y mínimo privilegio
A nivel de infraestructura: los servidores de aplicación no deben tener acceso directo a bases de datos internas, paneles de admin o la red de gestión. El daño de un SSRF se limita muchísimo si el servidor afectado no puede llegar a servicios críticos. Esta capa de defensa funciona incluso si el código tiene un fallo. Para más contexto cloud, visita nuestra sección sobre seguridad en la nube.
7. Deshabilitar el IMDS v1 en cloud y usar IMDSv2
En AWS, IMDSv2 exige un token de sesión que se obtiene con una petición PUT antes de consultar 169.254.169.254. Un SSRF básico (que solo hace GET) no puede obtener ese token, lo que elimina el vector de robo de credenciales IAM. Configura siempre HttpTokens=required en tus instancias EC2.
Errores comunes: listas negras que no funcionan
El error más frecuente al intentar mitigar SSRF es usar una blacklist de patrones. El atacante puede saltársela de varias formas:
| Objetivo del atacante | Técnica de bypass de blacklist | Defensa correcta |
|---|---|---|
| Acceder a 127.0.0.1 | http://127.1/, http://0x7f000001/, http://2130706433/, http://[::1]/ |
Allow-list + resolver IP y comparar rangos |
Acceder al IMDS de AWS (169.254.169.254) |
DNS personalizado que resuelve a esa IP; representación decimal/hex de la IP | Bloquear por IP resuelta; usar IMDSv2 |
| Leer archivos locales | file:///etc/passwd, dict://localhost:11211/ |
Permitir solo esquemas https:// |
| Saltar la validación del dominio | https://attacker.com@interno.com/, https://interno.com.attacker.com/ |
Usar el hostname del objeto URL parseado, no la cadena en crudo |
| Acceder a IPs privadas vía redirección | URL externa que redirige a 192.168.1.1 |
Deshabilitar redirecciones o revalidar cada hop |
Vídeo recomendado
Para ver una demostración práctica de SSRF con laboratorios de PortSwigger, este vídeo en español del canal Mr.RedSmasher en YouTube (0JagGd3dx84) es un buen punto de partida: cubre la explicación teórica y varias demos con herramientas reales.
📚 ¿Quieres practicarlo en un laboratorio legal, paso a paso? Lo trabajamos en el Módulo 6: CSRF y SSRF de nuestro Curso de Hacking Web.
Preguntas frecuentes
¿Qué diferencia hay entre SSRF y CSRF?
Son vulnerabilidades distintas. CSRF (Cross-Site Request Forgery) engaña al navegador de una víctima autenticada para que haga peticiones en su nombre al servidor. SSRF engaña al propio servidor para que haga peticiones a destinos arbitrarios. En SSRF el atacante no necesita ningún usuario víctima: actúa directamente sobre el servidor.
¿Cómo sé si una aplicación es vulnerable a SSRF?
Busca parámetros que contengan URLs, IPs o nombres de host: url=, redirect=, fetch=, src=, endpoint=, callback=. Prueba a sustituirlos por http://127.0.0.1/ o por una URL de Burp Collaborator y observa si el servidor hace peticiones hacia esos destinos. En un SSRF ciego, la única señal puede ser una interacción DNS o HTTP en tu servidor de escucha.
¿El firewall no me protege de SSRF?
No. Un firewall perimetral no protege contra SSRF porque la petición sale desde el servidor de aplicación, que normalmente tiene acceso a la red interna. El firewall ve tráfico «legítimo» del servidor hacia servicios internos. La protección debe estar en el código (validación de URL) y en la segmentación de red (que el servidor de app no pueda llegar a infraestructura crítica).
¿Qué es el endpoint de metadatos y por qué es tan peligroso?
Los proveedores de cloud (AWS, GCP, Azure) exponen un endpoint especial en http://169.254.169.254/ que devuelve información de configuración de la instancia, incluyendo credenciales IAM temporales. Estas credenciales pueden tener permisos amplios sobre la cuenta cloud. Si un atacante consigue que el servidor haga una petición a esa IP, puede robar las credenciales y comprometer toda la infraestructura cloud del objetivo.
¿SSRF es solo una vulnerabilidad de aplicaciones web?
No. SSRF puede aparecer en cualquier sistema que haga peticiones de red basándose en entrada del usuario: aplicaciones móviles con backend propio, herramientas de CI/CD, sistemas de procesado de documentos (PDF, XML), aplicaciones de IoT con conectividad cloud, o cualquier servicio que haga peticiones HTTP hacia URLs que controle el usuario. El patrón se repite siempre igual: entrada controlada por el atacante → petición de red desde el servidor.
Aviso ético y legal
Las técnicas descritas en este artículo tienen una finalidad exclusivamente educativa. Hacer pruebas de SSRF o cualquier otra técnica de hacking en sistemas sin autorización expresa y por escrito del propietario es un delito en España tipificado en el artículo 197 bis del Código Penal, con penas de hasta tres años de prisión. Practica siempre en entornos de laboratorio autorizados como PortSwigger Web Security Academy, DVWA o máquinas de HackTheBox/TryHackMe.
