¿Qué es la falsificación de solicitudes entre sitios (CSRF)?

Las vulnerabilidades de falsificación de solicitudes entre sitios (CSRF o XSRF) rara vez son altas o críticas en sus clasificaciones de gravedad. Sin embargo, todavía pueden hacer mucho daño. Han sido la segunda vulnerabilidad de WordPress más común en los últimos años después de las vulnerabilidades Cross-Site Scripting (XSS). Comprenderá cómo proteger mejor su sitio web si sabe qué es una vulnerabilidad CSRF y cómo los atacantes suelen explotarla.

Moverse por la política del mismo origen

Una vulnerabilidad CSRF hace posible que un atacante eluda una característica estándar del navegador llamada política del mismo origen. Todos los navegadores web siguen esta regla para evitar el tipo de interferencia que permiten los CSRF. Normalmente, cuando está cargando una página web, su navegador solo interactúa con un dominio o subdominio, además de las excepciones permitidas. Y solo aceptará contenido a través de un protocolo, HTTP o HTTPS (no ambos), sin advertirle que hay un problema. Si las personas malintencionadas eluden la política del mismo origen, también pueden engañarlo para que haga clic en enlaces que realizan acciones no deseadas al interactuar inesperadamente con un sitio diferente.

Visualmente, tendría pocas o ninguna pista de que está interactuando con otro sitio de una manera no deseada. El secuestro de clics funciona así. Si su sitio de WordPress ha sido explotado a través de una vulnerabilidad CSRF, usted y sus visitantes podrían estar sujetos a phishing, clickjacking y cosas peores.

En esta guía, profundizaremos en los detalles de las falsificaciones de solicitudes entre sitios. Veremos un ejemplo específico de una vulnerabilidad CSRF para que comprenda cómo funcionan. Luego, le mostraremos lo que puede hacer para evitar que surjan vulnerabilidades CSRF en su sitio. También sugeriremos algunas formas de negar o limitar el daño que puede causar un exploit CSRF exitoso al fortalecer su sitio contra estos y otros tipos de ataques.

Vamos a ver.

¿Cómo afecta un ataque de falsificación de solicitud entre sitios (CSRF) a su sitio de WordPress?

Cuando un ataque CSRF tiene éxito, sus víctimas autorizan sin querer una acción dañina, como una actualización de sus credenciales de inicio de sesión. Pueden ser engañados para permitir que un atacante se haga cargo de su cuenta de usuario. Peor aún, una víctima de un exploit CSRF podría permitir que los atacantes inicien transferencias financieras en su nombre.

Si un complemento en su sitio de WordPress contiene una vulnerabilidad CSRF, un atacante podría secuestrar algunas cuentas de usuario. Ese sería uno de los peores escenarios. Si una cuenta robada tiene una función administrativa en WordPress o el usuario reutiliza su contraseña en otros sitios, el daño podría ser extenso.

¿Cómo funciona un ataque CSRF?

Deben existir tres condiciones diferentes para que un pirata informático haga que un ataque CSRF funcione. Si los entiende en un nivel general, tendrá una buena comprensión práctica de algunos fundamentos de seguridad web.

1. Manejo de sesiones basado en cookies

Al igual que otras aplicaciones sin estado, WordPress se basa en cookies de sesión para identificar a los usuarios. En condiciones de seguridad bajas o comprometidas, un atacante podría generar algunas cookies de sesión falsas o manipular a un usuario que inició sesión para realizar alguna acción no deseada. WordPress aceptará solicitudes falsificadas y manipuladas que sean o parezcan ser de un usuario que haya iniciado sesión.

Si bien los exploits CSRF a menudo se enfocan en el manejo de sesiones basadas en cookies, ese no es su único objetivo. Los ataques CSRF pueden ser efectivos contra cualquier aplicación que agregue automáticamente credenciales de usuario a las solicitudes. La autenticación basada en certificados y la autenticación básica HTTP también son susceptibles a las vulnerabilidades CSRF por este motivo.

2. Se puede orientar una acción relevante

