Cross-site scripting y OAuth... ¿problemas?
El Cross-site scripting, XSS (no conozco una buena traducción del término, ¿programación cruzada entre sitios?) es uno de los fallos de seguridad más habituales en la web. En Over 1 Million websites are at risk of sensitive information leakage - XSS is dead. Long live XSS nos recuerdan cómo a lo largo del tiempo se han proporcionado soluciones para evitar el problema, es bien conocido y eso significa que muchos sitios están protegidos.
Throughout the years, many protection layers have been placed to detect XSS and prevent its exploitation. From an attacker’s perspective, these protections pose a real challenge. While XSS is still alive and kicking, it has become astronomically more difficult to exploit it successfully than before, which explains why we gradually see fewer instances of it in the wild.
Sin embargo, aparecen nuevas formas de ataque y eso nos impide poder estar tranquilos. En este caso se trata de una combinación entre el XSS y el sistema de autorización OAuth.
However, similar to many other cases in the cybersecurity ecosystem - sometimes new, seemingly unrelated developments can lead to the reincarnation of old and, at times, forgotten vulnerabilities. In this blog post, we demonstrate why this is exactly the case of XSS when smartly combined with a new emerging technology - OAuth.
El problema del XSS se basa en la inserción de código en JavaScript en el navegador del usuario. Este JavaScript tiene acceso a lo que hay disponible para ese navegador y se pueden conseguir ataques que roban credenciales, sesiones, ….
If you write HTML/JS code instead of the input, the browser will think that the code was generated by the backend and parse it as legitimate HTML/JS.
Hay algunas técnicas para mitigar el problema como pueden ser: limpiar las entradas y codificar las salidas (Manual Input Sanitization and Output Encoding), utilizar entornos de programación modernos, que nos ayudan a manejar estos problemas (Using Modern Web Frameworks), parámetros como HTTP-Only, que evitan que los programitas peligrosos accedan a las cookies (HTTP-Only) y las políticas de seguridad de contenidos (CSP) que permiten especificar de dónde se pueden cargar determinados elementos peligrosos.
Después de esta introducción nos explican cómo encontraron un problema en hotjar, que es una herramienta de analítica web. Descargan sus programas en JavaScript (porque tienen que estar disponibles para enviarlos al navegador), los analizan hasta encontrar algún problema, y enconctaron algún problema. Sin embargo, el sitio estaba bien protegido contra estas cosas (con HTTP-Only) así que no era posible atacar directamente.
Y aquí entra en juego OAuth, gracias que hotjar utiliza login social mediante Google:
One of the features in Hotjar—and almost any other modern website today—is social login, which is based on OAuth (the open standard for authorization).
Esto significa que si pinchamos en la identificación con Google, el sitio confiará en lo que nos mande (si le hemos autorizado en el pasado) y por allí habrá códigos de autorización que estarán visibles para los programas en JavaScript.
In other words - the secret code, at the end of the OAuth flow, will be located in the URL - and that’s something that the javascript code can read.
Por lo tanto, si enviamos una petición adecuadamente preparada en el proceso de autorización, cuando nos vuelva tendremos acceso a esos códigos.
With this method, the javascript code opens a new tab to Google, and Google automatically redirects the user back to https://insights.hotjar.com with the OAuth code in the URL:
A veces los fallos son muy sencillos, y otras veces muy complejos. Aquí estamos en un camino intermedio donde la comodidad de los usuarios (y de los gestores del sitio) junto con la obligada confianza (necesaria para que todo funcione) nos juegan una mala pasada.
En este momento el problema estaría resuelto en este proveedor, pero es fácil que haya muchos sitios donde todavía no sean ni siquiera conscientes del problema.