Los codificadores conquistan la seguridad: Share & Learn Series - Cross-Site Request Forgery

Publicado el 13 de diciembre de 2018
por Jaap Karan Singh
ESTUDIO DE CASO

Los codificadores conquistan la seguridad: Share & Learn Series - Cross-Site Request Forgery

Publicado el 13 de diciembre de 2018
por Jaap Karan Singh
Ver recurso
Ver recurso

A diferencia de los ataques dirigidos directamente a los operadores de sitios web o aplicaciones, el objetivo de muchos ataques de falsificación de solicitud entre sitios (CSRF) es robar dinero, bienes o credenciales directamente a un usuario. Esto no significa que los operadores de sitios web deban ignorar las vulnerabilidades del código CSRF, ya que, en última instancia, la reposición 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 tienen que romperse a favor del atacante para que funcione. A pesar de esto, son un vector de ataque extremadamente popular porque un ataque exitoso puede transferir dinero directamente a un hacker, o configurarlo para poder moverse por un sitio con impunidad. Si todo sale como quiere el hacker, es posible que el usuario al que va dirigido ni siquiera sepa que ha sido víctima de un ataque.

La buena noticia es que, dado que hay muchas cosas que tienen que ir bien para que un ataque CSRF funcione, hay bastantes técnicas defensivas que pueden detenerlos en su camino.

Para ello, analizaremos tres aspectos clave de los ataques CSRF:

  • Cómo funcionan
  • Por qué son tan peligrosos
  • Cómo puede poner defensas para detenerlos en seco.

¿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 se debe realizar para crearlos. Y debido a que a menudo se intentan en diferentes plataformas, a lo largo de los años han adquirido una variedad de nombres y apodos. Es posible que oigas referirse a los ataques CSRF como XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery o Hostile Linking. A Microsoft le gusta referirse a ellos como ataques One-Click en la mayor parte de su documentación. Pero todos son ataques CSRF, y las técnicas para derrotarlos son idénticas.

Un ataque CSRF puede producirse si un usuario está conectado a un sitio web para hacer negocios o para realizar su trabajo. La clave es que el usuario debe estar conectado y autenticado activamente en un sitio web o aplicación. El ataque se lanza normalmente 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 para que hagan clic en un enlace en un correo electrónico que les lleva a un sitio web comprometido con el script de ataque.

El sitio web comprometido contiene un script que ordena al navegador activo 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é autentificado, el sitio pensará que los comandos están siendo emitidos por 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. Puede que incluso se encuentre dentro de una geocerca, sentado correctamente en el terminal de su oficina. Si quiere cambiar su contraseña o transferir fondos, no hay razón para no creer que es él quien hace la solicitud.

Desglosando los elementos del ataque, queda claro por qué éste es tan difícil de llevar a cabo para el atacante. Para empezar, el usuario debe estar autenticado activamente en el sitio donde se produce el ataque. Si un correo electrónico con un script de ataque llega después de que el usuario haya finalizado su sesión de navegación o haya cerrado la sesión, el ataque falla.

El atacante también se ve obligado a realizar un gran reconocimiento en el 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 será para la víctima, no para el atacante. A menos que el atacante sea capaz de ver la evidencia de que su ataque ha funcionado, como que el dinero aparezca de repente 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 acepta el sitio objetivo, el código para ejecutar un ataque CSRF puede ser extremadamente sencillo, aunque varía dependiendo del propio sitio.

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 dólares 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, un script de ataque CSRF podría estar incrustado en la acción de clic:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

Si el usuario objetivo caía en el enlace de ingeniería social y hacía clic en él mientras la sesión del navegador con la aplicación financiera seguía abierta, su navegador pediría a la aplicación que enviara 100.000 dólares a la cuenta de ShadyLady15.

El script podría incluso estar oculto en una imagen invisible que el usuario no viera, pero que aún así podría provocar que el navegador hiciera la petición, así:

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

El resultado es el mismo. ShadyLady15 consigue 100.000 dólares 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 por la que los ataques de ransomware siguen dando vueltas. Pone muy pocos saltos entre los atacantes y el dinero de la víctima. En un ataque de ransomware, los sistemas se encriptan y los usuarios son extorsionados por dinero para descifrar esos datos. Con un ataque CSRF, hay incluso menos pasos. 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 utilizando usuarios válidos. Imagine que un atacante pudiera utilizar un exploit CSRF para cambiar la contraseña de un administrador. Podría utilizar inmediatamente esa contraseña para empezar a robar datos, abrir agujeros a través de las defensas de la red o instalar puertas traseras.

