Las vulnerabilidades de la web proliferan y aumentan constantemente. Mantener la seguridad y privacidad de tus usuarios es más importante que nunca. Si no solucionas las vulnerabilidades de la web, puedes arruinar tu reputación y recibir cuantiosas multas de los organismos reguladores, y también perderás la confianza de tus usuarios.
Los sitios web y las aplicaciones web son vulnerables al malware, al spam y a otros ataques; este artículo se centra en uno de estos vectores de ataque: los ataques de Falsificación de Petición en Sitios Cruzados (CSRF – Cross-Site Request Forgery). Los ataques CSRF son especialmente preocupantes porque pueden producirse 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 parecen muy similares a las auténticas.
Este artículo explora un analiza CSRF, cómo funciona y los pasos que puedes dar para prepararte ante uno.
Echa un vistazo a nuestra guía en vídeo para entenderlo todo sobre los ataques CSRF
¿Qué Es un Ataque CSRF?
Un ataque de falsificación de petición en sitios cruzados, también conocido como ataque CSRF, engaña a un usuario autenticado para que realice acciones no deseadas mediante el envío de peticiones maliciosas sin que se dé cuenta.
Normalmente, un ataque CSRF implica solicitudes de cambio de estado porque el atacante no recibe respuesta. Ejemplos de este tipo de solicitudes son borrar un registro, cambiar una contraseña, comprar un producto o enviar un mensaje. Todas ellas pueden ocurrir sin el conocimiento del usuario.
El atacante malicioso suele utilizar la ingeniería social para enviar a un usuario desprevenido un enlace a través del chat o del correo electrónico.
Cuando el usuario hace clic en el enlace, ejecuta los comandos que el atacante establece.
Por ejemplo, hacer clic en un enlace puede transferir fondos de la cuenta de un usuario. O puede cambiar la dirección de correo electrónico de un usuario impidiéndole recuperar el acceso a la cuenta.
¿Cómo Funciona un Ataque CSRF?
Conseguir 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 pretende que un usuario autenticado envíe sin saberlo una solicitud web maliciosa a un sitio o aplicación web. Estas peticiones pueden consistir en cookies, parámetros de URL y otros tipos de datos que al usuario le parecen normales.
Para que un ataque CSRF tenga éxito, deben darse las siguientes condiciones:
- Un usuario autenticado debe haber iniciado sesión en una aplicación web que utilice cookies para la gestión de sesiones.
- Un atacante debe crear una solicitud falsificada que cambie de estado.
- Las peticiones auténticas gestionadas por el servidor objetivo no deben contener parámetros impredecibles. Por ejemplo, la solicitud no debe esperar una contraseña como parámetro de verificación antes de iniciar la solicitud de cambio de estado.
El método más común para completar ataques CSRF es utilizar cookies en aplicaciones con una política de cookies SameSite débil. Los navegadores web incluyen cookies de forma automática y a menudo 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 SameSite define cómo trata la cookie el navegador en contextos de navegación entre sitios. Si se establece en estricto, la cookie no se comparte en contextos de navegación entre sitios, lo que evita ataques CSRF. El navegador adjunta la cookie en todos los contextos de navegación entre sitios si se establece como ninguna. Esto hace que la aplicación sea vulnerable a los ataques CSRF.
Cuando un usuario envía sin saberlo una solicitud maliciosa a través de un navegador web, las cookies guardadas hacen que la solicitud parezca legítima al servidor. El servidor responde entonces a la solicitud cambiando la cuenta del usuario, cambiando el estado de la sesión o devolviendo los datos solicitados.
Veamos con más detalle dos ejemplos de vías de ataque CSRF, una con una solicitud GET y otra con una solicitud POST.
CSRF para una Solicitud GET
En primer lugar, consideremos una solicitud GET utilizada por una aplicación web de banca financiera, en la que el ataque aprovecha una solicitud GET y la entrega de un hipervínculo.
Supongamos que la solicitud GET para transferir dinero tiene el siguiente aspecto:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1En la petición auténtica anterior, el usuario solicita transferir 1.000 dólares a una cuenta en 547895 como pago por los productos adquiridos.
Aunque esta solicitud es explícita, sencilla 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 desconocer. Así, para iniciar un ataque, un atacante sólo necesitaría alterar los parámetros de esta solicitud (el importe y el número de cuenta) para crear una solicitud falsificada ejecutable.
La petición maliciosa sería efectiva en cualquiera de los usuarios del banco mientras tuvieran sesiones en curso gestionadas por cookies.
Así es como se vería la solicitud falsificada para transferir 500 dólares a la cuenta de un hacker (aquí, el número 654585). Ten en cuenta que el ejemplo de abajo es una versión muy simplificada de los pasos que hay que seguir en un ataque CSRF para obtener una explicación.
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1Una vez hecho esto, el atacante debe idear una forma de engañar al usuario para que envíe esta solicitud mientras está conectado a su aplicación de banca online. Una de las formas de hacerlo es crear un hipervínculo inofensivo que llame la atención del usuario. El enlace puede tener este aspecto:
<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 enviar esto por correo electrónico a muchos clientes del banco. Aquellos que hagan clic en el enlace mientras están conectados, activarían la petición de enviar al atacante 500 dólares desde la cuenta conectada.
CSRF para una Solicitud POST
Veamos cómo la misma institución financiera experimentaría un CSRF si sólo aceptara peticiones POST. En este caso, el envío de hipervínculos utilizado en el ejemplo de solicitud GET no funcionaría. Por lo tanto, un ataque CSRF con éxito requeriría que un atacante creara un formulario HTML. La solicitud auténtica para enviar 1.000 dólares por un producto adquirido tendría este aspecto:
POST /online/transfer HTTP/1.1
Host: xymbank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg
amount=1000
account=547895Esta solicitud POST requiere una cookie para determinar la identidad del usuario, la cantidad que desea enviar y la cuenta a la que desea enviar. Los atacantes pueden alterar esta solicitud para realizar un ataque CSRF.
El atacante sólo debe añadir una cookie auténtica a una solicitud falsificada para que el servidor procese la transferencia. Pueden hacerlo creando un hipervínculo de aspecto inofensivo que lleve al usuario a una página web desencadenante con el siguiente aspecto:
<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 los parámetros de importe y cuenta en el formulario anterior. Una vez que un usuario autenticado visita la página, el navegador añade la cookie de sesión antes de reenviar la solicitud al servidor. El servidor reenvía entonces 500 dólares a la cuenta del hacker.
3 Formas de Abatir los Ataques CSRF
Existen varios métodos para prevenir y mitigar drásticamente los posibles ataques CSRF en tu sitio o aplicación web, entre ellos:
- Utilizar tokens CSRF
- Utilizar la cabecera de referencia
- Elegir una solución de alojamiento centrada en la seguridad, como Kinsta
Cómo Prevenir los Ataques CSRF Utilizando Tokens CSRF
Un sitio web seguro frente a CSRF asigna a cada sesión un token único y lo comparte con el servidor y el navegador del cliente. Cada vez que un navegador envía una solicitud sensible, el servidor espera que contenga el token CSRF asignado. Si contiene un token incorrecto, el servidor lo descarta. El token CSRF no se almacena en las cookies de sesión del 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 100% a prueba de ataques. Algunas de las vulnerabilidades que acompañan a los tokens CSRF son:
- Evasión de la validación – Algunas aplicaciones se saltan el paso de verificación si no encuentran un token. Si un atacante consigue acceder al código que contiene un token, puede eliminarlo y ejecutar con éxito un ataque CSRF. Así, si una solicitud válida a un servidor tiene este aspecto
POST /change_password
POST body:
password=pass123&csrf_token=93j9d8eckke20d433Un atacante sólo necesita eliminar el token y enviarlo así para ejecutar el ataque:
POST /change_password
POST body:
password=pass123- Pool de tokens – Algunas aplicaciones mantienen un pool de tokens para validar las sesiones de usuario en lugar de designar un token específico a una sesión. Un atacante sólo necesita obtener uno de los tokens ya existentes en el pool para hacerse pasar por cualquiera de los usuarios del sitio.
Un atacante puede entrar en una aplicación utilizando su cuenta para obtener un token, como por ejemplo:
[application_url].com?csrf_token=93j9d8eckke20d433Y como los tokens están agrupados, el atacante puede copiar y utilizar ese mismo token para iniciar sesión en una cuenta de usuario diferente, ya que volverá a utilizarlo:
- Los CSRF pueden copiarse en la cookie – Algunas aplicaciones copiarán los parámetros relacionados con un token en la cookie de un usuario. Si un atacante consigue acceder a dicha cookie, puede crear fácilmente otra cookie, colocarla en un navegador y ejecutar un ataque CSRF.
Así, un atacante puede entrar en una aplicación utilizando su cuenta y abrir el archivo cookie para ver lo siguiente:
Csrf_token:93j9d8eckke20d433A continuación, pueden utilizar esta información para crear otra cookie y 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 entrar realmente en una sesión, obtener un token CSRF similar a los anteriores y utilizarlo para orquestar un ataque CSRF a la sesión de una víctima.
Cómo Prevenir los Ataques CSRF con el Encabezado Referrer
Otra estrategia para prevenir los ataques CSRF es utilizar el encabezado referrer. En HTTP, los encabezados referrer indican el origen de las peticiones. Suelen utilizarse para realizar análisis, optimización y registro.
También puedes activar la comprobación de los encabezados de referencia en el lado del servidor para evitar ataques CSRF. El lado del servidor comprueba el origen de la solicitud y determina el origen de destino de la solicitud. Si coinciden, se permite la solicitud. Si no coinciden, el servidor rechaza la solicitud.
Utilizar cabeceras de referencia es mucho más fácil que utilizar tokens porque no requiere la identificación individual del usuario.
Vulnerabilidades potenciales del encabezado de referencia
Al igual que los tokens CSRF, los encabezados de referencia tienen algunas vulnerabilidades importantes.
En primer lugar, las cabeceras de referencia no son obligatorias, y algunos sitios enviarán solicitudes sin ellas. Si el CSRF no tiene la política necesaria para gestionar solicitudes sin encabezado, los atacantes pueden utilizar solicitudes sin encabezado para ejecutar ataques de cambio de estado.
Además, este método ha perdido eficacia con la reciente introducción de la política de referencia. Esta especificación evita la filtración de URL a otros dominios, dando a los usuarios más control sobre la información de la cabecera de referencia. Pueden elegir exponer parte de la información de la cabecera de referencia o desactivarla añadiendo 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 peticiones de esta página. Hacer esto dificulta que las aplicaciones que dependen de las cabeceras de referencia eviten ataques CSRF desde dicha página.
Cómo Protege Kinsta Contra los Ataques CSRF
Además de utilizar la cabecera referrer y los tokens CSRF, existe una tercera opción mucho más sencilla: elegir un servicio de alojamiento seguro como Kinsta para tus sitios y aplicaciones web proporciona una barrera mucho más fuerte y segura entre los atacantes y tus usuarios.
Además de las funciones 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 con Cloudflare de Kinsta proporciona una protección de nivel empresarial con protección basada en IP y cortafuegos.
En concreto, Kinsta cuenta actualmente con unas 60 reglas de cortafuegos personalizadas para ayudar a prevenir ataques maliciosos y hacer frente a vulnerabilidades graves no autenticadas en plugins y temas, incluidas las específicas que buscan vulnerabilidades CSRF.
Resumen
La falsificación de petición en sitios cruzados (CSRF) es un ataque que engaña a usuarios autenticados para que inicien peticiones de cambio de estado de forma no intencionada. Su objetivo es que las aplicaciones que no pueden diferenciar entre solicitudes de cambio de estado válidas y falsificadas.
El CSRF sólo puede tener éxito en aplicaciones que dependen de las cookies de sesión para identificar a los usuarios registrados y que tienen una política de cookies SameSite débil. También necesitan un servidor que acepte peticiones que no contengan parámetros desconocidos, como contraseñas. Los hackers pueden enviar ataques maliciosos utilizando GET o POST.
Aunque el uso de tokens CSRF o la aplicación de la verificación del encabezado de referencia pueden evitar algunos ataques CSRF, ambas medidas tienen vulnerabilidades potenciales que pueden hacer que tus medidas preventivas sean inútiles si no tienes cuidado.
Migrar a una plataforma de alojamiento seguro como Kinsta protege tus sitios web o aplicaciones web de los ataques CSRF. Además, la integración de Kinsta con Cloudflare evita ataques CSRF específicos.
Deja una respuesta