¿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 es uno de los 10 principales riesgos de seguridad de las aplicaciones de la OWASP, una recopilación ampliamente reconocida de los riesgos de seguridad de las aplicaciones web más críticos. SSRF es también uno de los 10 principales riesgos de seguridad de la OWASP que son comunes tanto a las aplicaciones como a las API, y merece una consideración especial a la hora de implantar soluciones de seguridad.

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.

Para protegerse contra los ataques SSRF, aplique una combinación de medidas preventivas de ciberseguridad que incluyan:

• Validación de entradas: Valide y depure rigurosamente las entradas proporcionadas por los usuarios, especialmente cuando la aplicación realice solicitudes a recursos externos. Implemente listas de URL permitidas, permitiendo solo dominios de confianza o URL específicas a las que la aplicación necesite acceder. Asegúrese de que solo se permitan los protocolos esperados, como http y https, y evite protocolos potencialmente peligrosos como file:// o ftp://, que a menudo se explotan en ataques SSRF. Además, valide que las URL proporcionadas por los usuarios se ajusten a los patrones o formatos esperados, lo que reduce la probabilidad de inyectar URL malintencionadas.
• Listas de hosts y direcciones IP permitidas . Mantenga una lista de hosts y direcciones IP permitidas con las que la aplicación puede interactuar. Esto puede ayudar a restringir las solicitudes a destinos de confianza y previstos, reduciendo la superficie de ataque para SSRF.
• Restrinja el acceso a los recursos internos. Implemente la segmentación de red para limitar la exposición de los recursos internos. Asegúrese de que los servidores externos tienen un acceso mínimo a los sistemas y servicios internos. Configure cortafuegos de aplicaciones web (WAF) y controles de acceso para restringir las conexiones salientes desde el servidor de aplicaciones. Permita únicamente las conexiones necesarias y predefinidas y bloquee el tráfico saliente innecesario. Implemente un proxy inverso para que actúe como intermediario entre la aplicación y los recursos externos. Configure el proxy para controlar a qué recursos externos puede acceder la aplicación, añadiendo una capa adicional de 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.

Las soluciones WAF de F5 bloquean y mitigan un amplio espectro de riesgos derivados de los 10 principales riesgos de OWASP, incluido SSRF. Las soluciones WAF de F5 combinan protecciones de firmas y de comportamiento, incluida la inteligencia de amenazas de F5 Labs y la seguridad automatizada mediante aprendizaje automático para seguir el ritmo de las amenazas emergentes. Alivian la carga y la complejidad de proteger de forma coherente las aplicaciones en nubes, en las infraestructuras locales y en entornos de borde, y están disponibles en varias opciones de implementación. BIG-IP Advanced WAF es una solución robusta que puede mantener sus aplicaciones a salvo de ataques SSRF y proporcionar un parche crítico para las vulnerabilidades de software, mientras que F5 Distributed Cloud WAF protege aplicaciones en cualquier lugar, simplificando las operaciones a través de una plataforma de seguridad como servicio fácil de usar.

Las soluciones Web Application and API Protection (WAAP) de F5 defienden la totalidad de la superficie expuesta a ataques de las aplicaciones modernas con protecciones integrales que incluyen WAF, API Security, mitigación de DDoS de capa 3 y capa 7 y defensa ante bots contra amenazas y fraudes automatizados. La plataforma distribuida facilita la implementación de políticas coherentes y el escalado de la seguridad en todo su conjunto de aplicaciones y API independientemente de dónde estén alojadas, así como la integración de protecciones en el ciclo de vida de las API y en ecosistemas de seguridad más amplios.