Aunque es mucho trabajo, y hasta cierto punto 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 bajo y lento, tratando de mantenerse por debajo del radar del SIEM y del personal de ciberseguridad. Por el contrario, un solo ataque CSRF puede saltarse bastantes pasos a lo largo de la cadena de muerte cibernética, permitiéndoles empezar muy cerca de su objetivo final.

¿Cómo detener los ataques CSRF?

A diferencia de la mayoría de las vulnerabilidades, con los ataques CSRF el fallo no está realmente en el código, sino en un exploit que los atacantes han creado para forzar a un navegador a hacer peticiones que el usuario no quiere, y que incluso puede desconocer. Pero pueden ser derrotados.

Uno de los mejores métodos es hacer que los desarrolladores añadan un token CSRF a la identidad de un usuario cada vez que se genere 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 a los formularios que son comprobados por el servidor 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 de qué se trata, por lo que todas sus solicitudes fallarán.

Un método aún más fácil, y que no requiere mucha programación, es añadir un desafío Captcha a cualquier cosa sensible como las solicitudes de cambio de contraseña o las órdenes de transferencia de dinero. Puede ser tan simple como pedir al usuario que haga clic en un botón para confirmar que el solicitante 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 de repente reciban un desafío CAPTCHA sin hacer primero algo como una solicitud de transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede utilizar la generación de contraseñas de un solo uso utilizando un token de terceros, como un teléfono inteligente, dependiendo de cuánto quiera una organización ralentizar el trabajo en nombre de la seguridad.

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

Cerrando la puerta al CSRF

Con un potencial de ganancias tan alto, es probable que los ataques CSRF nunca mueran del todo, pero esperamos que hayas aprendido por qué son tan persistentes, y cómo bloquearlos de tu red para siempre.

Para más información, puedes echar un vistazo a la hoja de trucos para la prevención de falsificaciones en sitios cruzados de OWASP, que sirve como documento vivo que describe esta vulnerabilidad a medida que evoluciona. Si realmente quieres reforzar tus conocimientos de seguridad, puedes aprender a vencer esta amenaza y muchas más visitando el Secure Code Warrior blog.

¿Crees que estás preparado para poner a prueba tus nuevos conocimientos sobre defensa? Juega con la demo gratuita de la plataforma Secure Code Warrior hoy mismo.

Ver recurso
Ver recurso

Autor

Jaap Karan Singh

¿Quieres más?

Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.

Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.

Ver blog
¿Quieres más?

Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores

Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.

Centro de recursos

Los codificadores conquistan la seguridad: Share & Learn Series - Cross-Site Request Forgery

Publicado el 13 de diciembre de 2018
Por Jaap Karan Singh

A diferencia de los ataques dirigidos directamente a los operadores de sitios web o aplicaciones, el objetivo de muchos ataques de falsificación de solicitud entre sitios (CSRF) es robar dinero, bienes o credenciales directamente a un usuario. Esto no significa que los operadores de sitios web deban ignorar las vulnerabilidades del código CSRF, ya que, en última instancia, la reposición 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 tienen que romperse a favor del atacante para que funcione. A pesar de esto, son un vector de ataque extremadamente popular porque un ataque exitoso puede transferir dinero directamente a un hacker, o configurarlo para poder moverse por un sitio con impunidad. Si todo sale como quiere el hacker, es posible que el usuario al que va dirigido ni siquiera sepa que ha sido víctima de un ataque.

La buena noticia es que, dado que hay muchas cosas que tienen que ir bien para que un ataque CSRF funcione, hay bastantes técnicas defensivas que pueden detenerlos en su camino.

Para ello, analizaremos tres aspectos clave de los ataques CSRF:

  • Cómo funcionan
  • Por qué son tan peligrosos
  • Cómo puede poner defensas para detenerlos en seco.

¿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 se debe realizar para crearlos. Y debido a que a menudo se intentan en diferentes plataformas, a lo largo de los años han adquirido una variedad de nombres y apodos. Es posible que oigas referirse a los ataques CSRF como XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery o Hostile Linking. A Microsoft le gusta referirse a ellos como ataques One-Click en la mayor parte de su documentación. Pero todos son ataques CSRF, y las técnicas para derrotarlos son idénticas.

Un ataque CSRF puede producirse si un usuario está conectado a un sitio web para hacer negocios o para realizar su trabajo. La clave es que el usuario debe estar conectado y autenticado activamente en un sitio web o aplicación. El ataque se lanza normalmente 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 para que hagan clic en un enlace en un correo electrónico que les lleva a un sitio web comprometido con el script de ataque.

