¿Cuál es la diferencia entre falsificación de solicitudes entre sitios y del lado del servidor?

Introducción a CSRF y SSRF

Los ataques de falsificación de solicitudes entre sitios (Cross-Site Request Forgery – CSRF) y falsificación de solicitudes del lado del servidor (Server-Side Request Forgery – SSRF) tienen nombres similares.

Ambos ataques aprovechan la forma en que los servidores procesan las URL’s. Sin embargo, estos ataques tienen propósitos e impactos muy diferentes. Comprender la diferencia entre ellos es una parte importante de las pruebas de penetración para aplicaciones web.

Falsificación de solicitudes entre sitios

Las vulnerabilidades de falsificación de solicitudes entre sitios se han incluido en la lista de las diez principales de OWASP para aplicaciones web. Esto fue en la versión más reciente. La razón para eliminarlos de la edición de 2017 fue que muchos frameworks de aplicaciones web contienen protecciones CSRF. Empero, todavía estaban presentes en el 5% de las aplicaciones web en el momento del lanzamiento.

El propósito de los ataques CSRF es obligar a un usuario a realizar acciones no deseadas en su cuenta en línea. Lograr esto implica aprovechar las solicitudes de cambio de estado, donde un servidor web tomará medidas basadas en un usuario autenticado que navega a una página en particular.

Los ejemplos pueden incluir cambiar la contraseña de una cuenta o realizar una transacción a través de un portal de banca en línea.

Funcionamiento

Un atacante explota una vulnerabilidad CSRF cuando un usuario visita un sitio web diseñado para forzar solicitudes secundarias a un sitio determinado. Por ejemplo, el sitio web puede incluir una imagen o un iframe que afirme que debe buscarse desde una determinada página web en el sitio de destino.

Cuando el navegador del usuario intenta obtener el contenido, realiza una solicitud de cambio de estado en el sitio de destino y restablece una contraseña o realiza una transacción financiera.

Los ataques CSRF funcionan porque el usuario ya está autenticado en el sitio de destino y la solicitud forzada incluye la cookie que contiene información de la sesión.

Los ataques CSRF estándar suponen que un usuario ya está autenticado en un sitio, pero los ataques CSRF también se pueden “almacenar”.

Por ejemplo, la imagen maliciosa o el iframe pueden ser un anuncio que las redes publicitarias digitales ocasionalmente colocan en el sitio objetivo o parte de un comentario en el foro del sitio. En estos casos, el atacante garantiza que el usuario se autentica en el sitio cuando está viendo el contenido malicioso.

Falsificación de solicitudes del lado del servidor

Los ataques de falsificación de solicitudes del lado del servidor están diseñados para explotar cómo un servidor procesa la información externa. Algunas aplicaciones web pueden estar diseñadas para leer información o escribir información en una URL particular (como una API REST).

Si un atacante puede modificar la URL de destino, puede extraer información confidencial de la aplicación o inyectarle información no confiable.

El amplio uso de las API REST significa que las aplicaciones vulnerables podrían proporcionar una gran cantidad de información confidencial a un atacante. Los ejemplos de datos potencialmente vulnerables incluyen:

  • Información de configuración en la nube. AWS incluye una API REST desde la que se puede leer la información de configuración y (a veces) las claves de autenticación.  Esto si un atacante puede redirigir el objetivo de la API.
  • Bases de datos. Las bases de datos NoSQL como MongoDB están diseñadas para incluir una API REST. Esta la puede usar el atacante para consultar la base de datos si la autenticación no está habilitada.
  • Archivos: los archivos almacenados en el servidor pueden leerse utilizando file://URI’s.

Usos

Las vulnerabilidades asociadas con las vulnerabilidades SSRF no se limitan a la exfiltración de datos. En algunos casos, las aplicaciones pueden estar diseñadas para leer datos de una URL particular.

Si esta URL es confiable, es posible que la aplicación no esté realizando la validación de datos. Esto podría permitir a un atacante proporcionar información maliciosa que podría explotar. Por ejemplo, un desbordamiento de búfer, un desbordamiento de enteros, inyección de SQL u otra vulnerabilidad en la aplicación.

El impacto de una vulnerabilidad SSRF puede ser significativo. Un ejemplo reciente de un ataque que explota SSRF (y la dificultad de protegerse contra él) fue la violación de datos de Capital One. Ahí se expuso la información personal de 106 millones de personas.

Diferencias entre CSRF y SSRF

Las vulnerabilidades CSRF y SSRF aprovechan la forma en que un servidor web administra las UR’sL. Sin embargo, los dos tipos de vulnerabilidades difieren mucho en el objetivo del ataque y su propósito.

Objetivo del ataque

La falsificación de solicitudes entre sitios y la falsificación de solicitudes del lado del servidor explotan el servidor web. Sin embargo, solo los exploits SSRF están diseñados para atacar al objetivo.

El objetivo de un ataque CSRF es el usuario. Si bien se logra utilizando fallas en la forma en que se diseña la aplicación web, su propósito es realizar acciones legítimas, pero no autorizadas en la cuenta del usuario con el servicio basado en la web.

La falsificación de SSRF, por otro lado, está diseñada para apuntar principalmente al servidor. Si bien, a la larga, el ataque puede afectar a los usuarios del servicio, el objetivo principal del ataque es el robo de información confidencial. Información del servidor o la explotación de otras vulnerabilidades mediante el uso de SSRF para evitar las contramedidas de validación de entrada.

Propósito de ataque

La falsificación de solicitudes entre sitios y la falsificación de solicitudes del lado del servidor también difieren en el propósito del ataque.

En el caso de SSRF, el objetivo principal del ataque es obtener acceso a datos confidenciales. Esto podría realizarse directamente (forzándote a escribir datos en una URL proporcionada por el atacante). De manera indirecta (permitiendo la explotación de una vulnerabilidad que puede usarse para robar datos).

Las vulnerabilidades CSRF, por otro lado, no proporcionan a un atacante ningún acceso a datos confidenciales. El atacante obliga al navegador de un usuario a visitar el sitio de destino, la solicitud y la respuesta reales se realizan de forma independiente.

Incluso si el ataque resulta en el envío de datos confidenciales en respuesta a una solicitud maliciosa, estos datos solo van a la computadora del usuario objetivo, no al atacante. El propósito de explotar una vulnerabilidad CSRF es obligar al usuario objetivo a tomar medidas en interés del atacante. Por ejemplo, cambiar la contraseña de una cuenta a una conocida por el atacante.

Conclusión: detección de vulnerabilidades CSRF y SSRF

Si bien las vulnerabilidades CSRF y SSRF son muy diferentes. No obstante, ambas están habilitadas por el mismo problema: una falla en el uso correcto de las URL’s por parte del servidor.

Al buscar vulnerabilidades potenciales en una aplicación web, examinar cómo la aplicación usa URL’s y los tipos, formatos y destinos de las solicitudes que se le piden, pueden ayudar a identificar estas vulnerabilidades.