Los codificadores conquistan la seguridad: Share & Learn Series - Cross-Site Request Forgery
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.
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 y lucrativo.
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostración
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
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.
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.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostración
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
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.
Índice
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
.png)
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
