Vulnerabilidad SSRF en n8n
Por qué la entrada de usuario en URLs HTTP puede exponer tu red interna
¿Qué es este problema?
Server-Side Request Forgery (SSRF) ocurre cuando la entrada controlada por el usuario se usa para construir URLs de solicitud HTTP. Los atacantes pueden abusar de esto para acceder a servicios internos, endpoints de metadatos de cloud o APIs internas que no deberían ser accesibles públicamente.
Patrones peligrosos:
•URL de HTTP Request usando $json.url desde webhook•Construcción dinámica de URL desde entrada de formulario•Hostnames proporcionados por usuario sin validación•Seguimiento de redirects sin verificación de URL
¿Por qué es peligroso?
Acceso a red interna
Los atacantes pueden acceder a servicios internos (bases de datos, APIs) que solo son accesibles desde dentro de tu red.
Exposición de metadatos cloud
Acceder a 169.254.169.254 puede exponer credenciales AWS/GCP y metadatos de instancia.
Escaneo de puertos
Los atacantes pueden usar tu servidor para escanear puertos internos y descubrir servicios.
Bypass de firewall
Las solicitudes desde tu servidor evitan firewalls externos, accediendo a recursos de otro modo protegidos.
Cómo solucionarlo
- 1
Validar URLs contra lista permitida
Solo permite solicitudes a dominios conocidos y confiables. Rechaza todos los demás.
- 2
Bloquear rangos IP internos
Rechaza URLs apuntando a localhost, 10.x.x.x, 172.16.x.x, 192.168.x.x y 169.254.x.x.
- 3
Deshabilitar redirects o validar
No sigas redirects automáticamente, o valida destinos de redirect contra las mismas reglas.
- 4
Usar parseo de URL
Parsea URLs apropiadamente y valida el componente hostname, no solo el string completo.
Escanea tu workflow ahora
Sube tu archivo JSON de n8n y detecta nodos HTTP usando URLs controladas por usuario.