Coders Conquer Security: Serie de aprendizaje y uso compartido - Falsificación de solicitudes entre sitios (CSRF)

A diferencia de los ataques dirigidos directamente a los operadores de sitios web o aplicaciones, el objetivo de muchos ataques de falsificación de petición en sitios cruzados (CSRF) es robar dinero, bienes o credenciales directamente de un usuario. Esto no significa que los operadores de sitios deban ignorar las vulnerabilidades de código CSRF, ya que, en última instancia, el reembolso de los fondos robados, en el caso de un ataque puramente monetario, puede ser responsabilidad del sitio de alojamiento con el código inseguro. Y si el usuario objetivo pierde sus credenciales o cambia su contraseña sin saberlo, un delincuente podría causar estragos utilizando esa identidad robada, especialmente si la víctima tiene acceso privilegiado.

Los ataques CSRF son bastante complejos y dependen de múltiples capas para tener éxito. En otras palabras, muchas cosas deben fallar a favor del atacante para que funcionen. A pesar de esto, son un vector de ataque extremadamente popular porque un ataque exitoso puede transferir dinero directamente a un hacker o permitirle moverse por un sitio con impunidad. Si todo sale como el hacker quiere, es posible que el usuario objetivo ni siquiera sepa que fue víctima de un ataque.

La buena noticia es que, debido a que tantas cosas deben salir bien para que un ataque CSRF funcione, existen bastantes técnicas defensivas excelentes que pueden detenerlos en seco.

Con ese fin, analizaremos tres aspectos clave de los ataques CSRF:

• Cómo funcionan
• Por qué son tan peligrosos
• Cómo puedes implementar defensas para detenerlos por completo.

¿Cómo funcionan los ataques CSRF?

Debido a que los ataques CSRF exitosos tienen la capacidad de robar directamente dinero, bienes o credenciales de los usuarios objetivo, son populares a pesar de la gran cantidad de trabajo que requiere crearlos. Y como a menudo se intentan en diferentes plataformas, a lo largo de los años han recibido una variedad de nombres y apodos. Es posible que escuches que los ataques CSRF se denominan XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery o Hostile Linking. A Microsoft le gusta referirse a ellos como ataques de un solo clic en la mayoría de su documentación. Pero todos son ataques CSRF y las técnicas para derrotarlos son idénticas.

Un ataque CSRF puede ocurrir si un usuario ha iniciado sesión en un sitio realizando transacciones o trabajando. La clave es que el usuario debe haber iniciado sesión y estar autenticado activamente en un sitio web o aplicación. El ataque normalmente se lanza desde un sitio web secundario o un correo electrónico. A menudo, los atacantes utilizan técnicas de ingeniería social para engañar a los usuarios y que hagan clic en un enlace de un correo electrónico que los lleva a un sitio web comprometido con el script de ataque.

El sitio web comprometido contiene un script que instruye al navegador activo para que ejecute comandos, normalmente algo malicioso como cambiar la contraseña de un usuario o transferir dinero a una cuenta controlada por el atacante. Mientras el usuario esté autenticado, el sitio pensará que los comandos los está emitiendo el usuario autorizado. ¿Por qué no lo haría? El usuario ya se ha autenticado y ha proporcionado las contraseñas necesarias para acceder al sitio. Incluso pueden estar ubicados dentro de una geocerca, sentados correctamente en su terminal de oficina. Si quieren cambiar su contraseña o transferir fondos, no hay razón para no creer que son ellos quienes realizan la solicitud.

Al desglosar los elementos del ataque, queda claro por qué es tan difícil de lograr para el atacante. Para empezar, el usuario debe estar autenticado activamente en el sitio donde tiene lugar el ataque. Si llega un correo electrónico con un script de ataque después de que un usuario haya finalizado su sesión de navegador o haya cerrado la sesión, el ataque falla.

El atacante también se ve obligado a realizar un gran reconocimiento del sitio objetivo para saber qué scripts aceptará ese sitio. Los atacantes no pueden ver la pantalla de la víctima y cualquier respuesta del sitio web irá a la víctima, no al atacante. A menos que el atacante pueda ver evidencia de que su ataque funciona, como que el dinero aparezca repentinamente en su cuenta, ni siquiera sabrá de inmediato si ha tenido éxito.

Dentro de los parámetros difíciles pero no imposibles de tener al usuario conectado en el momento del ataque y saber qué scripts aceptará el sitio objetivo, el código para ejecutar un ataque CSRF puede ser extremadamente simple, aunque varía según el sitio en sí.

Digamos que un banco o una aplicación financiera utiliza solicitudes GET para transferir dinero, de esta manera:

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

Ese código enviaría una solicitud para transferir $100 a un usuario llamado NancySmith12.

Pero si el usuario objetivo recibiera un correo electrónico, tal vez uno disfrazado como si viniera de un colega, se podría incrustar un script de ataque CSRF en la acción de clic:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">¿Puedes revisar rápidamente este informe trimestral?<a></a></a>

