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 sencillo, y que no requiere mucha programación, es añadir un desafío Captcha a cualquier cosa sensible, como solicitudes de cambio de contraseña u órdenes de transferencia de dinero. Puede ser tan sencillo 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 crear un script de respuesta al desafío, y los usuarios que de repente reciban un desafío CAPTCHA sin haber hecho antes algo como solicitar una transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede utilizar la generación de contraseñas de un solo uso mediante un token de terceros, como un teléfono inteligente, dependiendo de lo mucho que una organización quiera 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 sencillo, y que no requiere mucha programación, es añadir un desafío Captcha a cualquier cosa sensible, como solicitudes de cambio de contraseña u órdenes de transferencia de dinero. Puede ser tan sencillo 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 crear un script de respuesta al desafío, y los usuarios que de repente reciban un desafío CAPTCHA sin haber hecho antes algo como solicitar una transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede utilizar la generación de contraseñas de un solo uso mediante un token de terceros, como un teléfono inteligente, dependiendo de lo mucho que una organización quiera 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 sencillo, y que no requiere mucha programación, es añadir un desafío Captcha a cualquier cosa sensible, como solicitudes de cambio de contraseña u órdenes de transferencia de dinero. Puede ser tan sencillo 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 crear un script de respuesta al desafío, y los usuarios que de repente reciban un desafío CAPTCHA sin haber hecho antes algo como solicitar una transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede utilizar la generación de contraseñas de un solo uso mediante un token de terceros, como un teléfono inteligente, dependiendo de lo mucho que una organización quiera 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 sencillo, y que no requiere mucha programación, es añadir un desafío Captcha a cualquier cosa sensible, como solicitudes de cambio de contraseña u órdenes de transferencia de dinero. Puede ser tan sencillo 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 crear un script de respuesta al desafío, y los usuarios que de repente reciban un desafío CAPTCHA sin haber hecho antes algo como solicitar una transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede utilizar la generación de contraseñas de un solo uso mediante un token de terceros, como un teléfono inteligente, dependiendo de lo mucho que una organización quiera 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
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
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.
