¿Qué es SSRF?

En un ataque SSRF, el atacante manipula la entrada utilizada para especificar la URL de destino en una solicitud HTTP del lado del servidor. Esto puede suceder cuando una aplicación no valida ni depura correctamente una URL introducida por un usuario antes de que se realicen solicitudes para extraer datos de un recurso remoto. De este modo, el atacante puede hacer que el servidor de destino realice solicitudes a destinos arbitrarios, lo que puede dar lugar a diversos riesgos de seguridad.

Estos ataques también pueden ocurrir si el recurso objetivo mantiene relaciones de confianza con otros sistemas, como un servicio de metadatos en la nube o API back-end, lo que permite a un atacante realizar solicitudes a esos servicios de confianza y extraer información sensible o ejecutar acciones no autorizadas.

A medida que las aplicaciones web modernas ofrecen funciones prácticas a los usuarios finales, la búsqueda de una URL se ha convertido en un escenario común. Como resultado, la incidencia de SSRF está aumentando. Además, la gravedad de los ataques SSRF crece a medida que las API y los servicios en la nube se vuelven más frecuentes, y las arquitecturas informáticas se hacen más descentralizadas y complejas.

SSRF is one of the OWASP Top 10 Application Security Risks, a widely recognized compilation of the most critical web application security risks. SSRF is also one of the OWASP Top Ten security risks that are common to both apps and APIs, and bears special consideration when implementing security solutions. 

Así es como funciona un ataque SSRF:

• La aplicación permite que el usuario introduzca datos para determinar la URL o el recurso de destino de una solicitud del lado del servidor. Estos datos pueden proceder de parámetros de una URL, de campos de formulario introducidos por el usuario o de otras fuentes de datos.
• El atacante envía una solicitud especialmente diseñada, manipulando la entrada para que apunte a un recurso al que el atacante quiere acceder o que desea vulnerar. Este recurso podría ser un servidor interno, un servicio back-end, una API u otros sistemas internos que están detrás de cortafuegos y no son accesibles desde la red externa.
• El servidor procesa la entrada malintencionada del usuario y construye una solicitud hacia la URL especificada. Esta solicitud se realiza desde la perspectiva del servidor, no desde el navegador del usuario, lo que convierte la petición en una solicitud del lado del servidor.
• Si el servidor objetivo está dentro de una red interna, el atacante puede intentar acceder y recuperar información sensible de los recursos internos y luego filtrar esos datos a una ubicación externa controlada por el atacante. El ataque SSRF también puede utilizarse para escanear puertos en sistemas internos, lo que permite al atacante identificar debilidades y vulnerabilidades potenciales.
• Los ataques SSRF son especialmente preocupantes en entornos de nube en los que las instancias pueden tener acceso a servicios de metadatos sensibles.
• El impacto de un ataque SSRF puede ser grave, ya que va desde el acceso no autorizado a datos y servicios sensibles hasta la explotación de sistemas internos, e incluso el compromiso de entornos completos de nube.

Así es como puede desarrollarse un ataque SSRF en la vida real.

Imaginemos una aplicación web insegura que permite a los usuarios cargar imágenes para su procesamiento, y que ofrece una función para proporcionar una URL a la imagen que desean procesar. Sin embargo, en lugar de proporcionar una URL legítima, el atacante envía una entrada cuidadosamente elaborada que contiene una URL malintencionada y que apunta a un recurso interno en el servidor de aplicaciones, como un archivo interno o una base de datos back-end. El servidor de aplicaciones procesa ciegamente la URL malintencionada y, tras recibir la entrada del atacante, realiza una solicitud al recurso interno especificado por la URL, obteniendo datos confidenciales o consultando la base de datos, para finalmente devolver esos datos al atacante.

Una vez comprometido el servidor, el atacante también puede realizar solicitudes a sistemas externos, sondear vulnerabilidades o interactuar con servicios a los que el servidor tiene acceso. La incidencia de un ataque SSRF puede variar según la arquitectura del sistema y los permisos del servidor comprometido. Los ataques pueden dar como resultado el acceso no autorizado a datos, la interrupción del servicio o el compromiso de sistemas internos.

Los ataques SSRF pueden clasificarse en diferentes tipos en función de la forma en que el atacante interactúa con el servidor y extrae la información.

En un ataque SSRF estándar, el atacante inyecta una URL malintencionada como parte de la entrada del usuario, lo que provoca que el servidor realice una petición al recurso especificado. El atacante puede observar directamente la respuesta del servidor y recopilar información sobre la red interna, como la forma de recuperar datos o identificar los servicios accesibles.

En los ataques SSRF ciegos, el atacante no recibe directamente la respuesta del servidor, sino que confirma indirectamente el éxito o el fracaso del ataque SSRF observando los cambios en el comportamiento de la aplicación.

El atacante envía una entrada manipulada, forzando al servidor a realizar una petición a un recurso externo o interno. El atacante busca cambios observables en la actividad de la aplicación, como diferencias en los mensajes de error, tiempos de respuesta u otros efectos secundarios. Esta información le permite deducir si el ataque SSRF ha tenido éxito, aunque no vea directamente la respuesta.

