SSRF es un problema de identidad cloud, no solo un filtro de URL

En resumen: Una falsificación de solicitudes del lado del servidor puede convertir una función de descarga aparentemente inocente en acceso a servicios internos y credenciales cloud. Una defensa duradera limita conjuntamente los destinos, las redirecciones, la resolución DNS y la identidad de la carga de trabajo.

La función vulnerable suele parecer inofensiva

Las aplicaciones descargan contenido remoto para vistas previas de enlaces, webhooks, importación de documentos, procesamiento de imágenes y análisis de seguridad. El peligro comienza cuando un atacante controla alguna parte del destino y el servidor puede alcanzar redes inaccesibles para el atacante. La aplicación se convierte entonces en un proxy que transporta la confianza del servidor hacia el espacio interno.

Bloquear una lista breve de cadenas no basta. Las representaciones alternativas de direcciones IP, los formatos IPv6, las redirecciones, la sintaxis de información de usuario y la revinculación DNS pueden transformar una URL aparentemente pública en una solicitud a una dirección de bucle local, un servicio privado o un endpoint de metadatos cloud después de superar la validación.

Valide cada decisión de red

• Permita únicamente los esquemas y puertos necesarios; rechace credenciales, fragmentos, nombres de host ambiguos y direcciones no canónicas.
• Resuelva el nombre de host, clasifique todas las direcciones devueltas y rechace rangos de bucle local, privados, link-local, multicast y reservados, tanto en IPv4 como en IPv6.
• Vuelva a validar cada destino de redirección y fije la conexión a la dirección validada para impedir que DNS cambie entre la comprobación y la solicitud.
• Imponga límites de tamaño de respuesta, tipo de contenido, tiempo de espera y redirecciones para evitar que una descarga permitida agote recursos.

Los controles de red deben respaldar las comprobaciones de la aplicación

La validación de la aplicación evoluciona y puede sufrir regresiones, por lo que el entorno de ejecución necesita un límite de salida independiente. Un servicio de descarga dedicado, con una lista de permisos estrecha, una ruta de red aislada y sin acceso a los planos de control de producción, reduce drásticamente el alcance de un error del analizador.

Las protecciones de metadatos cloud también importan. Exija protocolos de metadatos orientados a sesión cuando estén disponibles, bloquee las rutas de metadatos en la capa de red y conceda a la carga de descarga la identidad mínima posible. Si una solicitud llega a un endpoint interno de credenciales, debería encontrar poco o nada útil que robar.

Pruebe clases de evasión, no una sola carga útil

Una única solicitud a una dirección de metadatos conocida es solo una prueba superficial. Una suite SSRF completa cubre trucos de codificación, direcciones decimales y hexadecimales, notación IPv6 mixta, cadenas de redirección, cambios de DNS, discrepancias entre analizadores y nombres de host internos. También comprueba que los fallos no filtren tiempos de respuesta ni fragmentos del cuerpo.

El enfoque de KENSAI centrado en pruebas registra la clasificación del destino y la dirección a la que realmente se conectó. Así, un bloqueo aparente se convierte en evidencia verificable de que la solicitud nunca cruzó el límite de red previsto.

Conclusión

Trate la descarga remota como acceso privilegiado a la red. Valide y fije los destinos, vuelva a comprobar las redirecciones, restrinja la salida y minimice la identidad de la carga para que un error de análisis no termine en un compromiso cloud.