SSRF es un problema de identidad en la nube, no solo un filtro de URL

En resumen: Una falsificación de solicitudes del lado del servidor puede convertir una función de obtención aparentemente inocente en una vía de acceso a servicios internos y credenciales en la nube. Las defensas duraderas restringen 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 obtienen contenido remoto para vistas previas de enlaces, webhooks, importaciones de documentos, procesamiento de imágenes y análisis de seguridad. El peligro comienza cuando un atacante controla cualquier parte del destino y el servidor puede acceder a redes a las que el atacante no puede llegar. La aplicación se convierte en un proxy que traslada la confianza del servidor al espacio interno.

Bloquear una lista breve de cadenas no es suficiente. 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 dirigida a una dirección de bucle invertido, un servicio privado o un punto de conexión de metadatos en la nube después de que la validación ya se haya superado.

Valide cada decisión de red

• Permita únicamente los esquemas y puertos necesarios, y rechace credenciales, fragmentos, sintaxis de host ambiguas y formatos de dirección no canónicos.
• Resuelva el nombre de host, clasifique cada dirección devuelta y rechace los rangos de bucle invertido, privados, de enlace local, multidifusión y reservados tanto para IPv4 como para IPv6.
• Vuelva a validar cada destino de redirección y fije la conexión a la dirección validada para que DNS no pueda cambiar entre la comprobación y la solicitud.
• Aplique límites de tamaño de respuesta, tipo de contenido, tiempo de espera y redirecciones para que una obtención permitida no pueda convertirse en una vía de agotamiento de recursos.

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

La validación de la aplicación evolucionará y puede sufrir regresiones, por lo que el entorno de ejecución necesita un límite de salida independiente. Un servicio de obtención dedicado, con una lista de permitidos restringida, 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 en la nube también son importantes. Exija protocolos de metadatos orientados a sesiones cuando sean compatibles, bloquee las rutas de metadatos en la capa de red y asigne a la carga de trabajo de obtención la identidad con los privilegios mínimos posibles. Si una solicitud llega a un punto de conexión interno de credenciales, debería haber 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 rápida. Un conjunto completo de pruebas SSRF abarca trucos de codificación, direcciones decimales y hexadecimales, notación IPv6 mixta, cadenas de redirecciones, cambios de DNS, discrepancias entre analizadores y nombres de host internos. También verifica que los fallos no filtren información mediante los tiempos de respuesta ni fragmentos del cuerpo.

El enfoque de KENSAI, basado primero en las pruebas, registra la clasificación del destino y la dirección real a la que se estableció la conexión. Esto convierte un bloqueo aparente en evidencia verificable de que la solicitud nunca cruzó el límite de red previsto.

Conclusión

Trate la obtención de contenido remoto como acceso privilegiado a la red. Valide y fije los destinos, vuelva a comprobar las redirecciones, restrinja el tráfico de salida y minimice la identidad de la carga de trabajo para que un solo error de análisis no pueda provocar una vulneración de la nube.