El sitio web comprometido contiene un script que ordena al navegador activo 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é autentificado, el sitio pensará que los comandos están siendo emitidos por 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. Puede que incluso se encuentre dentro de una geocerca, sentado correctamente en el terminal de su oficina. Si quiere cambiar su contraseña o transferir fondos, no hay razón para no creer que es él quien hace la solicitud.

Desglosando los elementos del ataque, queda claro por qué éste es tan difícil de llevar a cabo para el atacante. Para empezar, el usuario debe estar autenticado activamente en el sitio donde se produce el ataque. Si un correo electrónico con un script de ataque llega después de que el usuario haya finalizado su sesión de navegación o haya cerrado la sesión, el ataque falla.

El atacante también se ve obligado a realizar un gran reconocimiento en el 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 será para la víctima, no para el atacante. A menos que el atacante sea capaz de ver la evidencia de que su ataque ha funcionado, como que el dinero aparezca de repente 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 acepta el sitio objetivo, el código para ejecutar un ataque CSRF puede ser extremadamente sencillo, aunque varía dependiendo del propio sitio.

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 dólares 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, un script de ataque CSRF podría estar incrustado en la acción de clic:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

Si el usuario objetivo caía en el enlace de ingeniería social y hacía clic en él mientras la sesión del navegador con la aplicación financiera seguía abierta, su navegador pediría a la aplicación que enviara 100.000 dólares a la cuenta de ShadyLady15.

El script podría incluso estar oculto en una imagen invisible que el usuario no viera, pero que aún así podría provocar que el navegador hiciera la petición, así:

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

El resultado es el mismo. ShadyLady15 consigue 100.000 dólares 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 por la que los ataques de ransomware siguen dando vueltas. Pone muy pocos saltos entre los atacantes y el dinero de la víctima. En un ataque de ransomware, los sistemas se encriptan y los usuarios son extorsionados por dinero para descifrar esos datos. Con un ataque CSRF, hay incluso menos pasos. 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 utilizando usuarios válidos. Imagine que un atacante pudiera utilizar un exploit CSRF para cambiar la contraseña de un administrador. Podría utilizar inmediatamente esa contraseña para empezar a robar datos, abrir agujeros a través de las defensas de la red o instalar puertas traseras.

Aunque es mucho trabajo, y hasta cierto punto 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 bajo y lento, tratando de mantenerse por debajo del radar del SIEM y del personal de ciberseguridad. Por el contrario, un solo ataque CSRF puede saltarse bastantes pasos a lo largo de la cadena de muerte cibernética, permitiéndoles empezar muy cerca de su objetivo final.

¿Cómo detener los ataques CSRF?

A diferencia de la mayoría de las vulnerabilidades, con los ataques CSRF el fallo no está realmente en el código, sino en un exploit que los atacantes han creado para forzar a un navegador a hacer peticiones que el usuario no quiere, y que incluso puede desconocer. Pero pueden ser derrotados.

Uno de los mejores métodos es hacer que los desarrolladores añadan un token CSRF a la identidad de un usuario cada vez que se genere 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 a los formularios que son comprobados por el servidor 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 de qué se trata, por lo que todas sus solicitudes fallarán.

Un método aún más fácil, y que no requiere mucha programación, es añadir un desafío Captcha a cualquier cosa sensible como las solicitudes de cambio de contraseña o las órdenes de transferencia de dinero. Puede ser tan simple como pedir al usuario que haga clic en un botón para confirmar que el solicitante 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 de repente reciban un desafío CAPTCHA sin hacer primero algo como una solicitud de transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede utilizar la generación de contraseñas de un solo uso utilizando un token de terceros, como un teléfono inteligente, dependiendo de cuánto quiera una organización ralentizar el trabajo en nombre de la seguridad.

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

Cerrando la puerta al CSRF

Con un potencial de ganancias tan alto, es probable que los ataques CSRF nunca mueran del todo, pero esperamos que hayas aprendido por qué son tan persistentes, y cómo bloquearlos de tu red para siempre.

Para más información, puedes echar un vistazo a la hoja de trucos para la prevención de falsificaciones en sitios cruzados de OWASP, que sirve como documento vivo que describe esta vulnerabilidad a medida que evoluciona. Si realmente quieres reforzar tus conocimientos de seguridad, puedes aprender a vencer esta amenaza y muchas más visitando el Secure Code Warrior blog.

¿Crees que estás preparado para poner a prueba tus nuevos conocimientos sobre defensa? Juega con la demo gratuita de la plataforma Secure Code Warrior hoy mismo.

Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.