Il punto 1. è più un problema di auto-XSS (basato su DOM). E come hai detto, i punti 2 e 3. sono veramente gli stessi (l'attacco avviene visitando un URL).
Una richiesta GET tramite un collegamento è il modo più comune per eseguire un attacco XSS. Il link potrebbe ad esempio essere inviato a una vittima via email o pubblicato in un forum.
Ma ci sono altri modi. La caratteristica che definisce XSS riflesso è che l'input è riflesso , il che significa che il server prende una sorta di valore da una richiesta HTTP, la inserisce in un contesto HTML nella risposta e il browser restituisce quella risposta , quindi eseguendo il codice inserito.
XSS riflesso basato su POST
L'XSS riflesso può anche essere eseguito tramite richieste POST (che non sono protette da CSRF). Ad esempio:
<form action="https://example.com/vulnerable" method="POST">
<input type="hidden" name="number" value="[XSS payload]" />
</form>
<script>document.forms[0].submit();</script>
Allo stesso modo, una richiesta GET potrebbe essere inviata tramite un modulo (cambiando il method in GET ). Un utente malintenzionato potrebbe scegliere questo approccio se è richiesta una richiesta POST o se ritiene che sia più probabile che un utente visiti una pagina in cui può pubblicare script e meno probabilmente che farà clic su un collegamento al sito della vittima.
Sfruttamento di Self-XSS
Il tuo punto 1. potrebbe essere sfruttabile se il sito è framingabile. Alcuni browser, ad es. L'ultima volta che ho controllato Firefox, consentono il trascinamento del testo negli iframe (ma non su di essi).
Eseguendo un attacco di clickjacking, un utente malintenzionato potrebbe convincere una vittima a "immettere" il payload XSS ed eseguirlo.
Un altro modo per eseguire un self-XSS è semplicemente chiedere all'utente di pubblicare il payload ("puoi pubblicare questo lungo post HTML [contenente un payload XSS] sul tuo sito web?", "Puoi caricare questo immagine innocua [il cui nome file contiene un carico utile XSS] sul tuo blog? ", ecc.)
Token di sessione con (non) protezione
do session tokens protect us from these approaches?
Se i token di sessione sono sempre inclusi nell'URL e la pagina non riflette alcun input quando il token di sessione è mancante (e il token di sessione è generato in modo sicuro), allora quello sarebbe davvero proteggersi da XSS (non autoreferenziali) che trasmettono a una vittima un collegamento malevolo. Allo stesso modo, i token CSRF proteggono le richieste da XSS (non auto) riflesse.
Tuttavia, ora hai un nuovo problema. I dati sensibili negli URL sono strongmente scoraggiati. Può facilmente fuoriuscire tramite i referer, quando gli utenti condividono link, ecc. E una volta che ciò accade, chiunque potrebbe avere accesso a tale account utente.