¿Qué es CSRF? ¿Cómo podemos prevenir CSRF?

En la era digital, Internet se ha integrado en el tejido de nuestra vida cotidiana. Hemos trasladado numerosas actividades en línea, desde compras hasta socialización en diversas plataformas y realización de transacciones bancarias. A medida que las interacciones financieras se vuelven más comunes, las ramificaciones de la seguridad en la red han adquirido mayor relevancia. Una de las amenazas cibernéticas más prevalentes en Internet es el CSRF (falsificación de solicitud entre sitios), y es imperativo profundizar en sus matices.

¿Qué es el CSRF?

Los ataques CSRF aprovechan las vulnerabilidades en los mecanismos de validación de solicitudes de un sitio web objetivo. En ciertas situaciones, los usuarios ejecutan involuntariamente solicitudes maliciosas mientras están conectados al sitio web objetivo. Los atacantes suelen emplear direcciones que se asemejan al dominio del sitio web objetivo, atrayendo a los usuarios a hacer clic. Incrustan código malicioso disfrazándolo como cargas de imágenes o formularios ocultos, iniciando solicitudes al sitio web objetivo y ejecutando acciones no autorizadas de manera encubierta. Objetivos como alterar contraseñas de usuarios o iniciar transferencias bancarias no autorizadas pueden resultar en pérdidas significativas para los usuarios.

Ejemplo de la vida real

Imagina un sitio web llamado e-bank.com que ofrece servicios de banca electrónica, con una página llamada /transfer para enviar solicitudes de transferencia. Cuando los usuarios acceden a la página e-bank.com/transfer, se presenta un formulario que muestra los detalles ingresados por el usuario. Al completar y enviar el formulario, se envía una solicitud HTTP POST a la dirección de la página, llevando parámetros como el destinatario y el monto ingresado por el usuario.

En este punto, un atacante puede construir una página maliciosa con un formulario invisible, dirigiendo la dirección de envío a e-bank.com/transfer. El atacante prellena el formulario con los parámetros específicos del destinatario y el monto. Cuando los usuarios son engañados para hacer clic en esta página maliciosa, el navegador ejecuta código JavaScript, enviando el formulario.

Si el usuario no está registrado o no ha iniciado sesión en e-bank.com, la solicitud de transferencia no puede ejecutarse. Sin embargo, si el usuario ha utilizado recientemente el servicio y el estado de inicio de sesión persiste, la solicitud de transferencia puede ejecutarse con éxito.

Esto encapsula los ataques CSRF: simples en principio pero con un potencial de daño inmenso. Afortunadamente, existen numerosos métodos maduros para prevenir tales ataques. Exploremos a continuación.

¿Cómo podemos prevenir el CSRF?

Abordar este problema implica medidas proactivas y pasivas.

Restricción de Método HTTP y Restricción de Referer

Como desarrolladores, podemos imponer restricciones más estrictas en direcciones sensibles dentro del servicio, como:

• Para direcciones que requieren envío de datos, prohibir el uso de solicitudes HTTP GET, obligando el uso de solicitudes POST. Esto añade complejidad para los atacantes que intentan construir páginas maliciosas.

• Además, podemos restringir el campo Referer en el encabezado de la solicitud HTTP (Referer), permitiéndolo solo desde direcciones legítimas conocidas y bloqueando solicitudes maliciosas.

Esta es una medida de protección proactiva sencilla, con un costo menor pero aún con cierta susceptibilidad a ataques.

Token CSRF

El Token CSRF es una solución ampliamente adoptada, combinando mecanismos de sesión del lado del servidor para prevenir ataques CSRF. Específicamente, el programa del servidor incrusta un campo de entrada oculto en las páginas que requieren protección con un Token CSRF generado aleatoriamente en el formulario de salida. Simultáneamente, se crea una sesión en el lado del servidor, almacenando esta cadena aleatoria con un tiempo de expiración.

Cuando un usuario solicita la página, el servidor inicializa la sesión, almacenando datos en el lado del servidor y estableciendo una cookie en el navegador del cliente que contiene el ID de Sesión para asociación. El Token CSRF se almacena en la sesión. Al enviar el formulario, se envía el Token CSRF. El programa del servidor compara este token con la parte almacenada en la sesión. La validación exitosa lleva a la ejecución de la lógica posterior; de lo contrario, se devuelve un error. Simultáneamente, se inserta un nuevo Token CSRF en el formulario para el próximo envío.

Esta es una medida de protección proactiva, que requiere cierto esfuerzo pero proporciona una protección robusta.

Protección de Origen Cruzado

A menudo encontramos una tecnología llamada CORS (Intercambio de Recursos de Origen Cruzado), una especificación que indica si los navegadores permiten solicitudes de origen cruzado. Los navegadores modernos soportan esta especificación. Al iniciar una solicitud Fetch/XHR en una página existente, el navegador envía una solicitud HTTP OPTIONS para verificar previamente si el servicio objetivo permite solicitudes desde la dirección de origen actual. El servidor proporcionará una lista de encabezados de respuesta, especificando los orígenes permitidos, los métodos de solicitud y los encabezados. El navegador sigue estas indicaciones, evitando solicitudes prohibidas en el lado del cliente.

Esta es otra medida de protección proactiva, configurable en el lado del servidor, pero ten en cuenta que, aunque es poco probable que los usuarios normales desactiven esta función, sigue siendo posible en el lado del cliente.

Bloqueo de Cookies de Terceros

Los servicios que desarrollamos a veces almacenan IDs de Sesión de usuarios en Cookies para mantener el estado de inicio de sesión. Las Cookies soportan configuraciones SameSite, evitando que el navegador envíe cookies a sitios de origen cruzado. Intentar ataques CSRF resulta en un estado no autenticado en el sitio objetivo.

Además, debido al mal uso de los mecanismos de Cookies HTTP para el seguimiento de clientes, los desarrolladores de navegadores han decidido restringir y bloquear gradualmente las cookies de terceros (Cuenta Regresiva de Cookies). Cuando una página en el dominio A intenta hacer una llamada al dominio B, incluso si pasa las verificaciones de reglas CORS, el navegador no enviará cookies a ese sitio de origen cruzado.

Resumen

Como puertas de enlace API, tanto Apache APISIX como API7 Enterprise soportan Token CSRF y CORS—dos medidas de protección mencionadas anteriormente—para prevenir ataques CSRF.

En conclusión, prevenir ataques CSRF requiere un enfoque multifacético, incorporando diversas técnicas en el lado del servidor, el navegador, el protocolo HTTP y más para lograr una protección integral.