XSS riflesso attraverso il valore del cookie?

Question

XSS riflesso attraverso il valore del cookie?

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)

5

Ho sempre considerato l'XSS riflesso come un attacco che avrebbe avuto luogo attraverso un URL. Ad esempio, avresti un URL come sotto:

http://someSite.com?message=welcome!<script>alert(1);</script>

e il messaggio verrebbe scritto nella pagina. Per poter eseguire l'attacco, dovrai indurre qualcuno a fare clic su quel link.

Recentemente stavo guardando un sito web usando BurpSuite e contrassegnato una vulnerabilità di script cross site riflessa e il vettore di attacco era un valore del cookie. Mentre potrei davvero cambiare il valore del cookie per renderlo javascript sulla pagina, non capisco come questo possa essere usato per attaccare un altro utente.

Nel mio primo esempio, un utente dovrebbe fare clic su un collegamento per eseguire l'attacco. Come eseguiresti un attacco con la seconda vulnerabilità?

web-application xss

posta Abe Miessler 16.10.2014 - 19:48

fonte

3 risposte

0

I cookie impostati su HTTP sono presentati su HTTPS.

Se un utente malintenzionato ha il pieno controllo del traffico di rete di una vittima, può impostare un cookie su HTTP e ciò causerà un attacco XSS contro il sito HTTPS. Credo che l'HSTS lo fermerebbe, anche se non mi sono confermato.

risposta data 16.10.2014 - 20:15

fonte

0

Una volta che l'iniezione è presente, non è necessario "fare clic sul collegamento". Nell'esempio fornito, se HTML + JavaScript viene eseguito il rendering, il codice alert () verrà eseguito automaticamente, senza interazione dell'utente.

Funziona in entrambi gli esempi, indipendentemente da dove si trova l'XSS nella sessione HTTP. Tutto ciò che è necessario è che l'XSS sia reindirizzato in un posto adatto all'interno del documento di destinazione.

Una volta sfruttato quel buco, possono accadere molte cose. Ricordare inoltre che XSS potrebbe essere persistente nel DB del sistema remoto. Il browser è sempre vittima di un attacco XSS, ma un database compromesso (contenente XSS persistente) è anche vittima dal punto di vista dell'amministratore di sistema.

risposta data 16.10.2014 - 22:05

fonte

Leggi altre domande sui tag web-application xss

Siamo al sicuro dall'infezione da Bad Rabbit? C'è un strong motivo per salare e cancellare le password quando il riutilizzo della password non è un problema?

score 2 · Accepted Answer

A causa della politica della stessa origine per i cookie , una specie di "pollo" o la situazione dell'uovo viene creata. Affinché l'attaccante possa rendere possibile questo vettore XSS, è necessario un altro difetto per impostare il valore del cookie.

Un possibile percorso di exploit sta utilizzando una vulnerabilità XSS su un sottodominio per sfruttare la seguente proprietà di cookie:

 www.foo.bar.example.com may set a cookie to be sent to *.bar.example.com or *.example.com, but not to *.something.else.example.com or *.com

Un altro percorso di exploit consisterebbe nell'usare la divisione della risposta HTTP su una pagina che sta eseguendo un reindirizzamento. In questa situazione non è possibile utilizzare la divisione della risposta HTTP per controllare il corpo HTTP, che è richiesto per XSS, invece l'utente malintenzionato può iniettare un'intestazione HTTP set-cookie per sfruttare una vulnerabilità XSS basata su cookie su un'altra pagina.

In molti casi questo XSS basato sui cookie non è sfruttabile. Burp avrebbe dovuto contrassegnare questo problema come giallo, che riflette una probabilità di sfruttamento medio / bassa.