A10:2021 – Falsificación de Solicitud del Lado del Servidor (SSRF)

Resumen

Esta categoría se añadió desde la encuesta comunitaria Top 10 (#1). Los datos muestran una tasa de incidencia relativamente baja con una cobertura de pruebas superior a la media y calificaciones superiores a la media en cuanto a Exploit e Impacto. Dado que las nuevas entradas probablemente sean una única o pequeña agrupación de Enumeraciones de Debilidades Comunes (CWEs) para atención y concienciación, se espera que se les dé enfoque y puedan integrarse en una categoría más amplia en una futura edición.

Descripción

Las fallas SSRF (Server-Side Request Forgery) ocurren siempre que una aplicación web está obteniendo un recurso remoto sin validar la URL proporcionada por el usuario. Esto permite a un atacante forzar a la aplicación para que envíe una solicitud elaborada a un destino inesperado, incluso cuando esté protegida por un firewall, VPN u otro tipo de lista de control de acceso (ACL) de red.

A medida que las aplicaciones web modernas proporcionan a los usuarios finales características convenientes, la obtención de una URL se convierte en un escenario común. Como resultado, la incidencia de SSRF está aumentando. Además, la severidad de SSRF está aumentando debido a los servicios en la nube y a la complejidad de las arquitecturas.

Cómo prevenir

Los desarrolladores pueden prevenir SSRF implementando algunos o todos los siguientes controles de defensa en profundidad:

Desde la capa de red

Segmenta la funcionalidad de acceso a recursos remotos en redes separadas para reducir el impacto de SSRF.
Aplica políticas de firewall o reglas de control de acceso a la red de "denegar por defecto" para bloquear todo excepto el tráfico intranet esencial.
Sugerencias:
~ Establece una propiedad y un ciclo de vida para las reglas de firewall basadas en aplicaciones.
~ Registra todos los flujos de red aceptados y bloqueados en los firewalls (ver A09:2021-Fallas en el Registro y Monitoreo de Seguridad).

Desde la capa de aplicación:

Sanea y valida todos los datos de entrada proporcionados por el cliente.
Aplica el esquema de URL, el puerto y el destino con una lista de permisos positiva.
No envíes respuestas en bruto a los clientes.
Desactiva las redirecciones HTTP.
Sé consciente de la consistencia de la URL para evitar ataques como el DNS rebinding y las condiciones de carrera "time of check, time of use" (TOCTOU).

No mitigues SSRF mediante el uso de una lista de denegación o expresiones regulares. Los atacantes tienen listas de payloads, herramientas y habilidades para eludir las listas de denegación.

Medidas adicionales a considerar:

No implementes otros servicios relevantes para la seguridad en sistemas frontales (por ejemplo, OpenID). Controla el tráfico local en estos sistemas (por ejemplo, localhost).
Para frontends con grupos de usuarios dedicados y gestionables, utiliza cifrado de red (por ejemplo, VPNs) en sistemas independientes para considerar necesidades de protección muy altas.

Ejemplos de Escenarios de Ataque

Los atacantes pueden usar SSRF para atacar sistemas protegidos detrás de firewalls de aplicaciones web, firewalls o ACLs de red, utilizando escenarios como:

Escenario #1: Escaneo de puertos en servidores internos – Si la arquitectura de red no está segmentada, los atacantes pueden mapear redes internas y determinar si los puertos están abiertos o cerrados en servidores internos a partir de los resultados de conexión o del tiempo transcurrido para conectar o rechazar conexiones de payloads SSRF.

Escenario #2: Exposición de datos sensibles – Los atacantes pueden acceder a archivos locales o servicios internos para obtener información sensible, como file:///etc/passwd y http://localhost:28017/.

Escenario #3: Acceso al almacenamiento de metadatos de servicios en la nube – La mayoría de los proveedores de la nube tienen almacenamiento de metadatos, como http://169.254.169.254/. Un atacante puede leer los metadatos para obtener información sensible.

Escenario #4: Compromiso de servicios internos – El atacante puede abusar de los servicios internos para realizar ataques adicionales, como Ejecución Remota de Código (RCE) o Denegación de Servicio (DoS).