Clasificación de XSS reflejados y basados en DOM

  

Observé que ciertos ataques podrían ser basados tanto en DOM como en Reflected XSS

No. Lo que enumera son las mismas cargas útiles tanto para XSS reflejados como basados en DOM (ambos ataques son a menudo explotados de manera similar). Pero lo que sucede debajo de eso sigue siendo XSS basado en DOM o XSS reflejado (bueno, o XSS almacenado). Nunca es a la vez.

Los nombres de los diferentes tipos de XSS no especifican cómo un atacante atacará a alguien, sino cómo funciona el ataque. Como ha señalado, tanto el XSS basado en DOM como el XSS reflejado podrían explotarse de la misma manera, por ejemplo:

http://example.com/index.php?user=<script>alert(123)</script>

Pero con el XSS reflejado, tendrá una secuencia de comandos del lado del servidor, que tomará el argumento user y luego lo colocará en el documento HTML que devuelve al usuario.

Por otro lado, con XSS basado en DOM, el navegador tomará el argumento user y luego lo colocará en la página web.

Entonces, la diferencia es cómo la carga útil termina siendo ejecutada por el lado del usuario, y eso puede suceder de una forma u otra. Pero no puede suceder en ambos sentidos al mismo tiempo *

_{Bueno, técnicamente, podría hacerlo si el servidor y el navegador colocan la carga útil en el sitio web, pero ese no es realmente el punto.}

No son necesariamente exclusivos. Aprovechan las diferentes debilidades. Si tiene la capacidad de realizar un XSS "tradicional" a través de un ataque reflejado, es probable que no tenga que intentar un ataque basado en dom porque puede inyectar el código que desee antes de que se cargue la página.

En sus ejemplos, no está del todo claro si está diferenciando la diferencia de raíz.

En un XSS tradicional, está enviando la carga útil como parte de la solicitud a la página. El servidor agrega su script a la página y luego responde a la víctima.

XSS basado en DOM ocurre todo en el lado del cliente, por ejemplo, los datos son leídos por JavaScript directamente desde la URL, el título, un campo de entrada, etc.

Por ejemplo, comienzas con una solicitud GET como somesite.com/index.php?someVar=foo

hacemos someVar igual a <script>alert(1)</script>

En un XSS reflejado, el servidor lee la variable someVar y luego se convierte en parte de la página de respuesta. Entonces, si hay un script PHP para index.php como:

echo "<h1>Welcome</h1>";
echo $_GET['someVar'];

El HTML renderizado será:

<h1>Welcome</h1>
<script>alert(1)</script>

Ahora, en realidad, si el atacante pudiera colocar una secuencia de comandos para hacer lo que quiera. Básicamente, tienen control total y pueden ejecutar cualquier comando que deseen. Puede haber un impacto en función del momento en el que se ejecuta el código, pero esencialmente tienen el control de la página que se le entrega a la víctima.

Por otro lado, comencemos con la misma URL:

somesite.com/index.php?someVar=foo hacemos someVar igual a alert(1)

En este caso, el archivo PHP se ve así:

echo "<h1>Welcome to URL Check</h1>";
echo "<script id="someVar"></script>" 
?>

<script>
document.getElementById("someVar").innerHTML = getURLParameter('someVar');

function getURLParameter(name) {
  return decodeURIComponent((new RegExp('[?|&]' + name + '=' + '([^&;]+?)(&|#|;|$)').exec(location.search)||[,""])[1].replace(/\+/g, '%20'))||null
}
</script>
</body>

Ahora, admitiré que esta es una forma bastante extraña de hacer las cosas, pero demuestra cómo se podría usar la misma entrada tanto en el contexto basado en dom como en el contexto reflejado.

Ahora es posible que exista un escenario en el que necesite utilizar un ataque basado en XSS reflejado para aprovechar un ataque basado en DOM:

Nuevamente, dado somesite.com/index.php?someVar=foo hacemos someVar igual a alert(1)

<?php
echo '<h1>Welcome</h1>';
$someVar = $_GET['someVar'];
echo '<span id="watch1">' . $someVar . '</span>';
echo '<script id="watch2"></script>';
?>

<script>
  document.getElementById("watch2").innerHTML = document.getElementById("watch1").innerHTML
</script>

En este ejemplo, la entrada maliciosa viene como parte de la solicitud y el valor se asigna a alguna parte del HTML. Luego, cuando se ejecuta el JavaScript del lado del cliente, llama a esa entrada. El ataque real ocurre en el lado del cliente debido a la lectura de entrada. Esto puede no ser considerado XSS basado en dom en el sentido más puro.

Para evitar un ataque XSS reflejado, normalmente hará su filtrado / saneamiento en el lado del servidor; para un ataque basado en dom, debe hacer su filtrado / desinfección en el lado del cliente porque el cliente recibe información directamente de otra parte del cliente.

Nota: getURLParameter from David Morales