Debe haber alguna acción dentro de la aplicación de destino que se pueda engañar a las víctimas para que la tomen. Esta podría ser una acción privilegiada como cambiar los permisos de usuario. Podría estar relacionado con datos específicos del usuario, como actualizar la contraseña de un usuario. Estas son acciones comunes en todas las aplicaciones web, incluido WordPress. Tienen valor como objetivos para los piratas informáticos porque pueden abrirles el camino para robar cuentas de usuario y profundizar en formas de participar en robos, fraudes u otras actividades maliciosas.

3. Sin parámetros de solicitud impredecibles

Las solicitudes que realizan la acción específica deben ser conocidas o predecibles. Si las solicitudes dirigidas no necesitan contener parámetros cuyos valores el atacante no pueda determinar o adivinar, son más vulnerables a la manipulación.

Por ejemplo, si una solicitud de cambio de contraseña válida debe incluir la contraseña existente, es seguro, siempre que un atacante no conozca la contraseña. Los tokens CSRF y las cookies de SameSite agregan más obstáculos a los atacantes cuando los desarrolladores los usan para proteger su código. Pero a veces los desarrolladores no implementan estos métodos de seguridad correctamente o en absoluto. (Esta es la razón por la cual la autenticación de usuario sólida y sin contraseña es valiosa).

Explotación de una vulnerabilidad CSRF para cambiar los correos electrónicos de la cuenta de usuario: un ejemplo

Aquí hay un ejemplo más detallado. En realidad, no funcionará, pero ilustra los conceptos principales en juego para un exploit CSRF efectivo.

Considere una solicitud de cambio de correo electrónico. Cuando un usuario realiza esta acción, realiza una solicitud HTTP similar a esta para el servidor web que la recibe:

 POST /test HTTP/1.1 Host: yourwebsite.com Content-Type: application/x-www-form-urlencoded Content-Length: 60 Cookie: session=yvthgjrudhgeQkAPzeQ5gHgTvlyxHfsAfE;[email protected]

Por qué funciona

Esto cumple con las condiciones requeridas para CSRF si/porque:

• El sitio/aplicación de destino utiliza una cookie de sesión para identificar qué usuario emitió la solicitud, y no existen otros tokens o mecanismos para rastrear las sesiones de los usuarios. Esta es la razón por la que los desarrolladores deben usar tokens CSRF y/o cookies de SameSite.
• Cambiar la dirección de correo electrónico de un usuario es una acción relevante en interés de un atacante. ¡Seguro que lo es! Si puede cambiar la dirección de correo electrónico de un usuario a una que usted controle, puede tomar el control total de su cuenta.
• El atacante conoce los parámetros de solicitud que necesita para cambiar la dirección de correo electrónico de un usuario y puede generar valores válidos para ellos. Estos parámetros no son secretos y no es difícil determinar qué direcciones de correo electrónico usan muchas personas para sus cuentas en línea. La cookie de sesión es más complicada.

Cómo un atacante podría robar cookies de sesión

El principal obstáculo del atacante es determinar los valores reales de los parámetros que accederán a la cuenta de un usuario en particular. Podrían hacerlo mediante la creación de una página web dirigida a los usuarios del sitio objetivo. Este sitio engañoso puede tener enlaces o botones que parecen tener un propósito legítimo, como solicitar obsequios. En realidad, si haces clic en esos enlaces o botones, la única persona que obtiene algunos obsequios dulces de forma gratuita es el atacante.

Cuando hace clic en estos enlaces fraudulentos, realizarán una solicitud de cambio de dirección al sitio objetivo y vulnerable a CSRF. Si ha iniciado sesión en ese sitio, la solicitud será válida. Le robaron su cuenta: usted entregó sus llaves.

Los usuarios de un sitio de WordPress que permanecen conectados tienen una cookie de sesión activa en su navegador que persiste incluso cuando están en un sitio diferente. Su navegador incluirá automáticamente esa cookie de sesión dentro de una solicitud falsificada. WordPress puede ver esto como una solicitud de cambio de dirección perfectamente válida, aunque provenga de otro sitio y el usuario no tenga idea de que lo está haciendo.

