¿La carga útil para XSS basada en DOM está definida para originarse solo dentro del navegador o incluso fuera de él?

Question

¿La carga útil para XSS basada en DOM está definida para originarse solo dentro del navegador o incluso fuera de él?

#1 de tim (2 votos)
#2 de SilverlightFox (1 votos)

1

He leído en varios lugares puntos de vista contradictorios sobre lo que podría considerarse un XSS basado en DOM. Parece que la definición original dice que es una forma de XSS donde la carga útil se origina exclusivamente desde dentro del navegador, pero algunas personas también lo ven como una forma de XSS donde la carga útil no necesariamente se origina desde dentro del navegador, pero se usa para modificar el DOM.

La segunda vista es lo que me confunde. ¿Qué significa exactamente que la carga útil se utiliza para modificar el DOM? La página OWASP que describe DOM XSS , da un ejemplo que, para mí, parece ser el mismo que XSS reflejado.

Dice:

Se puede realizar un ataque XSS basado en DOM contra esta página enviando la siguiente URL a una víctima:   %código%. Cuando la víctima hace clic en este enlace, el navegador envía una solicitud para: http://www.some.site/page.html?default=<script>alert(document.cookie)</script> . El servidor responde con la página que contiene el código Javascript anterior.

El código de JavaScript original simplemente hace eco en la página (DOM) en tiempo de ejecución. El navegador luego muestra la página resultante y ejecuta la secuencia de comandos del atacante: /page.html?default=<script>alert(document.cookie)</script>

Dado que la carga útil va del navegador de la víctima al servidor y regresa al navegador, ¿cómo no se refleja esto en XSS?

¿Debo interpretar esto como Reflected XSS significa poder inyectar alert(document.cookie) tags en un contexto HTML, y DOM basado en DOM significa poder inyectar una carga útil dentro de un <script> ya existente?

xss javascript dom

pregunta user1720897 31.07.2016 - 08:26

fuente

2 respuestas

Lea otras preguntas en las etiquetas xss javascript dom

Llavero vs KeyStore vs TrustStore ¿Es necesario finalizar la sesión después de cerrar el navegador sin cerrar sesión?

score 2 · Answer 1

XSS basado en DOM vs XSS reflejado

¿Debo interpretar esto como Reflected XSS significa poder inyectar <script> tags en un contexto HTML, y DOM basado en DOM significa poder inyectar una carga útil dentro de un <script> ya existente?

No.

XSS reflejado significa que su carga útil inyectada se refleja en la respuesta entregada por el servidor y ejecutada por el navegador (no importa dónde se inserte la carga útil, siempre que sea interpretada por el navegador).

Con XSS basado en DOM , la carga útil puede o no entregarse en la respuesta del servidor, pero no será ejecutada por el navegador tal como está. En su lugar, el código JavaScript entregado por el servidor lo tomará y lo insertará en el DOM, lo que llevará a su ejecución.

DOM basado en XSS y la interacción del servidor

Dado que la carga útil va del navegador de la víctima al servidor y regresa al navegador, ¿cómo no se refleja esto en XSS?

Porque el hecho de que vaya al servidor y regrese no es relevante para el ataque.

Lo que es relevante para el ataque es que el JavaScript entregado por el servidor lee la URL y la inserta en el DOM, ejecutando así el código inyectado.

Si sigues leyendo, OWASP también describe esto:

El servidor responde con la página que contiene el código Javascript anterior. El navegador crea un objeto DOM para la página, en el que el objeto document.location contiene la cadena:
http://www.some.site/page.html?default=<script>alert(document.cookie)</script>
El código de JavaScript original en la página no espera que el parámetro predeterminado contenga el código HTML, y como tal, simplemente lo repite en la página (DOM) en tiempo de ejecución.
  [...]
  En el ejemplo anterior, mientras que la carga útil no estaba integrada por el servidor en la respuesta HTTP, aún llegó al servidor como parte de una solicitud HTTP y, por lo tanto, el ataque podría detectarse en el lado del servidor.

OWASP también establece específicamente que un ataque basado en DOM puede ir al servidor y volver.

score 1 · Answer 2

Dado que la carga útil va desde el navegador de la víctima al servidor y volviendo al navegador, ¿cómo no se refleja XSS en su lugar?

En ese ejemplo, no va al servidor a volver como XSS.

El código vulnerable está en Javascript:

<script>

document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");

document.write("<OPTION value=2>English</OPTION>");

</script>

Aunque en ese ejemplo, sí se envía al servidor:

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>

Pero no tiene que:

http://www.some.site/page.html#default=<script>alert(document.cookie)</script>

... también sería válido para este ataque. La sección "identificador de fragmentos" de la URL ( # ) nunca se envía al servidor, sin embargo, puede ser recogida por Javascript.

En su ejemplo, se envía al servidor, pero no es el servidor el que causa el XSS, es el código del lado del cliente. Esto es lo que define DOM basado en XSS.

Para citar a OWASP:

... la página en sí (la respuesta HTTP que es) no cambia, pero el código del lado del cliente contenido en la página se ejecuta de manera diferente Debido a las modificaciones maliciosas que se han producido en el DOM medio ambiente.