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?

¿Qué es el CSRF?

Definición

CSRF: el Cross Site Request Forgery (CSRF o XSRF) es un tipo de ataque que se suele usar para estafas por Internet. Los delincuentes se apoderan de una sesión autorizada por el usuario (session riding) para realizar actos dañinos. El proceso se lleva a cabo mediante solicitudes HTTP.

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.

Ejemplos de ataques de cross site request forgery

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.

Nota

El ejemplo de la cuenta bancaria es especialmente impactante porque ilustra a la perfección la gravedad que pueden presentar las consecuencias del CSRF. Aunque en la práctica, los portales de los bancos y, sobre todo, los mecanismos para realizar transferencias están protegidos con varias medidas para defenderse de estos ataques.

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.
Hecho

Los ataques de CSRF siempre tienen como finalidad realizar determinadas acciones en nombre de otro. Con el CSRF nunca se trata simplemente de consultar o copiar información, ya que el atacante no llega a tener acceso a la información de la cuenta del usuario. Incluso si un portal ofreciese una función de descarga de información sensible (por ejemplo, extractos de cuenta), el atacante podría provocar la descarga, pero no podría acceder a los datos descargados. Estos datos acabarían en el dispositivo del usuario.

Medidas de seguridad: ¿cómo se pueden evitar los ataques CSFR?

Navegar con atención y precaución

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.

Revisar el terminal en busca de malware

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.

Protección frente a CSRF por parte del operario de la página web

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.

Autenticación de doble factor

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.

Encabezado de referencia

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.

Cerrar sesión al finalizar el uso

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.


Porque la unión hace la fuerza. En IONOS
#estamoscontigo
y por eso que queremos ayudarte a seguir impulsando
tu negocio. Diseña la tienda de tus sueños con:

eCommerce
Gratis durante los primeros 3 meses.