Classificazione XSS riflessa e basata su DOM

I observed that certain attacks could be both DOM-based and Reflected XSS

No. Quello che elevi sono gli stessi payload sia per il DOM basato sia per l'XSS riflesso (entrambi gli attacchi sono spesso sfruttati in modi simili). Ma quello che succede al di sotto di questo è ancora o basato su DOM XSS o XSS riflesso (bene, o XSS memorizzato). Non è mai entrambi.

I nomi dei diversi tipi di XSS non specificano in che modo un utente malintenzionato attaccherà qualcuno, ma come funziona l'attacco. Come hai notato, sia l'XSS basato su DOM che l'XSS riflesso potrebbero essere sfruttati allo stesso modo, ad esempio:

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

Ma con XSS riflesso, avrai uno script sul lato server, che prenderà l'argomento user , quindi lo inserirà nel documento HTML che restituisce all'utente.

D'altro canto, con XSS basato su DOM, il browser prenderà l'argomento user e poi lo inserirà nella pagina web.

Quindi la differenza è come il carico utile finisce per essere eseguito dall'utente, e ciò può accadere in un modo o nell'altro. Ma non può accadere in entrambi i modi contemporaneamente *

_{beh, tecnicamente, potrebbe essere se il server e il browser posizionano il payload nel sito Web, ma non è proprio questo il punto.}

Non sono necessariamente esclusivi. Approfittano delle diverse debolezze. Se si ha la possibilità di eseguire un XSS "tradizionale" tramite un attacco riflesso, probabilmente non sarà necessario tentare un attacco basato su dom perché è possibile iniettare qualsiasi codice che si desidera prima che la pagina venga caricata.

Nei tuoi esempi, non è abbastanza chiaro se stai differenziando la differenza radice.

In un XSS tradizionale invii il payload come parte della richiesta alla pagina. Il server aggiunge il tuo script alla pagina e poi fornisce la risposta alla vittima.

Gli XSS basati su DOM si verificano tutti sul lato client, ad esempio i dati vengono letti da JavaScript direttamente dall'URL, dal titolo, da un campo di input, ecc.

Ad esempio, inizi con una richiesta GET come somesite.com/index.php?someVar=foo

rendiamo someVar uguale a <script>alert(1)</script>

In un XSS riflesso la variabile someVar viene letta dal server e quindi diventa parte della pagina di risposta. Quindi se c'è uno script PHP per index.php come:

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

L'HTML reso sarà:

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

Ora in realtà, se l'autore dell'attacco potrebbe rilasciare uno script per fare ciò che vuole. Fondamentalmente, hanno il pieno controllo e possono eseguire tutti i comandi che vogliono. Ci può essere un impatto basato su quando nel flusso viene eseguito il codice, ma essenzialmente hanno il controllo della pagina visualizzata sulla vittima.

D'altra parte, iniziamo con lo stesso URL:

somesite.com/index.php?someVar=foo rendiamo someVar uguale a alert(1)

In questo caso, il file PHP ha il seguente aspetto:

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>

Ora, ammetto che questo è un modo piuttosto strano di fare le cose, ma dimostra come lo stesso input possa essere usato sia nel contesto basato su dom sia nel contesto riflesso.

Ora è certamente possibile che ci sia uno scenario in cui è necessario utilizzare un attacco basato su XSS riflesso per poi sfruttare un attacco basato su DOM:

Di nuovo, dato somesite.com/index.php?someVar=foo rendiamo someVar uguale 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>

In questo esempio, l'input dannoso viene fornito come parte della richiesta e il valore viene assegnato a una parte dell'HTML. Quindi, quando viene eseguito il codice JavaScript del client, chiama quell'input. L'attacco effettivo avviene sul lato client a causa dell'input di lettura. Questo non può essere considerato XSS basato su dom nel senso più puro.

Per prevenire un attacco XSS riflesso, solitamente eseguirai il filtraggio / disinfezione sul lato server; per un attacco basato su dom è necessario eseguire il filtraggio / disinfezione sul lato client perché il client riceve input direttamente da altrove nel client.

Nota: getURLParameter da David Morales