Da tali categorizzazioni :

Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call.

(em mine il mio)

Quindi per essere client XSS, deve coinvolgere aggiornare il DOM.

Sebbene, l'articolo continua a dire:

DOM Based XSS is simply a subset of Client XSS

Credo che questo si riferisca alla fonte effettiva proveniente dal DOM piuttosto che dal server.

per es.

foo.innerHTML = document.location.hash;

Invece di

foo.innerHTML = ajaxResult;

Questo perché la definizione di XSS basato su DOM è la seguente:

DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser.

Quindi l'XSS basato su client che non è basato su DOM è dove i dati stessi provengono dal server (riflesso nella risposta dalla richiesta HTTP), ma il codice viene visualizzato sulla pagina tramite JavaScript.

Esempio:

Richiesta:

http://example.com?name=<svg onload=alert(1) />

(Il nome sarebbe% codificato, ma l'ho lasciato non codificato qui per chiarezza.)

Risposta:

<script>
var name = "<svg onload=alert(1) />";
$('#output').html(name);
</script>

<div id="output">
</div>

asporto

Ciò che è probabilmente importante quando si tratta di XSS è il seguente:

• Qualsiasi tipo di XSS memorizzato è per lo più a rischio maggiore rispetto a qualsiasi forma di XSS riflesso. I filtri XSS del browser non possono fermarli (eccetto se è in atto una politica di sicurezza dei contenuti ed è sufficientemente bloccata).
• Quando un XSS aggiorna il DOM in un attacco XSS riflesso, ignora anche i filtri XSS del browser (stessi avvertimenti riguardo al CSP).
• Il server riflette che XSS è meno rischioso in quanto richiede l'interazione dell'utente e c'è anche una buona probabilità che un filtro XSS del browser lo blocchi.