Si el usuario objetivo cayera en el enlace de ingeniería social y hiciera clic en él mientras la sesión del navegador con la aplicación financiera aún estaba abierta, su navegador le pediría a la aplicación que enviara $100,000 a la cuenta de ShadyLady15.

El script incluso podría ocultarse en una imagen invisible que el usuario no vería, pero que aún podría activar el navegador para realizar la solicitud, de esta manera:

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

El resultado es el mismo. ShadyLady15 recibe 100.000 $ sin que nadie detecte el ataque.

¿Por qué es tan peligroso el CSRF?

Los ataques CSRF son populares hoy en día por la misma razón que los ataques de ransomware siguen circulando. Reducen al mínimo los pasos entre los atacantes y el dinero de la víctima. En un ataque de ransomware, los sistemas se cifran y se extorsiona a los usuarios para que paguen por descifrar los datos. Con un ataque CSRF, los pasos son aún menores. Cuando funcionan, las víctimas simplemente envían dinero a los atacantes sin saberlo.

Más allá de los ataques directos al dinero de una víctima o a las finanzas de una empresa, los ataques CSRF exitosos pueden utilizarse para comprometer una red mediante usuarios válidos. Imagine que un atacante pudiera usar un exploit CSRF para cambiar la contraseña de un administrador. Podría usarla inmediatamente para empezar a robar datos, abrir brechas en las defensas de la red o instalar puertas traseras.

Aunque requiere mucho trabajo y, en cierta medida, suerte, un ataque CSRF exitoso puede ser como ganar la lotería para los hackers, independientemente de su objetivo final. Al atacar una red, casi cualquier otro tipo de ataque requeriría meses de reconocimiento lento y discreto, tratando de pasar desapercibido ante el SIEM y el personal de ciberseguridad. Por el contrario, un solo ataque CSRF puede saltarse bastantes pasos en la cadena de ataque, permitiéndoles empezar muy cerca de su objetivo final.

¿Cómo detengo los ataques CSRF?

A diferencia de la mayoría de las vulnerabilidades, en los ataques CSRF la culpa no reside realmente en el código, sino en un exploit que los atacantes han creado para forzar al navegador a realizar solicitudes que el usuario no desea y de las que puede que ni siquiera sea consciente. Pero se pueden derrotar.

Uno de los mejores métodos es que los desarrolladores añadan un token CSRF a la identidad del usuario cada vez que se genera una nueva sesión. Debe consistir en una cadena de caracteres únicos y aleatorios, y ser invisible para los usuarios. A continuación, añada la solicitud del token CSRF como un campo oculto en los formularios que el servidor verifica cada vez que se envía una nueva solicitud. Los atacantes que envíen solicitudes a través del navegador de un usuario ni siquiera sabrán de la existencia del campo oculto del token, y mucho menos podrán averiguar cuál es, por lo que todas sus solicitudes fallarán.

Un método aún más sencillo, que no requiere mucha programación, es añadir un desafío CAPTCHA a cualquier acción sensible, como solicitudes de cambio de contraseña u órdenes de transferencia de dinero. Puede ser tan simple como pedir al usuario que haga clic en un botón confirmando que quien realiza la solicitud no es un robot o, en este caso, un script CSRF. Los atacantes no podrán programar una respuesta al desafío, y los usuarios que reciban de repente un desafío CAPTCHA sin haber realizado ninguna acción, como una solicitud de transferencia, sabrán que algo ocurre. Alternativamente, se puede utilizar la generación de contraseñas de un solo uso mediante un token de terceros, como un smartphone, dependiendo de cuánto quiera una organización ralentizar el trabajo en nombre de la seguridad.

Por último, aunque no es infalible, muchos navegadores como Microsoft Edge o Google Chrome tienen ahora restricciones de política de mismo origen para bloquear las solicitudes de cualquier persona que no sea el usuario local. Obligar a los usuarios a interactuar con su sitio utilizando las versiones más actualizadas de esos navegadores puede ayudar a crear otra capa de seguridad CSRF sin sobrecargar en absoluto a los equipos de desarrollo.

Cerrando la puerta al CSRF

Con un beneficio potencial tan alto, es probable que los ataques CSRF nunca desaparezcan por completo, pero esperamos que haya aprendido por qué son tan persistentes y cómo bloquearlos de su red para siempre.

Para seguir leyendo, puede consultar la hoja de trucos de prevención de falsificación de solicitudes entre sitios (CSRF) de OWASP, que sirve como documento vivo que narra esta vulnerabilidad a medida que evoluciona. Si realmente desea reforzar sus conocimientos de seguridad, puede aprender a derrotar esta amenaza y muchas más visitando el blog de Secure Code Warrior.

¿Cree que está listo para poner a prueba sus nuevos conocimientos defensivos? Pruebe la demo gratuita de la plataforma Secure Code Warrior hoy mismo.