Coders Conquer Security: Serie Share & Learn: Falsificación de solicitudes entre sitios
A diferencia de los ataques dirigidos directamente a los operadores de sitios web o aplicaciones, el objetivo de muchos ataques de falsificación de solicitudes entre sitios (CSRF) es robar dinero, bienes o credenciales directamente de un usuario. Esto no significa que los operadores de sitios deban ignorar las vulnerabilidades del código CSRF, ya que, en última instancia, la sustitución de los fondos robados, en caso de un ataque puramente monetario, puede ser responsabilidad del sitio de alojamiento por 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, hay muchas cosas que tienen que fallar a favor del atacante para que funcione. A pesar de ello, son un vector de ataque extremadamente popular porque un ataque exitoso puede transferir dinero directamente a un pirata informático o configurarlo para que pueda moverse por un sitio con impunidad. Si todo sale bien para un hacker, es posible que el usuario objetivo ni siquiera sepa que ha sido víctima de un ataque.
La buena noticia es que, dado que todo tiene que ir bien para que un ataque de la CSRF funcione, existen bastantes técnicas defensivas excelentes que pueden detenerlos.
Con ese fin, analizaremos tres aspectos clave de los ataques CSRF:
- Cómo funcionan
- Por qué son tan peligrosos
- Cómo puedes establecer defensas para detenerlos.
¿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 implica crearlos. Y dado que con frecuencia se realizan en diferentes plataformas, a lo largo de los años han adquirido una variedad de nombres y apodos. Es posible que a los ataques de la CSRF se les llame XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery o Hostile Linking. A Microsoft le gusta denominarlos ataques con un solo clic en la mayor parte de su documentación. Pero todos son ataques de la CSRF y las técnicas para derrotarlos son idénticas.
Un ataque CSRF puede ocurrir si un usuario inicia sesión en un sitio que realiza negocios o realiza su trabajo. La clave es que el usuario debe iniciar sesión y autenticarse activamente en un sitio web o una aplicación. El ataque normalmente se lanza desde un sitio web secundario o un correo electrónico. A menudo, los atacantes utilizan técnicas de ingeniería social para engañar a los usuarios para que hagan clic en un enlace de un correo electrónico que los lleva a un sitio web comprometido con el script del ataque.
El sitio web comprometido contiene un script que indica al navegador activo que ejecute comandos, normalmente algo malintencionado, como cambiar la contraseña de un usuario o transferir dinero a una cuenta controlada por el atacante. Mientras el usuario esté autenticado, el sitio pensará que los comandos los ha emitido el usuario autorizado. ¿Por qué no lo haría? El usuario ya se ha autenticado y ha proporcionado las contraseñas necesarias para acceder al sitio. Incluso pueden estar ubicados dentro de una geocerca, correctamente sentados en la terminal de su oficina. Si quieren cambiar su contraseña o transferir fondos, no hay motivo para no creer que son ellos los que hacen la solicitud.
Al analizar los elementos del ataque, queda claro por qué es tan difícil de llevar a cabo para el atacante. Para empezar, el usuario debe estar autenticado activamente en el sitio en el que se produce el ataque. Si recibe un correo electrónico con una secuencia de comandos de ataque después de que un usuario haya finalizado su sesión en el navegador o haya cerrado sesión, el ataque falla.
El atacante también se ve obligado a realizar muchos reconocimientos en el sitio objetivo para saber qué scripts aceptará ese sitio. Los atacantes no pueden ver la pantalla de la víctima y cualquier comentario que reciba del sitio web irá dirigido a la víctima, no al atacante. A menos que el atacante pueda ver pruebas de que su ataque ha funcionado (por ejemplo, si de repente aparece dinero en su cuenta), ni siquiera sabrá de inmediato si ha tenido éxito.
Dentro de los parámetros difíciles, pero no imposibles, de tener el usuario conectado en el momento del ataque y saber qué scripts aceptará el sitio objetivo, el código para ejecutar un ataque CSRF puede ser extremadamente simple, aunque varía según el sitio en sí.
Supongamos que una aplicación bancaria o financiera usa solicitudes GET para transferir dinero, de la siguiente manera:
OBTENGA 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.
Sin embargo, si el usuario objetivo recibe un correo electrónico, tal vez uno disfrazado como si procediera de un colega, se podría incrustar un script de ataque CSRF en la acción de clic:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">¿Puede leer rápidamente este informe trimestral? <a></a></a>
Si el usuario objetivo caía en la trampa del enlace de ingeniería social y hacía clic en él mientras la sesión del navegador con la aplicación financiera aún estaba abierta, su navegador le pediría a la aplicación que enviara 100.000 dólares a la cuenta de ShadyLady15.
El script podría incluso ocultarse en una imagen invisible que el usuario no vería, pero que aun así podría hacer que el navegador realizara la solicitud, de la siguiente manera:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
El resultado es el mismo. ShadyLady15 recibe 100.000 dólares sin que nadie detecte el ataque.
¿Por qué es tan peligrosa la CSRF?
Los ataques CSRF son populares hoy en día por la misma razón por la que los ataques de ransomware siguen circulando. Hay muy pocos saltos entre los atacantes y el dinero de la víctima. En un ataque de ransomware, los sistemas se cifran y se extorsiona a los usuarios para obtener dinero para descifrar esos datos. Con un ataque de CSRF, se necesitan incluso menos pasos. Cuando trabajan, las víctimas simplemente envían dinero a los atacantes sin saberlo.
Más allá de los ataques directos al dinero de la víctima o a las finanzas de una empresa, los ataques CSRF exitosos se pueden utilizar para comprometer una red que utiliza usuarios válidos. Imagínese si un atacante pudiera usar un exploit del CSRF para cambiar la contraseña de un administrador. Podrían usar esa contraseña de inmediato para empezar a robar datos, abrir brechas en las defensas de la red o instalar puertas traseras.
Aunque es mucho trabajo y, en cierta medida, suerte, un ataque CSRF exitoso puede ser como ganar la lotería para los piratas informáticos, independientemente de cuál sea su objetivo final. A la hora de atacar una red, casi cualquier otro tipo de ataque requeriría meses de reconocimiento lento y lento, tratando de mantenerse fuera del radar del personal de SIEM y ciberseguridad. Por el contrario, un solo ataque de la CSRF puede saltarse varios escalones de la cadena de ciberataque, lo que les permite empezar muy cerca de su objetivo final.
¿Cómo puedo detener los ataques de CSRF?
A diferencia de la mayoría de las vulnerabilidades, en los ataques CSRF la culpa no es realmente del código, sino de un exploit que los atacantes han creado para obligar a un navegador a realizar solicitudes que un usuario no quiere y que tal vez ni siquiera conozca. Pero pueden ser derrotados.
Uno de los mejores métodos es hacer que los desarrolladores agreguen un token CSRF a la identidad de un usuario cada vez que se genera una nueva sesión. Debe consistir en una cadena de caracteres únicos y aleatorios y ser invisible para los usuarios. A continuación, añada la solicitud del token CSRF como campo oculto a los formularios que el servidor comprueba 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 conocerán el 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 confidencial, como las solicitudes de cambio de contraseña o las órdenes de transferencia de dinero. Puede ser tan sencillo como pedirle a un usuario que haga clic en un botón para confirmar que el solicitante no es un robot o, en este caso, usar un script CSRF. Los atacantes no serán capaces de escribir una respuesta al desafío, y los usuarios que de repente reciban un desafío con el CAPTCHA sin hacer primero algo como solicitar una transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede generar una contraseña de un solo uso con un token de terceros, como un smartphone, en función de lo mucho que la organización quiera ralentizar el trabajo por motivos de seguridad.
Por último, aunque no es irrefutable, muchos navegadores como Microsoft Edge o Google Chrome ahora tienen política sobre el mismo origen existen restricciones para bloquear las solicitudes de cualquier persona que no sea el usuario local. Obligar a los usuarios a interactuar con tu sitio utilizando las versiones más actualizadas de esos navegadores puede ayudar a crear otra capa de seguridad basada en el CSRF sin sobrecargar en absoluto a los equipos de desarrollo.
Cerrando la puerta a la CSRF
Con un potencial de beneficio tan alto, es probable que los ataques CSRF nunca acaben por completo, pero esperamos que hayas aprendido por qué son tan persistentes y cómo bloquearlos definitivamente de tu red.
Para obtener más información, puede echar un vistazo a la hoja de trucos para prevenir la falsificación de solicitudes entre sitios de OWASP, que sirve como un documento vivo que narra esta vulnerabilidad a medida que evoluciona. Si realmente quieres reforzar tus conocimientos de seguridad, puedes aprender a derrotar a esta amenaza y a muchas más visitando la Secure Code Warrior blog.
¿Crees que estás listo para poner a prueba tus nuevos conocimientos defensivos? Juega un poco con el demo gratuita de la plataforma Secure Code Warrior en la actualidad.
Los ataques CSRF son bastante complejos y dependen de múltiples capas para tener éxito. En otras palabras, hay muchas cosas que tienen que fallar a favor del atacante para que funcione. A pesar de ello, son un vector de ataque extremadamente popular y lucrativo.
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of 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 solicitudes entre sitios (CSRF) es robar dinero, bienes o credenciales directamente de un usuario. Esto no significa que los operadores de sitios deban ignorar las vulnerabilidades del código CSRF, ya que, en última instancia, la sustitución de los fondos robados, en caso de un ataque puramente monetario, puede ser responsabilidad del sitio de alojamiento por 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, hay muchas cosas que tienen que fallar a favor del atacante para que funcione. A pesar de ello, son un vector de ataque extremadamente popular porque un ataque exitoso puede transferir dinero directamente a un pirata informático o configurarlo para que pueda moverse por un sitio con impunidad. Si todo sale bien para un hacker, es posible que el usuario objetivo ni siquiera sepa que ha sido víctima de un ataque.
La buena noticia es que, dado que todo tiene que ir bien para que un ataque de la CSRF funcione, existen bastantes técnicas defensivas excelentes que pueden detenerlos.
Con ese fin, analizaremos tres aspectos clave de los ataques CSRF:
- Cómo funcionan
- Por qué son tan peligrosos
- Cómo puedes establecer defensas para detenerlos.
¿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 implica crearlos. Y dado que con frecuencia se realizan en diferentes plataformas, a lo largo de los años han adquirido una variedad de nombres y apodos. Es posible que a los ataques de la CSRF se les llame XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery o Hostile Linking. A Microsoft le gusta denominarlos ataques con un solo clic en la mayor parte de su documentación. Pero todos son ataques de la CSRF y las técnicas para derrotarlos son idénticas.
Un ataque CSRF puede ocurrir si un usuario inicia sesión en un sitio que realiza negocios o realiza su trabajo. La clave es que el usuario debe iniciar sesión y autenticarse activamente en un sitio web o una aplicación. El ataque normalmente se lanza desde un sitio web secundario o un correo electrónico. A menudo, los atacantes utilizan técnicas de ingeniería social para engañar a los usuarios para que hagan clic en un enlace de un correo electrónico que los lleva a un sitio web comprometido con el script del ataque.
El sitio web comprometido contiene un script que indica al navegador activo que ejecute comandos, normalmente algo malintencionado, como cambiar la contraseña de un usuario o transferir dinero a una cuenta controlada por el atacante. Mientras el usuario esté autenticado, el sitio pensará que los comandos los ha emitido el usuario autorizado. ¿Por qué no lo haría? El usuario ya se ha autenticado y ha proporcionado las contraseñas necesarias para acceder al sitio. Incluso pueden estar ubicados dentro de una geocerca, correctamente sentados en la terminal de su oficina. Si quieren cambiar su contraseña o transferir fondos, no hay motivo para no creer que son ellos los que hacen la solicitud.
Al analizar los elementos del ataque, queda claro por qué es tan difícil de llevar a cabo para el atacante. Para empezar, el usuario debe estar autenticado activamente en el sitio en el que se produce el ataque. Si recibe un correo electrónico con una secuencia de comandos de ataque después de que un usuario haya finalizado su sesión en el navegador o haya cerrado sesión, el ataque falla.
El atacante también se ve obligado a realizar muchos reconocimientos en el sitio objetivo para saber qué scripts aceptará ese sitio. Los atacantes no pueden ver la pantalla de la víctima y cualquier comentario que reciba del sitio web irá dirigido a la víctima, no al atacante. A menos que el atacante pueda ver pruebas de que su ataque ha funcionado (por ejemplo, si de repente aparece dinero en su cuenta), ni siquiera sabrá de inmediato si ha tenido éxito.
Dentro de los parámetros difíciles, pero no imposibles, de tener el usuario conectado en el momento del ataque y saber qué scripts aceptará el sitio objetivo, el código para ejecutar un ataque CSRF puede ser extremadamente simple, aunque varía según el sitio en sí.
Supongamos que una aplicación bancaria o financiera usa solicitudes GET para transferir dinero, de la siguiente manera:
OBTENGA 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.
Sin embargo, si el usuario objetivo recibe un correo electrónico, tal vez uno disfrazado como si procediera de un colega, se podría incrustar un script de ataque CSRF en la acción de clic:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">¿Puede leer rápidamente este informe trimestral? <a></a></a>
Si el usuario objetivo caía en la trampa del enlace de ingeniería social y hacía clic en él mientras la sesión del navegador con la aplicación financiera aún estaba abierta, su navegador le pediría a la aplicación que enviara 100.000 dólares a la cuenta de ShadyLady15.
El script podría incluso ocultarse en una imagen invisible que el usuario no vería, pero que aun así podría hacer que el navegador realizara la solicitud, de la siguiente manera:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
El resultado es el mismo. ShadyLady15 recibe 100.000 dólares sin que nadie detecte el ataque.
¿Por qué es tan peligrosa la CSRF?
Los ataques CSRF son populares hoy en día por la misma razón por la que los ataques de ransomware siguen circulando. Hay muy pocos saltos entre los atacantes y el dinero de la víctima. En un ataque de ransomware, los sistemas se cifran y se extorsiona a los usuarios para obtener dinero para descifrar esos datos. Con un ataque de CSRF, se necesitan incluso menos pasos. Cuando trabajan, las víctimas simplemente envían dinero a los atacantes sin saberlo.
Más allá de los ataques directos al dinero de la víctima o a las finanzas de una empresa, los ataques CSRF exitosos se pueden utilizar para comprometer una red que utiliza usuarios válidos. Imagínese si un atacante pudiera usar un exploit del CSRF para cambiar la contraseña de un administrador. Podrían usar esa contraseña de inmediato para empezar a robar datos, abrir brechas en las defensas de la red o instalar puertas traseras.
Aunque es mucho trabajo y, en cierta medida, suerte, un ataque CSRF exitoso puede ser como ganar la lotería para los piratas informáticos, independientemente de cuál sea su objetivo final. A la hora de atacar una red, casi cualquier otro tipo de ataque requeriría meses de reconocimiento lento y lento, tratando de mantenerse fuera del radar del personal de SIEM y ciberseguridad. Por el contrario, un solo ataque de la CSRF puede saltarse varios escalones de la cadena de ciberataque, lo que les permite empezar muy cerca de su objetivo final.
¿Cómo puedo detener los ataques de CSRF?
A diferencia de la mayoría de las vulnerabilidades, en los ataques CSRF la culpa no es realmente del código, sino de un exploit que los atacantes han creado para obligar a un navegador a realizar solicitudes que un usuario no quiere y que tal vez ni siquiera conozca. Pero pueden ser derrotados.
Uno de los mejores métodos es hacer que los desarrolladores agreguen un token CSRF a la identidad de un usuario cada vez que se genera una nueva sesión. Debe consistir en una cadena de caracteres únicos y aleatorios y ser invisible para los usuarios. A continuación, añada la solicitud del token CSRF como campo oculto a los formularios que el servidor comprueba 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 conocerán el 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 confidencial, como las solicitudes de cambio de contraseña o las órdenes de transferencia de dinero. Puede ser tan sencillo como pedirle a un usuario que haga clic en un botón para confirmar que el solicitante no es un robot o, en este caso, usar un script CSRF. Los atacantes no serán capaces de escribir una respuesta al desafío, y los usuarios que de repente reciban un desafío con el CAPTCHA sin hacer primero algo como solicitar una transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede generar una contraseña de un solo uso con un token de terceros, como un smartphone, en función de lo mucho que la organización quiera ralentizar el trabajo por motivos de seguridad.
Por último, aunque no es irrefutable, muchos navegadores como Microsoft Edge o Google Chrome ahora tienen política sobre el mismo origen existen restricciones para bloquear las solicitudes de cualquier persona que no sea el usuario local. Obligar a los usuarios a interactuar con tu sitio utilizando las versiones más actualizadas de esos navegadores puede ayudar a crear otra capa de seguridad basada en el CSRF sin sobrecargar en absoluto a los equipos de desarrollo.
Cerrando la puerta a la CSRF
Con un potencial de beneficio tan alto, es probable que los ataques CSRF nunca acaben por completo, pero esperamos que hayas aprendido por qué son tan persistentes y cómo bloquearlos definitivamente de tu red.
Para obtener más información, puede echar un vistazo a la hoja de trucos para prevenir la falsificación de solicitudes entre sitios de OWASP, que sirve como un documento vivo que narra esta vulnerabilidad a medida que evoluciona. Si realmente quieres reforzar tus conocimientos de seguridad, puedes aprender a derrotar a esta amenaza y a muchas más visitando la Secure Code Warrior blog.
¿Crees que estás listo para poner a prueba tus nuevos conocimientos defensivos? Juega un poco con el demo gratuita de la plataforma Secure Code Warrior en la actualidad.
A diferencia de los ataques dirigidos directamente a los operadores de sitios web o aplicaciones, el objetivo de muchos ataques de falsificación de solicitudes entre sitios (CSRF) es robar dinero, bienes o credenciales directamente de un usuario. Esto no significa que los operadores de sitios deban ignorar las vulnerabilidades del código CSRF, ya que, en última instancia, la sustitución de los fondos robados, en caso de un ataque puramente monetario, puede ser responsabilidad del sitio de alojamiento por 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, hay muchas cosas que tienen que fallar a favor del atacante para que funcione. A pesar de ello, son un vector de ataque extremadamente popular porque un ataque exitoso puede transferir dinero directamente a un pirata informático o configurarlo para que pueda moverse por un sitio con impunidad. Si todo sale bien para un hacker, es posible que el usuario objetivo ni siquiera sepa que ha sido víctima de un ataque.
La buena noticia es que, dado que todo tiene que ir bien para que un ataque de la CSRF funcione, existen bastantes técnicas defensivas excelentes que pueden detenerlos.
Con ese fin, analizaremos tres aspectos clave de los ataques CSRF:
- Cómo funcionan
- Por qué son tan peligrosos
- Cómo puedes establecer defensas para detenerlos.
¿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 implica crearlos. Y dado que con frecuencia se realizan en diferentes plataformas, a lo largo de los años han adquirido una variedad de nombres y apodos. Es posible que a los ataques de la CSRF se les llame XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery o Hostile Linking. A Microsoft le gusta denominarlos ataques con un solo clic en la mayor parte de su documentación. Pero todos son ataques de la CSRF y las técnicas para derrotarlos son idénticas.
Un ataque CSRF puede ocurrir si un usuario inicia sesión en un sitio que realiza negocios o realiza su trabajo. La clave es que el usuario debe iniciar sesión y autenticarse activamente en un sitio web o una aplicación. El ataque normalmente se lanza desde un sitio web secundario o un correo electrónico. A menudo, los atacantes utilizan técnicas de ingeniería social para engañar a los usuarios para que hagan clic en un enlace de un correo electrónico que los lleva a un sitio web comprometido con el script del ataque.
El sitio web comprometido contiene un script que indica al navegador activo que ejecute comandos, normalmente algo malintencionado, como cambiar la contraseña de un usuario o transferir dinero a una cuenta controlada por el atacante. Mientras el usuario esté autenticado, el sitio pensará que los comandos los ha emitido el usuario autorizado. ¿Por qué no lo haría? El usuario ya se ha autenticado y ha proporcionado las contraseñas necesarias para acceder al sitio. Incluso pueden estar ubicados dentro de una geocerca, correctamente sentados en la terminal de su oficina. Si quieren cambiar su contraseña o transferir fondos, no hay motivo para no creer que son ellos los que hacen la solicitud.
Al analizar los elementos del ataque, queda claro por qué es tan difícil de llevar a cabo para el atacante. Para empezar, el usuario debe estar autenticado activamente en el sitio en el que se produce el ataque. Si recibe un correo electrónico con una secuencia de comandos de ataque después de que un usuario haya finalizado su sesión en el navegador o haya cerrado sesión, el ataque falla.
El atacante también se ve obligado a realizar muchos reconocimientos en el sitio objetivo para saber qué scripts aceptará ese sitio. Los atacantes no pueden ver la pantalla de la víctima y cualquier comentario que reciba del sitio web irá dirigido a la víctima, no al atacante. A menos que el atacante pueda ver pruebas de que su ataque ha funcionado (por ejemplo, si de repente aparece dinero en su cuenta), ni siquiera sabrá de inmediato si ha tenido éxito.
Dentro de los parámetros difíciles, pero no imposibles, de tener el usuario conectado en el momento del ataque y saber qué scripts aceptará el sitio objetivo, el código para ejecutar un ataque CSRF puede ser extremadamente simple, aunque varía según el sitio en sí.
Supongamos que una aplicación bancaria o financiera usa solicitudes GET para transferir dinero, de la siguiente manera:
OBTENGA 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.
Sin embargo, si el usuario objetivo recibe un correo electrónico, tal vez uno disfrazado como si procediera de un colega, se podría incrustar un script de ataque CSRF en la acción de clic:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">¿Puede leer rápidamente este informe trimestral? <a></a></a>
Si el usuario objetivo caía en la trampa del enlace de ingeniería social y hacía clic en él mientras la sesión del navegador con la aplicación financiera aún estaba abierta, su navegador le pediría a la aplicación que enviara 100.000 dólares a la cuenta de ShadyLady15.
El script podría incluso ocultarse en una imagen invisible que el usuario no vería, pero que aun así podría hacer que el navegador realizara la solicitud, de la siguiente manera:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
El resultado es el mismo. ShadyLady15 recibe 100.000 dólares sin que nadie detecte el ataque.
¿Por qué es tan peligrosa la CSRF?
Los ataques CSRF son populares hoy en día por la misma razón por la que los ataques de ransomware siguen circulando. Hay muy pocos saltos entre los atacantes y el dinero de la víctima. En un ataque de ransomware, los sistemas se cifran y se extorsiona a los usuarios para obtener dinero para descifrar esos datos. Con un ataque de CSRF, se necesitan incluso menos pasos. Cuando trabajan, las víctimas simplemente envían dinero a los atacantes sin saberlo.
Más allá de los ataques directos al dinero de la víctima o a las finanzas de una empresa, los ataques CSRF exitosos se pueden utilizar para comprometer una red que utiliza usuarios válidos. Imagínese si un atacante pudiera usar un exploit del CSRF para cambiar la contraseña de un administrador. Podrían usar esa contraseña de inmediato para empezar a robar datos, abrir brechas en las defensas de la red o instalar puertas traseras.
Aunque es mucho trabajo y, en cierta medida, suerte, un ataque CSRF exitoso puede ser como ganar la lotería para los piratas informáticos, independientemente de cuál sea su objetivo final. A la hora de atacar una red, casi cualquier otro tipo de ataque requeriría meses de reconocimiento lento y lento, tratando de mantenerse fuera del radar del personal de SIEM y ciberseguridad. Por el contrario, un solo ataque de la CSRF puede saltarse varios escalones de la cadena de ciberataque, lo que les permite empezar muy cerca de su objetivo final.
¿Cómo puedo detener los ataques de CSRF?
A diferencia de la mayoría de las vulnerabilidades, en los ataques CSRF la culpa no es realmente del código, sino de un exploit que los atacantes han creado para obligar a un navegador a realizar solicitudes que un usuario no quiere y que tal vez ni siquiera conozca. Pero pueden ser derrotados.
Uno de los mejores métodos es hacer que los desarrolladores agreguen un token CSRF a la identidad de un usuario cada vez que se genera una nueva sesión. Debe consistir en una cadena de caracteres únicos y aleatorios y ser invisible para los usuarios. A continuación, añada la solicitud del token CSRF como campo oculto a los formularios que el servidor comprueba 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 conocerán el 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 confidencial, como las solicitudes de cambio de contraseña o las órdenes de transferencia de dinero. Puede ser tan sencillo como pedirle a un usuario que haga clic en un botón para confirmar que el solicitante no es un robot o, en este caso, usar un script CSRF. Los atacantes no serán capaces de escribir una respuesta al desafío, y los usuarios que de repente reciban un desafío con el CAPTCHA sin hacer primero algo como solicitar una transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede generar una contraseña de un solo uso con un token de terceros, como un smartphone, en función de lo mucho que la organización quiera ralentizar el trabajo por motivos de seguridad.
Por último, aunque no es irrefutable, muchos navegadores como Microsoft Edge o Google Chrome ahora tienen política sobre el mismo origen existen restricciones para bloquear las solicitudes de cualquier persona que no sea el usuario local. Obligar a los usuarios a interactuar con tu sitio utilizando las versiones más actualizadas de esos navegadores puede ayudar a crear otra capa de seguridad basada en el CSRF sin sobrecargar en absoluto a los equipos de desarrollo.
Cerrando la puerta a la CSRF
Con un potencial de beneficio tan alto, es probable que los ataques CSRF nunca acaben por completo, pero esperamos que hayas aprendido por qué son tan persistentes y cómo bloquearlos definitivamente de tu red.
Para obtener más información, puede echar un vistazo a la hoja de trucos para prevenir la falsificación de solicitudes entre sitios de OWASP, que sirve como un documento vivo que narra esta vulnerabilidad a medida que evoluciona. Si realmente quieres reforzar tus conocimientos de seguridad, puedes aprender a derrotar a esta amenaza y a muchas más visitando la Secure Code Warrior blog.
¿Crees que estás listo para poner a prueba tus nuevos conocimientos defensivos? Juega un poco con el demo gratuita de la plataforma Secure Code Warrior en la actualidad.
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of 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 solicitudes entre sitios (CSRF) es robar dinero, bienes o credenciales directamente de un usuario. Esto no significa que los operadores de sitios deban ignorar las vulnerabilidades del código CSRF, ya que, en última instancia, la sustitución de los fondos robados, en caso de un ataque puramente monetario, puede ser responsabilidad del sitio de alojamiento por 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, hay muchas cosas que tienen que fallar a favor del atacante para que funcione. A pesar de ello, son un vector de ataque extremadamente popular porque un ataque exitoso puede transferir dinero directamente a un pirata informático o configurarlo para que pueda moverse por un sitio con impunidad. Si todo sale bien para un hacker, es posible que el usuario objetivo ni siquiera sepa que ha sido víctima de un ataque.
La buena noticia es que, dado que todo tiene que ir bien para que un ataque de la CSRF funcione, existen bastantes técnicas defensivas excelentes que pueden detenerlos.
Con ese fin, analizaremos tres aspectos clave de los ataques CSRF:
- Cómo funcionan
- Por qué son tan peligrosos
- Cómo puedes establecer defensas para detenerlos.
¿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 implica crearlos. Y dado que con frecuencia se realizan en diferentes plataformas, a lo largo de los años han adquirido una variedad de nombres y apodos. Es posible que a los ataques de la CSRF se les llame XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery o Hostile Linking. A Microsoft le gusta denominarlos ataques con un solo clic en la mayor parte de su documentación. Pero todos son ataques de la CSRF y las técnicas para derrotarlos son idénticas.
Un ataque CSRF puede ocurrir si un usuario inicia sesión en un sitio que realiza negocios o realiza su trabajo. La clave es que el usuario debe iniciar sesión y autenticarse activamente en un sitio web o una aplicación. El ataque normalmente se lanza desde un sitio web secundario o un correo electrónico. A menudo, los atacantes utilizan técnicas de ingeniería social para engañar a los usuarios para que hagan clic en un enlace de un correo electrónico que los lleva a un sitio web comprometido con el script del ataque.
El sitio web comprometido contiene un script que indica al navegador activo que ejecute comandos, normalmente algo malintencionado, como cambiar la contraseña de un usuario o transferir dinero a una cuenta controlada por el atacante. Mientras el usuario esté autenticado, el sitio pensará que los comandos los ha emitido el usuario autorizado. ¿Por qué no lo haría? El usuario ya se ha autenticado y ha proporcionado las contraseñas necesarias para acceder al sitio. Incluso pueden estar ubicados dentro de una geocerca, correctamente sentados en la terminal de su oficina. Si quieren cambiar su contraseña o transferir fondos, no hay motivo para no creer que son ellos los que hacen la solicitud.
Al analizar los elementos del ataque, queda claro por qué es tan difícil de llevar a cabo para el atacante. Para empezar, el usuario debe estar autenticado activamente en el sitio en el que se produce el ataque. Si recibe un correo electrónico con una secuencia de comandos de ataque después de que un usuario haya finalizado su sesión en el navegador o haya cerrado sesión, el ataque falla.
El atacante también se ve obligado a realizar muchos reconocimientos en el sitio objetivo para saber qué scripts aceptará ese sitio. Los atacantes no pueden ver la pantalla de la víctima y cualquier comentario que reciba del sitio web irá dirigido a la víctima, no al atacante. A menos que el atacante pueda ver pruebas de que su ataque ha funcionado (por ejemplo, si de repente aparece dinero en su cuenta), ni siquiera sabrá de inmediato si ha tenido éxito.
Dentro de los parámetros difíciles, pero no imposibles, de tener el usuario conectado en el momento del ataque y saber qué scripts aceptará el sitio objetivo, el código para ejecutar un ataque CSRF puede ser extremadamente simple, aunque varía según el sitio en sí.
Supongamos que una aplicación bancaria o financiera usa solicitudes GET para transferir dinero, de la siguiente manera:
OBTENGA 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.
Sin embargo, si el usuario objetivo recibe un correo electrónico, tal vez uno disfrazado como si procediera de un colega, se podría incrustar un script de ataque CSRF en la acción de clic:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">¿Puede leer rápidamente este informe trimestral? <a></a></a>
Si el usuario objetivo caía en la trampa del enlace de ingeniería social y hacía clic en él mientras la sesión del navegador con la aplicación financiera aún estaba abierta, su navegador le pediría a la aplicación que enviara 100.000 dólares a la cuenta de ShadyLady15.
El script podría incluso ocultarse en una imagen invisible que el usuario no vería, pero que aun así podría hacer que el navegador realizara la solicitud, de la siguiente manera:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
El resultado es el mismo. ShadyLady15 recibe 100.000 dólares sin que nadie detecte el ataque.
¿Por qué es tan peligrosa la CSRF?
Los ataques CSRF son populares hoy en día por la misma razón por la que los ataques de ransomware siguen circulando. Hay muy pocos saltos entre los atacantes y el dinero de la víctima. En un ataque de ransomware, los sistemas se cifran y se extorsiona a los usuarios para obtener dinero para descifrar esos datos. Con un ataque de CSRF, se necesitan incluso menos pasos. Cuando trabajan, las víctimas simplemente envían dinero a los atacantes sin saberlo.
Más allá de los ataques directos al dinero de la víctima o a las finanzas de una empresa, los ataques CSRF exitosos se pueden utilizar para comprometer una red que utiliza usuarios válidos. Imagínese si un atacante pudiera usar un exploit del CSRF para cambiar la contraseña de un administrador. Podrían usar esa contraseña de inmediato para empezar a robar datos, abrir brechas en las defensas de la red o instalar puertas traseras.
Aunque es mucho trabajo y, en cierta medida, suerte, un ataque CSRF exitoso puede ser como ganar la lotería para los piratas informáticos, independientemente de cuál sea su objetivo final. A la hora de atacar una red, casi cualquier otro tipo de ataque requeriría meses de reconocimiento lento y lento, tratando de mantenerse fuera del radar del personal de SIEM y ciberseguridad. Por el contrario, un solo ataque de la CSRF puede saltarse varios escalones de la cadena de ciberataque, lo que les permite empezar muy cerca de su objetivo final.
¿Cómo puedo detener los ataques de CSRF?
A diferencia de la mayoría de las vulnerabilidades, en los ataques CSRF la culpa no es realmente del código, sino de un exploit que los atacantes han creado para obligar a un navegador a realizar solicitudes que un usuario no quiere y que tal vez ni siquiera conozca. Pero pueden ser derrotados.
Uno de los mejores métodos es hacer que los desarrolladores agreguen un token CSRF a la identidad de un usuario cada vez que se genera una nueva sesión. Debe consistir en una cadena de caracteres únicos y aleatorios y ser invisible para los usuarios. A continuación, añada la solicitud del token CSRF como campo oculto a los formularios que el servidor comprueba 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 conocerán el 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 confidencial, como las solicitudes de cambio de contraseña o las órdenes de transferencia de dinero. Puede ser tan sencillo como pedirle a un usuario que haga clic en un botón para confirmar que el solicitante no es un robot o, en este caso, usar un script CSRF. Los atacantes no serán capaces de escribir una respuesta al desafío, y los usuarios que de repente reciban un desafío con el CAPTCHA sin hacer primero algo como solicitar una transferencia de dinero sabrán que algo está pasando. Como alternativa, se puede generar una contraseña de un solo uso con un token de terceros, como un smartphone, en función de lo mucho que la organización quiera ralentizar el trabajo por motivos de seguridad.
Por último, aunque no es irrefutable, muchos navegadores como Microsoft Edge o Google Chrome ahora tienen política sobre el mismo origen existen restricciones para bloquear las solicitudes de cualquier persona que no sea el usuario local. Obligar a los usuarios a interactuar con tu sitio utilizando las versiones más actualizadas de esos navegadores puede ayudar a crear otra capa de seguridad basada en el CSRF sin sobrecargar en absoluto a los equipos de desarrollo.
Cerrando la puerta a la CSRF
Con un potencial de beneficio tan alto, es probable que los ataques CSRF nunca acaben por completo, pero esperamos que hayas aprendido por qué son tan persistentes y cómo bloquearlos definitivamente de tu red.
Para obtener más información, puede echar un vistazo a la hoja de trucos para prevenir la falsificación de solicitudes entre sitios de OWASP, que sirve como un documento vivo que narra esta vulnerabilidad a medida que evoluciona. Si realmente quieres reforzar tus conocimientos de seguridad, puedes aprender a derrotar a esta amenaza y a muchas más visitando la Secure Code Warrior blog.
¿Crees que estás listo para poner a prueba tus nuevos conocimientos defensivos? Juega un poco con el demo gratuita de la plataforma Secure Code Warrior en la actualidad.
Tabla de contenido
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
