Server-side request forgery (SSRF)

Las aplicaciones traen cosas. Pintan la vista previa de un enlace, importan un documento desde una URL, llaman a un webhook que configuró el cliente, comprueban una imagen, o hacen de proxy de una petición hacia un back end. Allí donde el destino de esa descarga lo influye una entrada del usuario, el usuario puede apuntarla a otro sitio.

El valor de eso no es la respuesta. Es la posición. La aplicación está dentro del perímetro de red, muchas veces dentro de una subred privada, con una dirección de origen en la que confían los servicios internos y con credenciales asociadas a su entorno de ejecución. Una petición desde internet a una interfaz administrativa interna se rechaza en el borde. Esa misma petición hecha por la aplicación es una petición de una máquina de confianza.

El objetivo clásico es un servicio que escucha en loopback o en un rango privado y no tiene autenticación propia, porque quien lo desplegó razonó que el control era la red. Los paneles internos, las colas de mensajes, las cachés, las API de orquestación de contenedores y los endpoints de métricas caen todos en ese patrón.

En el cloud el objetivo es más concreto y más valioso: el servicio de metadatos de instancia, un endpoint HTTP de enlace local al que llega cualquier carga de trabajo y que reparte credenciales temporales del rol con el que se ejecuta esa carga. Si el endpoint responde a un GET pelado sin autenticar, un SSRF en una funcionalidad de vista previa se convierte en un juego de credenciales de cloud válidas, y a partir de ahí el proyecto pasa de la aplicación a la cuenta.

El SSRF ciego es el caso en el que la respuesta no vuelve nunca. Se puede explotar igual: la petición o se produce o no, y ese sí o no basta para mapear un rango interno, y basta para disparar una petición que cambia estado contra un servicio que no necesita contestar.

El fallo más común es una validación que comprueba la cadena en vez del destino. Un filtro mira el nombre de máquina, decide que no es interno, y después la aplicación resuelve ese nombre a una dirección privada. Los nombres los controla el atacante, las respuestas de DNS las controla el atacante, y las redirecciones las controla el atacante: una máquina permitida que devuelve una redirección a una dirección interna derrota a una comprobación hecha solo sobre la URL original.

El segundo fallo es validar una vez y conectar después. Entre la comprobación y el socket hay una segunda consulta de DNS, y un atacante que controle la zona puede responder distinto cada vez. El arreglo no es una expresión regular mejor; es resolver el nombre tú mismo, comprobar la dirección que has resuelto, y conectar a esa dirección.

El tercero es donde el SSRF se gana su sitio en un pentesting. Por sí solo es una petición hecha por un servidor. El hallazgo que escribimos casi nunca es eso. Es la cadena: una vista previa de imagen acepta una URL, la URL llega al endpoint de metadatos, el endpoint devuelve credenciales del rol de la instancia, el rol tiene acceso de lectura a un bucket de almacenamiento que nunca se pensó alcanzable desde la capa web, y el bucket guarda documentos de clientes. Cada eslabón es un problema de severidad baja o media por separado. Juntos son el informe. Perseguir la cadena entera en vez de pararse en «el servidor hizo una petición» es lo que separa una prueba de verdad del resultado de un escáner.

Los nombres se parecen y se confunden sin parar, incluso en tickets de subsanación que después aplican el arreglo equivocado. La petición falsificada viene de lados opuestos.

La consecuencia para quien defiende es que los tokens anti-CSRF no hacen nada contra el SSRF, y los controles de red de salida no hacen nada contra el cross-site request forgery. Dos nombres, dos capas, ningún solapamiento.

Bloquear una lista de rangos privados comparando cadenas. Las direcciones se pueden escribir en decimal, en octal, con mapeo a IPv6, o esconderse detrás de un nombre que resuelva a ellas. Compara sobre la dirección resuelta, en binario, contra los rangos que quieres decir.

Olvidarse de la redirección. Si la descarga sigue redirecciones, hay que repetir todas las comprobaciones en cada salto. En la práctica, desactiva el seguimiento de redirecciones en las descargas del servidor o vuelve a validar cada una.

Dar por inofensivo un caso ciego. Una petición que no devuelve nada sigue llegando a una cola, sigue disparando un webhook, sigue borrando algo en una API REST que acepta un GET donde no debería. Que no haya respuesta no significa que no haya impacto.

