Cross-Site Request Forgery (CSRF): ¿Qué es?¿Ejemplos de uso?¿Qué medidas mitigadoras podemos usar?

    A menudo suelen verse en las noticias ataques de ciberdelincuentes a usuarios y a celebridades, cuyas cuentas sociales son comprometidas o inclusive ven sus contenidos privados filtrados. Pero hay muchos otros ataques, quizás la mayoría, que no salen a la luz y ni sus propias víctimas se enteran.

    Las técnicas utilizadas por los atacantes comienzan a ser cada vez más sofisticadas, muchas veces imperceptibles para los perfiles no tan técnicos. Es por eso que en esta entrada, veremos cómo funciona una técnica utilizada por cibercriminales en sitios web para el robo de información, con el objetivo de poder prevenir que se vean afectados.

   

        El Cross-Site Request Forgery (CSRF) es una vulnerabilidad de seguridad en la que un atacante engaña a un usuario legítimo para que realice una acción no deseada en un sitio web sin su conocimiento o consentimiento.

    En un ataque CSRF, el atacante engaña a la víctima para que haga clic en un enlace malicioso o visite una página web maliciosa. Esta página maliciosa puede contener una solicitud HTTP que realiza una acción no deseada en el sitio web de la víctima.

    Por ejemplo, imagina que un usuario ha iniciado sesión en su cuenta bancaria en línea y luego visita una página web maliciosa. La página maliciosa contiene un formulario que envía una solicitud HTTP al sitio web del banco para transferir fondos de la cuenta bancaria del usuario a la cuenta del atacante. Si el usuario hace clic en el botón de envío sin saber que está realizando una transferencia, el ataque CSRF habrá sido exitoso.

    El ataque CSRF puede ser utilizado para realizar una amplia variedad de acciones no deseadas, incluyendo la transferencia de fondos, la modificación de la información de la cuenta, la eliminación de datos y mucho más.

    Para prevenir los ataques CSRF, los desarrolladores de aplicaciones web deben implementar medidas de seguridad adecuadas, como la inclusión de tokens CSRF en los formularios y solicitudes HTTP. Estos tokens CSRF permiten que la aplicación web verifique que la solicitud proviene de un usuario legítimo y no de un atacante malintencionado (aunque cuidadín que también se pueden hacer cositas con esto).


Ejemplo de uso 


    Damn Vulnerable Web App (DVWA) es una aplicación web con vulnerabilidades que fue diseñada de este modo a propósito, con el fin de poder practicar ciberataques en ella de forma legal y segura. En este ejemplo, usaremos esta app con el objetivo de entender cómo funciona un ataque de CSRF.

    •1) Abriremos el enlace de DVWA e iniciaremos sesión con las credenciales por defecto: «admin» y «password«.



    •2) Después, nos dirigiremos a la pestaña de CSRF, donde encontraremos la vulnerabilidad de cross-site request forgery para este ejemplo.




    •3) Como verás, la aplicación nos permite cambiar nuestra contraseña sin necesidad de validar la anterior. Esto es una vulnerabilidad que nos permitirá asignarle la contraseña que queramos a cualquier usuario que ejecute el enlace que produciremos.

    •4) Pare ello, iremos a la ventana de Burp Suite y activaremos el botón «Intercept is on» para empezar a capturar las peticiones.
   

    •5) Después, regresaremos a DVWA y asignaremos la nueva contraseña que queramos.


    •6) Para este ejemplo de cross-site request forgery, elegiremos la contraseña «payload123«, pero, en realidad, puedes elegir la que desees. Daremos clic en «Change» y volveremos a Burp para ver la petición.



    •7) En Burp Suite, haz clic derecho sobre la petición interceptada y selecciona la opción «Copy URL«. Esto creará un enlace que, al ser ejecutado por un usuario, cambiará inmediatamente su contraseña por la que hayamos elegido. Dicho enlace se verá como este:
    

http[:]//192.168.175.130/dvwa/vulnerabilities/csrf/?  Password_new=payload123[&] password_conf=payload123[&] Change=Change



¿Que medidas mitigadoras podemos ejecutar?


• Navegar con atención y precaución

    Como usuario, la consigna es precaución, ante todo. Si no navegas por páginas de fiabilidad dudosa ni abres correos electrónicos sospechosos es muy complicado que te conviertas en víctima de un ataque de este tipo. Para protegerte del CSRF también debes cerrar siempre tu sesión en portales relevantes para tu seguridad antes de acceder a cualquier página web cuyo origen es desconocido.
 
• Revisar el terminal en busca de malware

    Como usuario también debes asegurarte de que tu dispositivo (ordenador, portátil, smartphone, etc.) está libre de software malicioso. Si una aplicación actúa en segundo plano y te espía como usuario, es muy difícil evitar el CSRF. Una vez que el dispositivo o la cuenta estén infectados, pueden ser víctima de múltiples otros ataques.

• Protección frente a CSRF por parte del operario de la página web

    Los operarios de la página web también pueden proteger a los usuarios. Los atacantes solo pueden llevar a cabo ataques de cross site request rorgery porque conocen la estructura exacta de los correspondientes formularios y solicitudes HTTP. Si se introduce un factor aleatorio en la ecuación, el ciberdelincuente suele quedar en fuera de juego. La página web puede crear un token único (similar a una secuencia aleatoria de caracteres) y convertirlo en parte de la solicitud HTTP. Así, si el servidor recibe una solicitud sin token o con un toquen que (ya) no es válido, dicha solicitud se rechaza de forma automática.

• Autenticación de doble factor (2FA)

    Por norma general, la banca electrónica cuenta con una autenticación de doble factor; antes de que el usuario pueda efectuar una transferencia debe introducir un código que no se puede facilitar a través de la página web. Esta técnica no solo sirve como protección frente al CSRF, sino también frente a otros ataques. Incluso si el atacante llega a hacerse con los datos de acceso, no podría realizar la transferencia mientras no cuente con el segundo factor.

• Encabezado de referencia

    En teoría, el encabezado de referencia ya funciona como elemento protector. Esta parte de la solicitud HTTP indica de dónde proviene la solicitud. Así, las páginas web pueden filtrar todos los orígenes externos. No obstante, el encabezado de referencia ha demostrado ser muy poco fiable a lo largo de los últimos años. Cualquier ampliación del navegador, como por ejemplo bloqueadores de anuncios, modifican o eliminan el encabezado de referencia. En este caso, los usuarios con una configuración de este tipo ya no podrían usar la oferta de la página web.

• Cerrar sesión al finalizar el uso

    Una medida que no puede ofrecer protección definitiva, pero que al menos supone un obstáculo para los ciberdelincuentes es no mantener las sesiones iniciadas de manera ilimitada. En este asunto, los operadores sopesan la comodidad de los usuarios y el riesgo. Los portales de bancos, por ejemplo, suelen cerrar la sesión tras solo unos minutos sin que el usuario realice una acción. En cambio, otras páginas web (como, por ejemplo, la mayoría de las redes sociales), que gestionan datos menos sensibles, pueden dejar las sesiones abiertas durante varios días. En cuanto un usuario no tiene la sesión iniciada en el portal, cualquier ataque de CSRF carece de efecto.


No hay comentarios:

Publicar un comentario