Suponiendo que no existan otras medidas de seguridad, como el atributo de cookie de SameSite, el sitio de destino vulnerable procesará una solicitud falsificada igual que una válida. Si el sitio web objetivo no aplica un paso de confirmación de cambio de dirección, o si el atacante tiene una forma de evitarlo, el atacante cambiará con éxito la dirección del usuario a cualquier dirección que elija.

Cómo se envía un ataque CSRF a un sitio web vulnerable

Los mecanismos de entrega para los ataques CSRF y los ataques de secuencias de comandos de sitios cruzados reflejados (XSS reflejados) son similares.

En la mayoría de los casos, los atacantes colocarán su código malicioso en un sitio engañoso que controlan. Este podría ser un sitio legítimo que ya han comprometido, razón por la cual Google mantiene una lista de sitios engañosos. ¡Todos los navegadores advertirán a sus usuarios si estás en esta lista! Es por eso que iThemes Security verifica todos los días para asegurarse de que su sitio no se haya convertido en una herramienta de piratas informáticos.

Lograr que las víctimas potenciales visiten un sitio web engañoso es simplemente una cuestión de redes sociales básicas y marketing por correo electrónico. A veces, el código malicioso simplemente se coloca en un sitio popular en un área activa.

Es posible que un atacante ni siquiera necesite un sitio web para atraer a sus víctimas. Algunos exploits simples de CSRF usan el método GET. Esto es lo que hace su navegador cuando hace clic en un enlace o ingresa una URL en la barra de direcciones. Realiza una solicitud GET utilizando la URL en el enlace o que usted proporciona. A veces, un ataque CSRF se puede ejecutar por completo con una sola solicitud GET a un sitio web vulnerable. En situaciones como esta, es posible que el atacante no necesite usar un sitio web engañoso. Simplemente pueden alimentar a sus víctimas con una URL maliciosa directamente.

Protección de su sitio contra ataques de falsificación de solicitudes entre sitios (CSRF)

Las vulnerabilidades CSRF surgen con frecuencia en complementos y, a veces, en temas. Cuando los piratas informáticos los atacan, no es difícil protegerse. Use complementos y temas de calidad en los que confíe, elimine los que no esté usando y mantenga todo su software actualizado . También debe implementar una política de seguridad de usuario bien pensada y considerar dejar de usar contraseñas. Si se explota una vulnerabilidad CSRF (o cualquier otra) en su sitio para obtener acceso a las cuentas de los usuarios, no le servirá de mucho al atacante si está utilizando claves de paso. Nadie puede robar lo que no existe.

Además de administrar actualizaciones y advertirle sobre complementos y temas vulnerables, iThemes Security Pro facilita la configuración y administración de reglas de seguridad basadas en roles y usuarios. Delegar privilegios basados ​​en el principio del mínimo privilegio. Asegure su inicio de sesión, recuperación de contraseña y formularios de contacto con CAPTCHA. No le dé a sus usuarios mayores capacidades de las que necesitan. Exigir a los usuarios con mayores privilegios que utilicen métodos de autenticación más sólidos. Y definitivamente adopte la forma más conveniente y sencilla de iniciar sesión en WordPress sin una contraseña: ¡Passkeys!

El mejor complemento de seguridad de WordPress para asegurar y proteger WordPress

Actualmente, WordPress funciona en más del 40% de todos los sitios web, por lo que se ha convertido en un objetivo fácil para los piratas informáticos con intenciones maliciosas. El complemento iThemes Security Pro elimina las conjeturas de la seguridad de WordPress para que sea más fácil asegurar y proteger su sitio web de WordPress. Es como tener un experto en seguridad a tiempo completo en el personal que supervisa y protege constantemente su sitio de WordPress por usted.

Obtenga iThemes Security Pro

dan knauss

Dan Knauss es el generalista de contenido técnico de StellarWP. Ha sido escritor, profesor y autónomo trabajando en código abierto desde finales de la década de 1990 y con WordPress desde 2004.