Tratar la protección de los metadatos como un problema de red. Al endpoint de enlace local no se le puede poner un cortafuegos que lo separe de la carga de trabajo, porque la carga lo usa legítimamente. El control está en el propio endpoint: exigir una petición orientada a sesión, y fijar el límite de saltos de la respuesta para que una petición reenviada desde un contenedor no llegue.

Arreglar el único parámetro del que informamos. El SSRF es una propiedad de todos los sitios donde la aplicación descarga una URL. Si se arregló la función de importación y no el validador del webhook, no ha cambiado nada.

Empieza por decidir si el destino tiene que estar abierto siquiera. La mayoría de las funciones de descarga tienen un conjunto pequeño de destinos legítimos, y una lista de máquinas permitidas es a la vez más sencilla y más fuerte que cualquier filtro. Cuando el destino sea de verdad arbitrario, resuelve el nombre en tu propio código, rechaza cualquier dirección de un rango privado, de loopback, de enlace local o reservado, y conecta a la dirección que has validado y no al nombre.

Aleja la descarga de la posición sensible. Un proxy de salida dedicado, o un servicio pequeño en una subred sin ruta a nada interno, convierte un SSRF con éxito en una petición que no llega a ninguna parte. Aplica filtrado de salida para que la aplicación solo pueda llegar a los destinos que necesita, que suelen ser una lista muy corta y casi nunca «internet».

En cloud, impón el modo de metadatos orientado a sesión en todo el parque y no instancia por instancia, porque la única carga que se quedó en el modo antiguo es la que se va a encontrar. Después reduce lo que vale el rol: un rol de capa web acotado a los dos buckets que usa convierte el robo de credenciales en un incidente bastante más pequeño. Ese acotado es mínimo privilegio aplicado a una identidad de máquina y no a una persona.

Para la detección, la señal está en los registros de salida y en el DNS: una máquina de aplicación resolviendo nombres que no ha resuelto nunca, peticiones a direcciones de enlace local, o un estallido de intentos de conexión por un rango privado desde una máquina que normalmente habla con tres destinos.

En un informe, el SSRF se escribe contra el parámetro que controla el destino, y el hallazgo lleva la cadena, no solo la primitiva. Registramos la petición, el destino interno alcanzado, qué volvió y dónde se paró la cadena. Si llegó a credenciales, decimos qué identidad se emitió, a qué estaba acotada y qué confirmamos que podíamos alcanzar con ella. Paramos en la primera evidencia que demuestra el alcance, y no ejercitamos la credencial más allá de lo necesario para establecerlo.

La severidad la decide dónde aterrizó la petición, nunca la existencia del defecto. Un SSRF que solo llega a internet público es un hallazgo bajo escrito por completitud. Uno que llega a un endpoint de metadatos con una configuración sin versionar es crítico antes de que nadie abra una consola, porque el paso siguiente es un camino de ataque en cloud y no otra petición web.

Esto es una parte fija de cómo abordamos una aplicación que descarga cosas, y es el hallazgo que más veces lleva un proyecto desde la aplicación hasta la cuenta de cloud.

¿Qué puede hacer de verdad un atacante con un SSRF? Llegar a todo lo que alcance el servidor: interfaces internas de administración sin autenticación, los metadatos de cloud y sus credenciales, las API de contenedores y de orquestación, las API internas que confían en la red de origen, y, cuando hay una redirección o un manejador de protocolo disponible, servicios que ni siquiera son HTTP.

¿Un cortafuegos detiene el SSRF? En el perímetro no, porque la petición nace dentro de él. El filtrado de salida sí ayuda, porque decide adónde se permite ir a la petición falsificada, y es uno de los pocos controles que reduce el impacto sin tocar la aplicación.

¿El SSRF es lo mismo que un open redirect? No. Un open redirect manda a algún sitio el navegador del usuario; el SSRF manda al servidor. Eso sí, se combinan: un open redirect en una máquina permitida es una forma habitual de saltarse la lista de permitidos de un SSRF.

¿Cómo protegemos el endpoint de metadatos del cloud? Exigiendo en todas partes el modo de petición orientado a sesión, fijando el límite de saltos de la respuesta para que no lleguen las peticiones reenviadas desde dentro de un contenedor, y reduciendo los permisos del rol de la instancia para que una credencial filtrada valga menos.