CSRF: explicación del ataque Cross Site Request Forgery

Muy pocos usuarios saben a qué peligros se exponen cuando navegan por Internet. Al margen del spear phishing también está aumentando la popularidad del cross site request forgery entre los ciberdelincuentes. Con este método, los hackers pueden, por ejemplo, realizar transferencias mediante banca electrónica. ¿Pero cómo funciona exactamente este método de ataque? ¿Y cómo podemos protegernos?

Imaginemos que un usuario ha iniciado sesión en una plataforma online. Tras el inicio de sesión, el usuario permanece en su cuenta mientras dura la sesión (este período de tiempo varía según la página) sin tener que volver a introducir su contraseña. Y esta circunstancia es la que aprovecha el ciberdelincuente. Por norma general, los usuarios con sesión iniciada pueden realizar más acciones y acciones más importantes que los usuarios no identificados.

El funcionamiento del CSRF es el siguiente: mientras el usuario está con la sesión iniciada en el portal, también visita otra página, la cual está creada por el hacker. En esta otra página, el usuario realiza una acción cualquiera, por ejemplo, el accionamiento de un botón. A continuación, el atacante envía una solicitud HTTP al portal empleado por el usuario y realiza una acción dañina en nombre del usuario, ya que la sesión sigue activa. Para conseguir todo esto, el atacante solo necesita conocer la solicitud HTTP correcta y esta solicitud es bastante fácil de leer.

El servidor del portal reconoce que la solicitud HTTP ha sido formulada correctamente y a través de las cookies correspondientes, también detecta que el usuario (o su navegador) permanecen con la sesión iniciada. El servidor ejecuta la acción y es posible que el usuario ni se dé cuenta de que se acaba de llevar a cabo una acción en su nombre.

El ataque CSRF funciona porque el servidor receptor no comprueba de dónde procede la solicitud. Es decir, no queda claro si la solicitud HTTP ha sido creada por la propia página web o si su origen es externo. En este contexto, el atacante se aprovecha de una laguna de seguridad del navegador; transmite las solicitudes sin evaluar las consecuencias.

Las tres variantes del CSRF que se perpetúan con mayor frecuencia son las siguientes: la más empleada consiste en colar una URL. Dicha URL se esconde en una página web externa o en un correo electrónico. El acceso a esta URL desencadena la solicitud HTTP. Por norma general, el usuario sí puede ver esta URL si presta atención. No obstante, el origen de la URL se puede ocultar mediante ingeniería social y la técnica de spoofing.

También hay puntos para realizar el denominado cross site scripting (XSS). En lugar de crear una página web maliciosa propia, algunos hackers manipulan una página ya existente mediante el XSS y la usan para fines criminales sin que el operador tenga constancia. Por norma general, en este ataque se introduce JavaScript en la página web y este se encarga de realizar el ataque CSRF.

Si lo atacantes consiguen introducir software malicioso en el ordenador de la víctima, también es posible realizar un ataque de cross site request forgery. De esta manera, el atacante puede ordenar directamente al navegador que envíe la solicitud HTTP. No obstante, una vez que el ordenador de la víctima está infectado con malware o virus, hay muchas más opciones de ataque.

Nuestro ejemplo de CSRF gira en torno a la banca electrónica, ya que este caso es especialmente adecuado para ver el alcance de la técnica del ataque. Un usuario inicia sesión en su cuenta de banca electrónica. La página cuenta con un formulario específico para realizar transferencias. Si el usuario rellena el formulario y acciona el botón de confirmación, se envía una solicitud HTTP específica al servidor y se realiza la transferencia. El atacante conoce la estructura exacta del formulario y la solicitud HTTP y es capaz de recrear ambos. Como información se introducen los datos de la cuenta del estafador y un importe determinado por este.

Entonces, el hacker puede establecer una página web (o enviar un correo electrónico) de interés para el usuario de ejemplo. Se le pide al usuario que haga clic en un enlace aparentemente inofensivo, pero esta acción es la que activa la solicitud HTTP fraudulenta. Dicha solicitud se envía al banco y este realiza la acción deseada por el hacker. La sesión sigue iniciada y la solicitud es correcta. El servidor no cuenta con ninguna razón para no ejecutar la acción y, en consecuencia, el dinero se transfiere. El usuario no se da cuenta de nada hasta que comprueba su saldo.

Otros escenarios de ataques:

• Redes sociales: se publican comentarios o “Me gusta” en nombre del usuario con la sesión iniciada.
• Administración de páginas web: si una víctima accede al backend, se pueden crear nuevos usuarios o se puede eliminar la página web entera sin que se entere.
• Compras online: el atacante realiza compras a cuenta del usuario sin que este se dé cuenta.

Como usuario, la consigna es precaución, ante todo. Si no navegas por páginas de fiabilidad dudosa ni abres correos electrónicos sospechosos es muy complicado que te conviertas en víctima de un ataque de este tipo. Para protegerte del CSRF también debes cerrar siempre tu sesión en portales relevantes para tu seguridad antes de acceder a cualquier página web cuyo origen es desconocido.

Como usuario también debes asegurarte de que tu dispositivo (ordenador, portátil, smartphone, etc.) está libre de software malicioso. Si una aplicación actúa en segundo plano y te espía como usuario, es muy difícil evitar el CSRF. Una vez que el dispositivo o la cuenta estén infectados, pueden ser víctima de múltiples otros ataques.

Los operarios de la página web también pueden proteger a los usuarios. Los atacantes solo pueden llevar a cabo ataques de cross site request rorgery porque conocen la estructura exacta de los correspondientes formularios y solicitudes HTTP. Si se introduce un factor aleatorio en la ecuación, el hacker suele quedar en fuera de juego. La página web puede crear un token único (similar a una secuencia aleatoria de caracteres) y convertirlo en parte de la solicitud HTTP. Así, si el servidor recibe una solicitud sin token o con un toquen que (ya) no es válido, dicha solicitud se rechaza de forma automática.

Por norma general, la banca electrónica cuenta con una autenticación de doble factor; antes de que el usuario pueda efectuar una transferencia debe introducir un código TAN que no se puede facilitar a través de la página web. Esta técnica no solo sirve como protección frente al CSRF, sino también frente a otros ataques. Incluso si el atacante llega a hacerse con los datos de acceso, no podría realizar la transferencia mientras no cuente con el segundo factor.

En teoría, el encabezado de referencia ya funciona como elemento protector. Esta parte de la solicitud HTTP indica de dónde proviene la solicitud. Así, las páginas web pueden filtrar todos los orígenes externos. No obstante, el encabezado de referencia ha demostrado ser muy poco fiable a lo largo de los últimos años. Cualquier ampliación del navegador, como por ejemplo bloqueadores de anuncios, modifican o eliminan el encabezado de referencia. En este caso, los usuarios con una configuración de este tipo ya no podrían usar la oferta de la página web.

Una medida que no puede ofrecer protección definitiva, pero que al menos supone un obstáculo para los delincuentes es no mantener las sesiones iniciadas de manera ilimitada. En este asunto, los operadores sopesan la comodidad de los usuarios y el riesgo. Los portales de bancos, por ejemplo, suelen cerrar la sesión tras solo unos minutos sin que el usuario realice una acción. En cambio, otras páginas web (como, por ejemplo, la mayoría de las redes sociales), que gestionan datos menos sensibles, pueden dejar las sesiones abiertas durante varios días. En cuanto un usuario no tiene la sesión iniciada en el portal, cualquier ataque de CSRF carece de efecto.