SSRF — Server-Side Request Forgery — convierte a tu propio servidor en el proxy del atacante. Donde sea que tu app traiga una URL que otro provee, un atacante puede apuntarla hacia adentro — a servicios que nunca deberían ser alcanzables desde afuera.

Cómo funciona

Tu app toma una URL y la trae del lado del servidor — para un preview, importar datos, o un webhook provisto por el usuario. Si traés cualquier URL que te dan, el atacante provee una interna:

    POST /api/import  { "url": "http://169.254.169.254/latest/meta-data/..." }
# → tu servidor trae la metadata del cloud y puede filtrar credenciales

Como la petición sale desde adentro de tu red, los firewalls confían. El SSRF puede llegar a paneles internos, bases de datos y — lo más peligroso — el endpoint de metadata (169.254.169.254), que puede entregar credenciales IAM.

Cómo prevenir SSRF

  1. Allow-list de destinos. Solo traé hosts que permitís explícitamente.
  2. Bloqueá IPs privadas y reservadas (127/8, 10/8, 172.16/12, 192.168/16, link-local y 169.254.169.254).
  3. Re-verificá la IP resuelta tras resolver el hostname (contra DNS rebinding).
  4. Restringí esquemas (solo https/http; bloqueá file://, gopher://).
  5. No sigas redirects no confiables y usá IMDSv2 en AWS.

El SSRF se esconde en features de conveniencia. Nurbak escanea tu app por endpoints propensos a SSRF y el resto del checklist de seguridad de APIs.

Artículos relacionados