XSS en el DOM

En perfil.js el script lee un valor del fragmento de la URL —la parte que va despues del #— y lo escribe en la pagina con innerHTML. El fragmento no llega al servidor: lo maneja solo el navegador. Por eso este XSS no aparece en los registros del servidor y no se cierra codificando la salida en el servidor: el dato nunca pasa por alli. El auditor lo busca en el codigo del cliente, en el punto donde el script escribe en el documento algo que vino de la URL.

Abre el script y sigue el dato: de donde lo toma y donde lo escribe.

La clave de un XSS en el DOM es el sink: la funcion del navegador que convierte texto en marcado vivo. Escribir en innerHTML un dato que viene de la URL hace que el navegador trate ese texto como parte del documento y ejecute lo que contenga. El auditor reconoce el fallo por ese par —origen no confiable, como la URL, que termina en un sink que interpreta marcado, como innerHTML—, no por probar nada en el navegador.

Hay sinks seguros y sinks peligrosos: el mismo dato en uno es texto y en otro es codigo.

El arreglo vive donde vive el fallo: en el cliente. En vez de escribir el dato con innerHTML, se usa una via que lo trate como texto —asignar textContent—, de modo que el navegador lo muestre sin interpretarlo como marcado. Si de verdad hace falta construir elementos, se crean con las funciones del DOM y se insertan como nodos, nunca pegando una cadena con datos del usuario. El auditor recomienda el sink seguro, no filtrar la URL.

El principio es el mismo de toda la ruta: el dato que viene de fuera es texto hasta que algo decide lo contrario, y ese algo no debe ser el usuario.

El XSS en el DOM tiene su propia nota de triaje en Boletia, con el archivo, el sink, la clasificacion CWE-79 y el arreglo del lado del cliente. Abrela en el laboratorio, confirma que describe el innerHTML de perfil.js y lee el codigo del hallazgo con el que cierra.