Como la vulnerabilidad no se envía al servidor (usando #payload
), ¿puedo decir que un DOM XSS es una vulnerabilidad en el navegador en lugar de la aplicación web?
Dado que la aplicación proporciona la lógica que resulta en un comportamiento inesperado, el XSS basado en DOM es claramente un problema de la aplicación.
Las protecciones XSS basadas en DOM están integradas en muchos navegadores modernos, pero no debe confiar en ellas, ya que protegen contra un subconjunto más pequeño de ataques.
Editado para aclarar que no se debe confiar en las características del navegador para Protecciones XSS.
Entonces, ¿cuál es la aplicación? Existen marcos como Backebone.js que implementan todo el MVC de la aplicación en JavaScript en el cliente. El componente del lado del servidor de esta muy pequeña, y solo una capa de acceso a datos.
Entonces, para responder a su pregunta, el XSS basado en DOM afecta el componente del lado del cliente de una aplicación web.
Document Object Model es un ataque XSS en el que la carga útil del ataque se ejecuta como resultado de la modificación del entorno DOM. El código javascript se ejecuta en el lado del cliente, por lo que puedo decir que es una vulnerabilidad del lado de la aplicación.
Ejemplo de vulnerabilidad basada en DOM - enlace (document.cookie)
Consulte OWASP para obtener más información sobre las vulnerabilidades basadas en DOM XSS
Es una vulnerabilidad de la aplicación. Algunos navegadores intentan evitarlo bastante, pero el problema no es el navegador, sino la parte del cliente de la aplicación.
Modificar el DOM desde JavaScript es una técnica común y útil, incluso (o especialmente) utilizando una estructura de documento construida dinámicamente. Debido a esto, un navegador que no sabe nada sobre la lógica de la aplicación prevista solo puede detener los ataques más obvios, y aunque es bueno que intenten hacerlo, la principal responsabilidad es con la aplicación, no con el navegador.
Lea otras preguntas en las etiquetas xss