Labs de SSRF

Server-Side Request Forgery (SSRF)

¿Qué es SSRF?

El SSRF permite forzar al servidor a realizar peticiones HTTP a destinos arbitrarios, incluyendo servicios internos, metadatos de cloud providers y redes privadas. Es especialmente crítico en entornos cloud por el acceso a credenciales IAM.

¿Por qué practicar SSRF?

Con la migración masiva al cloud (AWS, GCP, Azure), el SSRF se ha convertido en una vulnerabilidad de alto impacto. Un SSRF que accede a metadatos cloud puede dar acceso a toda la infraestructura. Los bounties por SSRF crítico superan los $5,000 con frecuencia.

¿Qué aprenderás con los labs de SSRF?

Aprenderás a identificar features que aceptan URLs (webhook validators, image fetchers, PDF generators), bypassear blacklists con IPv6/decimal/octal, abusar metadata endpoints (169.254.169.254 + IMDSv1, GCP, Azure), y detectar SSRF blind via Burp Collaborator.

Tipos de SSRF que cubrimos

Basic SSRF
El servidor te devuelve la respuesta de la URL que le pasas. Lees /etc/passwd via file:// o internos via http://localhost.
Blind SSRF
El servidor hace la petición pero no te devuelve la respuesta. Detectas vía DNS callback (Burp Collaborator).
Cloud metadata
AWS IMDSv1: GET 169.254.169.254/latest/meta-data/iam/security-credentials/ → IAM creds.
Gopher / SMTP smuggling
Protocolos exóticos para hablar con servicios internos no-HTTP (Redis, Memcached, SMTP).
DNS rebinding
Bypass de validación pre-fetch: tu DNS responde IP pública la primera vez, IP interna la segunda.

¿Cómo encontrar y explotar SSRF?

Playbook práctico — del recon a la prueba de concepto.

1
Encontrar la feature que fetchea URLs
Webhooks, validadores de URL, previsualizadores de enlaces, importadores por URL, generadores de PDF/imágenes y avatares 'desde URL'. Cualquier parámetro con una URL es candidato.
```
POST /api/webhook   {"url":"https://x.oast.fun"}   →   ¿llega el callback?
```
2
Confirmar el alcance interno
Apunta a localhost y a la metadata para ver si el servidor llega a recursos internos no expuestos al exterior.
```
url=http://127.0.0.1:80   ·   url=http://169.254.169.254/
```
3
Robar credenciales cloud
Si hay IMDSv1, lee el rol IAM y sus credenciales temporales: acceso directo a la infraestructura.
```
http://169.254.169.254/latest/meta-data/iam/security-credentials/
```
4
Bypassear la blacklist
Si filtran 127.0.0.1/localhost, usa representaciones alternativas de la IP, IPv6, redirects o un dominio que resuelva a interno.
```
http://2130706433/   ·   http://[::1]/   ·   http://127.0.0.1.nip.io/
```
5
Explotar el SSRF ciego
Cuando no devuelve la respuesta, usa Burp Collaborator para confirmar el callback y mapea puertos internos por diferencias de tiempo/estado.
```
url=http://x.burpcollaborator.net   →   interacción DNS+HTTP recibida
```
6
Pivotar con gopher
Para hablar con servicios no-HTTP (Redis, Memcached, SMTP), forja el protocolo con gopher:// y consigue escritura/RCE.
```
gopher://127.0.0.1:6379/_SET%20x%20payload
```

Aprende la teoría

Academy: Server-Side Request Forgery (SSRF)

Cargando labs...

Ver en catálogo completo →

Preguntas frecuentes

¿Qué es un SSRF?

Server-Side Request Forgery es una vulnerabilidad que permite forzar al servidor a hacer peticiones HTTP (u otros protocolos) a destinos elegidos por el atacante, incluyendo servicios internos, la metadata cloud y redes privadas inaccesibles desde fuera.

¿Cómo se explota un SSRF?

Se introduce una URL controlada en una feature que el servidor consulta. Apuntando a http://169.254.169.254 se roban credenciales IAM en AWS; a http://localhost se alcanzan paneles internos; y con gopher:// se interactúa con Redis o SMTP para escalar a RCE.

¿Cómo encontrar SSRF en bug bounty?

Localiza cualquier parámetro que acepte una URL (webhooks, fetch de imágenes, previews, generadores de PDF) y prueba un dominio de Burp Collaborator. Si recibes el callback, tienes SSRF; luego intenta llegar a metadata e internos.

¿Cómo prevenir el SSRF?

Usa allowlist estricta de dominios/IPs, resuelve y valida la IP final tras seguir redirects, bloquea rangos internos y link-local (169.254.0.0/16, 127.0.0.0/8), exige IMDSv2 en AWS y deshabilita protocolos como file:// y gopher://.

¿Diferencia entre SSRF y Open Redirect?

En el SSRF es el servidor quien hace la petición (puede alcanzar internos y metadata). En el Open Redirect es el navegador de la víctima quien es redirigido. Por eso un Open Redirect suele usarse para bypassear la allowlist de un SSRF y encadenarlos.