Para armamentizar el XSS basado en DOM, necesitamos confiar en dos métodos de delivery convencionales de payloads XSS: namely storage y reflection. Esto es por lo que los XSS basados en DOM y otros ataques basados en DOM son tan difíciles de explotar. Sin un método de delivery adecuado, estás realizando el ataque sobre ti mismo.
Para contrarrestar esto, necesitamos que o el servidor almacene nuestro payload para posterior delivery o hacer delivery del payload mediante reflejo. En este punto se convierte en un XSS stored o reflected.
Como hemos mencionado en la tarea anterior, el XSS reflejado, especialmente ciando la source es la URL, puede resultar complicado de explotar debido a que los navegadores modernos URL encodean. Esto suele dejarnos con stored XSS como mecanismo de delivery. Si realizamos XSS a través de la información guardada del usuario, necesitamos encontrar un sink donde al información se añada sin sanitización.
Guías Generales de Armamentización
Antes de ver un caso de estudio, es recomendable hablar de armamentización general de XSS: A veces, encontrarás que es fácil hacer que alert('XSS') funcione. Sin embargo, esto es normalmente donde termina la diversión y no hemos probado impacto.
El siguiente paso suele ser intentar robar la cookie del usuario. Sin embargo, esto se convierte rápidamente en un problema cuando la seguridad de la cookie está reforzada por la flag HTTPOnly, no dejando que JavaScript recupere la cookie. Necesitamos profundizar más para obtener una vulnerabilidad XSS que consiga explotarlo y mostrar impacto real.
Este artículo habla sobre la armamentización de XSS. Para armamentizar XSS al completo, necesitamos entender el poder que tenemos. En el punto donde podemos ejecutar por completo XSS y cargar un payload staged, podemos controlar el navegador del usuario. Esto significa interferir con la aplicación como haría el usuario. No necesitamos disparar una alerta o robar la cookie. Podemos decirle al navegador que haga peticiones en nombre del usuario. Esto es lo que hace a XSS tan poderoso. Incluso si encuentras XSS en una página donde no hay nada sensible, puedes decirle al navegador que recupere información de otras páginas más sensibles.
Caso de Estudio XSS Basado en DOM
En 2010, fue descubierto que Twitter (ahora X) tenía una vulnerabilidad XSS basada en DOM. En una actualización a su JavaScript, Twitter introdujo la siguiente función:
//<![CDATA[ (function(g){var a=location.href.split("#!")[1];if(a){g.location=g.HBR=a;}})(window); //]]>
La función buscaba #! en la URL y asignaba el concepto al objeto window.location, creando una source y un sink sin sanitización. Como tal, un atacante podía obtener un pop-up simplemente usando el siguiente payload:
http://twitter.com/#!javascript:alert(document.domain);
Como ya hemos mencionado, esto sólo no hace nada, pero fue armamentizado por actores maliciosos. Fue realizado usando la función onmouseover de JavaScript para crear un gusano que:
- Se retweeteaba para contagiar a nuevos usuarios.
- Redirigía a usuarios a otras webs.
- Mostraba pop-ups y otros comportamientos intrusivos.
Cabe recalcar que aunque afectó a miles de usuarios, era 2010. Si el mismo bug fuera encontrado hoy, tendría consecuencias mucho más fatales.