Comprender los ataques CSRF y bloquear las vulnerabilidades CSRF
Publicado: 2022-11-21Las vulnerabilidades web son rampantes y aumentan constantemente. Mantener la seguridad y privacidad de tus usuarios es más importante que nunca. No abordar las vulnerabilidades web puede arruinar su reputación y multas considerables por parte de los reguladores, y también perderá la confianza de sus usuarios.
Los sitios web y las aplicaciones web son vulnerables al malware, el spam y otros ataques. Este artículo se centra en uno de esos vectores de ataque: los ataques de falsificación de solicitudes entre sitios (CSRF). Los ataques CSRF son particularmente preocupantes porque pueden ocurrir sin el conocimiento del usuario. También son difíciles de detectar para un desarrollador o propietario de un sitio web porque las solicitudes maliciosas se parecen mucho a las solicitudes genuinas.
Este artículo explora un ataque CSRF, cómo funciona y los pasos que puede seguir para prepararse para uno.
¿Qué es un ataque CSRF?
Un ataque de falsificación de solicitudes entre sitios, también conocido como ataque CSRF, engaña a un usuario autenticado para que realice acciones no deseadas mediante el envío de solicitudes maliciosas sin que se den cuenta.
Por lo general, un ataque CSRF involucra solicitudes de cambio de estado porque el atacante no recibe una respuesta. Los ejemplos de tales solicitudes incluyen la eliminación de un registro, el cambio de una contraseña, la compra de un producto o el envío de un mensaje. Todo esto puede ocurrir sin el conocimiento del usuario.
El atacante malintencionado suele utilizar la ingeniería social para enviar un enlace a un usuario desprevenido a través del chat o el correo electrónico.
Cuando el usuario hace clic en el enlace, ejecuta los comandos que establece el atacante.
Por ejemplo, hacer clic en un enlace puede transferir fondos desde la cuenta de un usuario. O bien, puede cambiar la dirección de correo electrónico de un usuario evitando que recupere el acceso a la cuenta.
¿Cómo funciona un ataque CSRF?
Lograr que el usuario inicie una solicitud de cambio de estado mientras está conectado es el primer paso y el más crucial en un ataque CSRF. Con los ataques CSRF, el atacante tiene como objetivo que un usuario autenticado envíe, sin saberlo, una solicitud web maliciosa a un sitio web o aplicación web. Estas solicitudes pueden consistir en cookies, parámetros de URL y otros tipos de datos que parecen normales para el usuario.
Para que un ataque CSRF tenga éxito, deben darse las siguientes condiciones:
- Un usuario autenticado debe iniciar sesión en una aplicación web que utiliza cookies para la gestión de la sesión.
- Un atacante debe crear una solicitud falsificada de cambio de estado.
- Las solicitudes genuinas manejadas por el servidor de destino no deben contener parámetros impredecibles. Por ejemplo, la solicitud no debe esperar una contraseña como parámetro con fines de verificación antes de iniciar la solicitud de cambio de estado.
El método más común para completar los ataques CSRF es usar cookies en aplicaciones con una política de cookies de SameSite débil. Los navegadores web incluyen cookies de forma automática y, a menudo, de forma anónima, y guardan las cookies utilizadas por un dominio en cualquier solicitud web que un usuario envíe a ese dominio.
La política de cookies de SameSite define cómo el navegador en contextos de navegación entre sitios trata la cookie. Si se establece en estricta, la cookie no se comparte en contextos de navegación entre sitios, lo que evita los ataques CSRF. El navegador adjunta la cookie en todos los contextos de sitios cruzados si está configurado en ninguno. Esto deja a la aplicación vulnerable a los ataques CSRF.
Cuando un usuario, sin saberlo, envía una solicitud maliciosa a través de un navegador web, las cookies guardadas hacen que la solicitud parezca legítima para el servidor. Luego, el servidor responde a la solicitud cambiando la cuenta del usuario, cambiando el estado de la sesión o devolviendo los datos solicitados.
Echemos un vistazo más de cerca a dos ejemplos de vías de ataque CSRF, una con una solicitud GET y la otra con una solicitud POST.
CSRF para una solicitud GET
Primero, considere una solicitud GET utilizada por una aplicación web de banca financiera, donde el ataque explota una solicitud GET y la entrega de un hipervínculo.
Supongamos que la solicitud GET para transferir dinero se parece a esto:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1
En la solicitud genuina anterior, el usuario solicita transferir $1,000 a una cuenta con 547895
como pago por los productos comprados.
Si bien esta solicitud es explícita, simple y práctica, expone al titular de la cuenta a un ataque CSRF. Esto se debe a que la solicitud no requiere detalles que un atacante pueda no conocer. Entonces, para iniciar un ataque, un atacante solo necesitaría alterar los parámetros de esta solicitud (la cantidad y el número de cuenta) para crear una solicitud falsificada ejecutable.
La solicitud maliciosa sería efectiva para cualquiera de los usuarios del banco siempre que tengan sesiones continuas administradas por cookies.
Así es como se vería la solicitud falsificada para transferir $500 a la cuenta de un pirata informático (aquí, número 654585
). Tenga en cuenta que el siguiente ejemplo es una versión muy simplificada de los pasos involucrados en un ataque CSRF para obtener una explicación.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1
Una vez que se completa, el atacante debe encontrar una forma de engañar al usuario para que envíe esta solicitud mientras está conectado a su aplicación de banca en línea. Una de las formas de hacerlo es crear un hipervínculo inofensivo que llame la atención del usuario. El enlace puede verse así:
<a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.
Dado que el atacante ha encontrado las direcciones de correo electrónico correctas de sus objetivos, puede enviarlas por correo electrónico a muchos clientes bancarios. Aquellos que hagan clic en el enlace mientras están conectados activarán la solicitud para enviar al atacante $ 500 desde la cuenta registrada.
CSRF para una solicitud POST
Veamos cómo la misma institución financiera experimentaría un CSRF si solo aceptara solicitudes POST. En este caso, la entrega de hipervínculos utilizada en el ejemplo de solicitud GET no funcionaría. Por lo tanto, un ataque CSRF exitoso requeriría que un atacante creara un formulario HTML. La solicitud genuina para enviar $1,000 por un producto comprado se vería así:
POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895
Esta solicitud POST requiere una cookie para determinar la identidad del usuario, la cantidad que desea enviar y la cuenta que desea enviar. Los atacantes pueden modificar esta solicitud para realizar un ataque CSRF.
El atacante solo debe agregar una cookie genuina a una solicitud falsificada para que el servidor procese la transferencia. Pueden hacerlo creando un hipervínculo de apariencia inofensiva que lleva al usuario a una página web desencadenante que se ve así:
<html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>
Ya hemos establecido la cantidad y los parámetros de la cuenta en el formulario de arriba. Una vez que un usuario autenticado visita la página, el navegador agrega la cookie de sesión antes de enviar la solicitud al servidor. El servidor luego reenvía $500 a la cuenta del hacker.
3 formas de reducir los ataques CSRF
Existen varios métodos para prevenir y mitigar drásticamente los posibles ataques CSRF en su sitio web o aplicación web, que incluyen:
- Uso de tokens CSRF
- Usando el encabezado de referencia
- Elegir una solución de alojamiento centrada en la seguridad, como Kinsta
Cómo prevenir ataques CSRF usando tokens CSRF
Un sitio web seguro CSRF asigna a cada sesión un token único y lo comparte con el lado del servidor y el navegador del cliente. Cada vez que un navegador envía una solicitud confidencial, el servidor espera que contenga el token CSRF asignado. Si tiene el token incorrecto, el servidor lo descarta. El token CSRF no se almacena en cookies de sesión en el navegador del cliente por motivos de seguridad.
Vulnerabilidades potenciales de los tokens CSRF
Aunque los tokens CSRF son una excelente medida de seguridad, este método no es a prueba de ataques. Algunas de las vulnerabilidades que acompañan a los tokens CSRF incluyen:
- Omisión de validación: algunas aplicaciones omiten el paso de verificación si no encuentran un token. Si un atacante obtiene acceso al código que contiene un token, puede eliminar ese token y ejecutar con éxito un ataque CSRF. Entonces, si una solicitud válida a un servidor se ve así:
POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433
Un atacante solo necesita eliminar el token y enviarlo así para ejecutar el ataque:
POST /change_password POST body: password=pass123
- Tokens agrupados : algunas aplicaciones mantienen un conjunto de tokens para validar las sesiones de los usuarios en lugar de designar un token específico para una sesión. Un atacante solo necesita obtener uno de los tokens que ya están en el grupo para hacerse pasar por cualquiera de los usuarios del sitio.
Un atacante puede iniciar sesión en una aplicación usando su cuenta para obtener un token, como:
[application_url].com?csrf_token=93j9d8eckke20d433
Y dado que los tokens están agrupados, el atacante puede copiar y usar ese mismo token para iniciar sesión en una cuenta de usuario diferente, ya que lo usará nuevamente:
- Los CSRF se pueden copiar mediante token en la cookie : algunas aplicaciones copiarán los parámetros relacionados con un token en la cookie de un usuario. Si un atacante obtiene acceso a dicha cookie, puede crear fácilmente otra cookie, colocarla en un navegador y ejecutar un ataque CSRF.
Entonces, un atacante puede iniciar sesión en una aplicación usando su cuenta y abrir el archivo de cookies para ver lo siguiente:
Csrf_token:93j9d8eckke20d433
Luego pueden usar esta información para crear otra cookie para completar el ataque.
- Tokens no válidos : algunas aplicaciones no hacen coincidir los tokens CSRF con una sesión de usuario. En tales casos, un atacante puede iniciar sesión genuinamente en una sesión, obtener un token CSRF similar a los anteriores y usarlo para orquestar un ataque CSRF en la sesión de una víctima.
Cómo prevenir ataques CSRF con el encabezado de referencia
Otra estrategia para prevenir ataques CSRF es usar el encabezado de referencia. En HTTP, los encabezados de referencia indican el origen de las solicitudes. Por lo general, se utilizan para realizar análisis, optimización y registro.
También puede habilitar la verificación de encabezados de referencia en el lado del servidor para evitar ataques CSRF. El lado del servidor verifica el origen de origen de la solicitud y determina el origen de destino de la solicitud. Si coinciden, se permite la solicitud. Si hay una discrepancia, el servidor descarta la solicitud.
Usar encabezados de referencia es mucho más fácil que usar tokens porque no requiere identificación de usuario individual.
Vulnerabilidades potenciales del encabezado de referencia
Al igual que los tokens CSRF, los encabezados de referencia tienen algunas vulnerabilidades importantes.
En primer lugar, los encabezados de referencia no son obligatorios y algunos sitios enviarán solicitudes sin ellos. Si CSRF no tiene la política para manejar solicitudes sin encabezados, los atacantes pueden usar solicitudes sin encabezados para ejecutar ataques de cambio de estado.
Además, este método se ha vuelto menos efectivo con la reciente introducción de la política de referencia. Esta especificación evita la fuga de URL a otros dominios, dando a los usuarios más control sobre la información en el encabezado de referencia. Pueden optar por exponer parte de la información del encabezado de referencia o deshabilitarla agregando una etiqueta de metadatos en la página HTML, como se muestra a continuación:
<meta name="referrer" content="no-referrer">
El código anterior elimina el encabezado de referencia para todas las solicitudes de esta página. Hacerlo dificulta que las aplicaciones que se basan en encabezados de referencia eviten los ataques CSRF desde dicha página.
Cómo protege Kinsta contra los ataques CSRF
Además de usar el encabezado de referencia y los tokens CSRF, hay una tercera opción mucho más fácil: elegir un servicio de alojamiento seguro como Kinsta para sus sitios web y aplicaciones web proporciona una barrera mucho más fuerte y segura entre los atacantes y sus usuarios.
Además de las características de seguridad críticas, como las copias de seguridad automáticas, la autenticación de dos factores y los protocolos SFTP sobre SSH, la integración de Cloudflare de Kinsta brinda protección de nivel empresarial con protección de firewall y basada en IP.
Específicamente, Kinsta actualmente tiene alrededor de 60 reglas de firewall personalizadas para ayudar a prevenir ataques maliciosos y lidiar con vulnerabilidades graves no autenticadas en complementos y temas, incluidos los específicos que buscan vulnerabilidades CSRF.
Resumen
La falsificación de solicitudes entre sitios (CSRF) es un ataque que engaña a los usuarios autenticados para que inicien solicitudes de cambio de estado sin querer. Se dirigen a aplicaciones que no pueden diferenciar entre solicitudes de cambio de estado válidas y falsificadas.
CSRF solo puede tener éxito en aplicaciones que se basan en cookies de sesión para identificar a los usuarios registrados y tienen una política de cookies de SameSite débil. También necesitan un servidor que acepte solicitudes que no contengan parámetros desconocidos, como contraseñas. Los piratas informáticos pueden enviar ataques maliciosos mediante GET o POST.
Aunque el uso de tokens CSRF o la aplicación de la verificación del encabezado del remitente pueden prevenir algunos ataques CSRF, ambas medidas tienen vulnerabilidades potenciales que pueden hacer que sus medidas preventivas sean inútiles si no tiene cuidado.
Migrar a una plataforma de alojamiento seguro como Kinsta protege sus sitios web o aplicaciones web de los ataques CSRF. Además, la integración de Kinsta con Cloudflare evita ataques CSRF específicos.