Los ataques SSRF ciegos basados en el tiempo explotan los retrasos en las respuestas del servidor para deducir el éxito o el fracaso del ataque, sin que el atacante vea directamente la respuesta.

Como en otros ataques SSRF, el atacante envía una entrada malintencionada que provoca que el servidor realice una solicitud a un recurso externo o interno. Luego, observa el tiempo que tarda la aplicación en responder. Los retrasos en el tiempo de respuesta pueden indicar que el SSRF ha tenido éxito. El atacante ajusta de manera iterativa la carga útil y supervisa los retrasos para extraer información sobre la red o los recursos internos.

To protect against SSRF attacks, implement a combination of preventative cybersecurity measures including: 

• Input validation. Validate and sanitize user-supplied input rigorously, especially when the application is making requests to external resources. Implement URL allowlisting, allowing only trusted domains or specific URLs that the application needs to access. Ensure that only the expected protocols, such as http and https, are allowed and avoid allowing potentially risky protocols such as file:// or ftp://, which are often exploited in SSRF attacks. Also, validate that URLs provided by users adhere to expected patterns or formats, reducing the likelihood of injecting malicious URLs.
• Allowlists for hosts and IP addresses. Maintain an allowlist of allowed hosts and IP addresses that the application is permitted to interact with. This can help restrict requests to trusted and intended destinations, reducing the attack surface for SSRF. 
• Restrict access to internal resources. Implement network segmentation to limit the exposure of internal resources. Ensure that external-facing servers have minimal access to internal systems and services. Configure web application firewalls (WAFs) and access controls to restrict outbound connections from the application server. Only allow necessary and predefined connections and block unnecessary outbound traffic. Deploy a reverse proxy to act as an intermediary between the application and external resources. Configure the proxy to control which external resources the application can access, adding an additional layer of control.

¿Cómo ayudan estas medidas preventivas a evitar los ataques SSRF? Veamos un escenario hipotético.

Un sistema de gestión de contenidos en línea permite a los usuarios introducir URL para insertar imágenes externas en sus entradas. Este sistema procesa las URL proporcionadas por los usuarios sin una validación de entrada adecuada. Un atacante, consciente de la falta de validación de entrada, intenta explotar el sistema proporcionando una URL malintencionada que apunte a un recurso interno, como un punto de conexión de API interno o un servidor de base de datos. Sin embargo, el equipo de seguridad de la aplicación mejora la validación de entrada del sistema para aplicar reglas estrictas a las URL aceptadas. El sistema comienza a validar que las URL proporcionadas por los usuarios se adhieran a los patrones esperados, y el equipo implementa una lista de dominios permitidos para recursos externos.

El atacante envía el mensaje con una URL manipulada con la intención de explotar la vulnerabilidad SSRF, pero la validación de entrada ahora detecta la URL malintencionada. La validación de entrada rechaza la URL malintencionada durante el procesamiento, impidiendo que la aplicación realice una petición al recurso interno especificado por el atacante. El ataque SSRF se ve frustrado por la validación de entrada mejorada: el sistema no permite peticiones no autorizadas a recursos internos, y se preserva la integridad y seguridad de los sistemas internos.

Al implementar la validación de entrada, la aplicación puede rechazar o desinfectar la entrada malintencionada, evitando solicitudes no autorizadas y mitigando el riesgo de ataques SSRF.

Los ataques SSRF son peligrosos porque permiten a los atacantes eludir las medidas tradicionales de seguridad de la red, como los cortafuegos y los controles de acceso, para acceder a información y recursos confidenciales que suelen estar protegidos dentro de la red interna de una organización y a los que no está previsto que se pueda acceder directamente desde Internet. Dado que los ataques SSRF plantean riesgos significativos para la confidencialidad, integridad y disponibilidad tanto de los datos como de los sistemas, las organizaciones deben implantar medidas de seguridad sólidas y buenas prácticas, incluidos WAF, validación de entrada adecuada, controles de acceso y segmentación de la red, para mitigar la amenaza de las vulnerabilidades SSRF y protegerse contra su posible explotación.

F5 WAF solutions block and mitigate a broad spectrum of risks stemming from the OWASP Top 10, including SSRF. F5 WAF solutions combine signature and behavioral protections, including threat intelligence from F5 Labs and automated security via machine learning (ML) to keep pace with emerging threats. They ease the burden and complexity of consistently securing applications across clouds, on-premises, and edge environments, and are available in a choice of deployment options. BIG-IP Advanced WAF is a robust solution that can keep your applications safe from SSRF attacks and provide a critical stopgap for software vulnerabilities, while F5 Distributed Cloud WAF secures apps everywhere with dramatically simplified operations through an easy-to-use, as-a-Service security platform.  

F5 Web Application and API Protection (WAAP) solutions defend the entirety of the modern app attack surface with comprehensive protections that include WAF, API security, L3-L7 DDoS mitigation, and bot defense against malicious automation and automated threats. The distributed platform makes it simple to deploy consistent policies and scale security across your entire estate of apps and APIs regardless of where they’re hosted, and integrate security into the API lifecycle and broader ecosystems.