Falsificación de solicitudes entre sitios (CSRF)

Un ataque CSRF obliga a un usuario autenticado (víctima) a enviar una solicitud HTTP falsificada, incluida la cookie de sesión de la víctima, a una aplicación web vulnerable, lo que permite al atacante obligar al navegador de la víctima a generar una solicitud que la aplicación vulnerable perciba como solicitudes legítimas de la víctima.

Comprendamos los agentes de amenazas, los vectores de ataque, la debilidad de la seguridad, el impacto técnico y los impactos comerciales de esta falla con la ayuda de un diagrama simple.

Ejemplo

Aquí hay un ejemplo clásico de CSRF:

Step 1 - Digamos que la aplicación vulnerable envía una solicitud de cambio de estado como texto plano sin ningún cifrado.

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

Step 2 - Ahora el pirata informático construye una solicitud que transfiere dinero de la cuenta de la víctima a la cuenta del atacante incrustando la solicitud en una imagen que se almacena en varios sitios bajo el control del atacante -

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

Las manos en

Step 1- Realicemos una falsificación de CSRF incrustando un script Java en una imagen. La instantánea del problema se enumera a continuación.

Step 2 - Ahora necesitamos simular la transferencia en una imagen 1x1 y hacer que la víctima haga clic en la misma.

Step 3 - Al enviar el mensaje, el mensaje se muestra como se resalta a continuación.

Step 4- Ahora, si la víctima hace clic en la siguiente URL, se ejecuta la transferencia, que se puede encontrar interceptando la acción del usuario usando burp suite. Podemos ver la transferencia al detectarla en Obtener mensaje como se muestra a continuación:

Step 5 - Ahora, al hacer clic en actualizar, se muestra la marca de finalización de la lección.

Mecanismos preventivos

  • CSRF se puede evitar creando un token único en un campo oculto que se enviaría en el cuerpo de la solicitud HTTP en lugar de en una URL, que es más propensa a la exposición.

  • Obligar al usuario a volver a autenticarse o demostrar que es un usuario para proteger CSRF. Por ejemplo, CAPTCHA.