SSRF a Metadata de Cloud

Tu app hace fetch de URLs proporcionadas por el usuario sin bloquear endpoints de metadata de cloud como 169.254.169.254, dejando a los atacantes robar tus credenciales cloud vía SSRF.

Cómo Funciona

Cada VM en la nube (AWS EC2, GCP, Azure) tiene un servicio de metadata interno en una dirección link-local (169.254.169.254). Este servicio devuelve las credenciales IAM de la instancia, incluyendo claves de acceso AWS temporales, con un simple HTTP GET — sin autenticación requerida desde dentro de la instancia. Si tu app hace fetch de cualquier URL que un usuario proporcione sin validarla, un atacante manda http://169.254.169.254/latest/meta-data/iam/security-credentials/ y roba tus credenciales cloud.

Código Vulnerable

// MAL: haciendo fetch de URL proporcionada por el usuario sin validación
export async function POST(req: Request) {
  const { url } = await req.json();
  // El atacante manda: http://169.254.169.254/latest/meta-data/iam/security-credentials/
  const response = await fetch(url);
  return Response.json({ content: await response.text() });
}

Código Seguro

// BIEN: valida que la URL sea externa y no sea una dirección privada/metadata
function isSafeUrl(url: string): boolean {
  const parsed = new URL(url);
  const blocklist = ['169.254.169.254', 'metadata.google.internal', '169.254.170.2'];
  return parsed.protocol === 'https:' && !blocklist.includes(parsed.hostname);
}
export async function POST(req: Request) {
  const { url } = await req.json();
  if (!isSafeUrl(url)) return Response.json({ error: 'URL inválida' }, { status: 400 });
  const response = await fetch(url);
  return Response.json({ content: await response.text() });
}

Ejemplo Real

La brecha de Capital One de 2019 fue causada exactamente por esto: una vulnerabilidad SSRF permitió al atacante golpear el endpoint de metadata de EC2 y recuperar credenciales IAM, que luego se usaron para descargar 100 millones de registros de clientes desde S3. Sigue siendo uno de los ataques de SSRF-a-toma-de-control-cloud más documentados.

Cómo Prevenirlo

Bloquea requests a 169.254.169.254, metadata.google.internal, 169.254.170.2 y fd00:ec2::254 (equivalente IPv6)
También bloquea rangos de IP privados: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 y localhost
Usa IMDSv2 en AWS EC2 que requiere un request PUT con un token de sesión — los simples requests GET al endpoint de metadata fallan
Aplica roles IAM de mínimos privilegios a tus instancias — incluso si las credenciales son robadas, el radio de impacto es limitado
Valida que las URLs proporcionadas por el usuario usen HTTPS y resuelvan a direcciones IP públicas antes de hacer fetch

Tecnologías Afectadas

Node.jsPython

Data Hogo detecta esta vulnerabilidad automáticamente.

Escanea Tu Repo Gratis

Vulnerabilidades Relacionadas

Bucket S3 con Acceso Público

critical

Tu bucket de S3 es públicamente legible debido a un ACL público, configuración de Block Public Access deshabilitada o una política de bucket con wildcard — cualquiera en internet puede listar y descargar tus archivos.

CWE-284OWASP A05:2021

Credenciales AWS Hardcodeadas

critical

Las claves de acceso de AWS (que empiezan con AKIA) o las claves de acceso secretas están hardcodeadas en tu código fuente, dando a cualquiera que lea el código acceso completo a tu cuenta de AWS.

CWE-798OWASP A02:2021

Política IAM Excesivamente Permisiva

high

Tu política IAM usa Action: '*' o Resource: '*', otorgando muchos más permisos de los necesarios y convirtiendo cualquier fuga de credenciales en una toma de control completa de la cuenta.

CWE-269OWASP A01:2021

CORS Mal Configurado en Almacenamiento Cloud

medium

Tu bucket de S3 o GCS tiene CORS configurado con origin: '*' o AllowedMethods: ['*'], permitiendo que cualquier sitio web lea las respuestas de tu almacenamiento y potencialmente acceda a datos privados.

CWE-942OWASP A05:2021