CSRF: ex­pli­ca­ció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á au­me­n­ta­n­do la po­pu­la­ri­dad del cross site request forgery entre los ci­be­r­de­li­n­cue­n­tes. Con este método, los hackers pueden, por ejemplo, realizar tra­n­s­fe­re­n­cias mediante banca ele­c­tró­ni­ca. ¿Pero cómo funciona exac­ta­me­n­te este método de ataque? ¿Y cómo podemos pro­te­ge­r­nos?

Ima­gi­ne­mos que un usuario ha iniciado sesión en una pla­ta­fo­r­ma 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 in­tro­du­cir su co­n­tra­se­ña. Y esta ci­r­cu­n­s­ta­n­cia es la que aprovecha el ci­be­r­de­li­n­cue­n­te. Por norma general, los usuarios con sesión iniciada pueden realizar más acciones y acciones más im­po­r­ta­n­tes que los usuarios no ide­n­ti­fi­ca­dos.

El fu­n­cio­na­mie­n­to 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 cua­l­quie­ra, por ejemplo, el ac­cio­na­mie­n­to de un botón. A co­n­ti­nua­ció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 co­rre­c­ta­me­n­te y a través de las cookies co­rre­s­po­n­die­n­tes, también detecta que el usuario (o su navegador) pe­r­ma­ne­cen 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 so­li­ci­tu­des sin evaluar las co­n­se­cue­n­cias.

Las tres variantes del CSRF que se perpetúan con mayor fre­cue­n­cia son las si­guie­n­tes: la más empleada consiste en colar una URL. Dicha URL se esconde en una página web externa o en un correo ele­c­tró­ni­co. El acceso a esta URL des­en­ca­de­na 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 in­ge­nie­ría social y la técnica de spoofing.

También hay puntos para realizar el de­no­mi­na­do 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 cri­mi­na­les sin que el operador tenga co­n­s­ta­n­cia. Por norma general, en este ataque se introduce Ja­va­S­cri­pt en la página web y este se encarga de realizar el ataque CSRF.

Si lo atacantes consiguen in­tro­du­cir 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 di­re­c­ta­me­n­te 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 ele­c­tró­ni­ca, ya que este caso es es­pe­cia­l­me­n­te adecuado para ver el alcance de la técnica del ataque. Un usuario inicia sesión en su cuenta de banca ele­c­tró­ni­ca. La página cuenta con un fo­r­mu­la­rio es­pe­cí­fi­co para realizar tra­n­s­fe­re­n­cias. Si el usuario rellena el fo­r­mu­la­rio y acciona el botón de co­n­fi­r­ma­ción, se envía una solicitud HTTP es­pe­cí­fi­ca al servidor y se realiza la tra­n­s­fe­re­n­cia. El atacante conoce la es­tru­c­tu­ra exacta del fo­r­mu­la­rio y la solicitud HTTP y es capaz de recrear ambos. Como in­fo­r­ma­ción se in­tro­du­cen los datos de la cuenta del estafador y un importe de­te­r­mi­na­do por este.

Entonces, el hacker puede es­ta­ble­cer una página web (o enviar un correo ele­c­tró­ni­co) de interés para el usuario de ejemplo. Se le pide al usuario que haga clic en un enlace apa­re­n­te­me­n­te ino­fe­n­si­vo, pero esta acción es la que activa la solicitud HTTP frau­du­le­n­ta. 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 co­n­se­cue­n­cia, el dinero se tra­n­s­fie­re. El usuario no se da cuenta de nada hasta que comprueba su saldo.

Otros es­ce­na­rios de ataques:

• Redes sociales: se publican co­me­n­ta­rios o “Me gusta” en nombre del usuario con la sesión iniciada.
• Ad­mi­ni­s­tra­ció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 pre­cau­ción, ante todo. Si no navegas por páginas de fia­bi­li­dad dudosa ni abres correos ele­c­tró­ni­cos so­s­pe­cho­sos es muy co­m­pli­ca­do que te co­n­vie­r­tas en víctima de un ataque de este tipo. Para pro­te­ge­r­te del CSRF también debes cerrar siempre tu sesión en portales re­le­va­n­tes para tu seguridad antes de acceder a cualquier página web cuyo origen es de­s­co­no­ci­do.

Como usuario también debes ase­gu­rar­te de que tu di­s­po­si­ti­vo (ordenador, portátil, sma­r­t­pho­ne, etc.) está libre de software malicioso. Si una apli­ca­ción actúa en segundo plano y te espía como usuario, es muy difícil evitar el CSRF. Una vez que el di­s­po­si­ti­vo o la cuenta estén in­fe­c­ta­dos, 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 es­tru­c­tu­ra exacta de los co­rre­s­po­n­die­n­tes fo­r­mu­la­rios y so­li­ci­tu­des 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 ca­ra­c­te­res) y co­n­ve­r­ti­r­lo 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 au­to­má­ti­ca.

Por norma general, la banca ele­c­tró­ni­ca cuenta con una au­te­n­ti­ca­ción de doble factor; antes de que el usuario pueda efectuar una tra­n­s­fe­re­n­cia debe in­tro­du­cir un código TAN que no se puede facilitar a través de la página web. Esta técnica no solo sirve como pro­te­c­ció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 tra­n­s­fe­re­n­cia mientras no cuente con el segundo factor.

En teoría, el en­ca­be­za­do de re­fe­re­n­cia 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 en­ca­be­za­do de re­fe­re­n­cia ha de­mo­s­tra­do ser muy poco fiable a lo largo de los últimos años. Cualquier am­plia­ción del navegador, como por ejemplo blo­quea­do­res de anuncios, modifican o eliminan el en­ca­be­za­do de re­fe­re­n­cia. En este caso, los usuarios con una co­n­fi­gu­ra­ción de este tipo ya no podrían usar la oferta de la página web.

Una medida que no puede ofrecer pro­te­c­ción de­fi­ni­ti­va, pero que al menos supone un obstáculo para los de­li­n­cue­n­tes es no mantener las sesiones iniciadas de manera ilimitada. En este asunto, los ope­ra­do­res 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.