Come giustificare che un XSS memorizzato che si verifica dopo l'accesso è una vulnerabilità

Il team di sviluppo è sbagliato. L'impatto qui è l'escalation dei privilegi orizzontale e verticale.

L'XSS post-autorizzazione è valido quanto l'XSS pre-autorizzazione. In genere, vuoi la vittima di essere registrata in ogni caso, poiché vuoi sfruttare la loro autenticazione corrente. L'unico fattore attenuante è che l'attaccante richiede un account. A seconda di quanto è facile ottenere, la valutazione di impatto del problema diminuirà, ma rimane comunque una vulnerabilità [*]

Un utente malintenzionato può utilizzare XSS per eseguire azioni arbitrarie nel nome di qualsiasi utente che visita la pagina contenente il carico utile e leggere tutti i dati a cui gli utenti hanno accesso.

_{[*] Nota che per alcuni utenti questo può essere un rischio accettato. Alcune applicazioni consentirebbero ad esempio agli amministratori di pubblicare HTML non filtrato, poiché hanno già accesso illimitato senza XSS.}

_{Se il carico utile verrà visualizzato solo all'utente che lo inserisce autonomamente, sarebbe un problema diverso. Puoi sfruttarlo solo facendo in modo che l'utente inserisca i dati (ad es. Tramite clickjacking o CSRF) o ingannando l'utente per accedere all'account che ha posizionato il payload (ad esempio tramite la sessione di fissazione o login CSRF).}

Crea uno script che blocca le app e fallo girare per tutti gli utenti che hanno effettuato l'accesso.

Se vuoi fare attacchi più avanzati, inserisci uno script che chiami un'API per modificare le informazioni sul profilo di un utente o altri dati (perché lo script avrà accesso ai cookie in modo che possa effettuare qualsiasi chiamata su quel dominio che si basa sui cookie per l'autenticazione). Può anche recuperare informazioni sul profilo dell'utente e visualizzarle sullo schermo (per dimostrare che l'autore dell'attacco può accedere a tutti questi dati).

Un passo ulteriore sarebbe quello di mostrare un'interfaccia utente che richiede nome utente e password (con alcuni messaggi come "la tua sessione è scaduta, inserisci nome utente e password per continuare"), e non consente all'utente di continuare a utilizzare il app fino a quando non ha verificato che la password sia corretta (ad es. contro qualche auth endpoint). Non devi memorizzarlo da nessuna parte, stai semplicemente indicando che a questo punto, lo sceneggiatore può inviare la password al proprio server.

Quanto di ciò che dovrai costruire dipende da quanto devi convincere. Puoi anche far sapere loro che sei gentile nel dire loro che stai facendo questo, un utente malintenzionato non ha bisogno di dirlo.

Se l'app è aperta a qualsiasi utente (ad esempio chiunque può registrarsi) e attui l'attacco, registra semplicemente un nuovo utente con un nome criptico e dimostralo.

Se gli utenti che hanno effettuato l'accesso sono solo dipendenti interni, dipende dalla fiducia tra i dipendenti. La minaccia interna è una preoccupazione molto legittima.

L'unica buona difesa è una difesa in profondità. Al momento, il loro schema di autenticazione può sembrare sicuro. Ma un giorno verrà rilevata una vulnerabilità, da parte di un utente malintenzionato o da parte di te o da un membro interno scontento che è già stato autenticato.

Se stavano eseguendo un'adeguata difesa in profondità, quando quell'agente nemico otteneva l'accesso al sistema, il danno che potevano fare sarebbe stato limitato da ulteriori meccanismi di sicurezza. Tuttavia, con la loro attitudine secondo cui una vulnerabilità conta solo se può essere eseguita da una minaccia esterna, stanno eliminando completamente ogni possibilità di creare linee di difesa aggiuntive.

Quindi, ad esempio, un utente malintenzionato in grado di ottenere solo un accesso utente limitato potrebbe ottenere le credenziali di amministratore. Il loro schema di autorizzazione è vulnerabile. Oppure un dipendente sottopagato potrebbe decidere di eseguire un minatore di criptovaluta basato su JS sui clienti di tutti i tuoi utenti per guadagnare un po 'di denaro extra sul lato. Oppure un utente esterno alla finanza / gestione potrebbe accedere alle informazioni interne per un po 'di insider trading.

Dire che XSS non ha importanza perché devi essere loggato è funzionalmente equivalente a dire che tutti gli utenti che hanno effettuato l'accesso dovrebbero avere il permesso di vedere e fare tutto ciò che fanno tutti gli altri utenti registrati. Nessun utente vs amministratore, nessuna privacy dipartimentale, nessun utente non ripudio. Tutti gli utenti, funzionalmente indistinguibili. Se ciò non è vero per il loro caso d'uso, allora XSS è una vulnerabilità sfruttabile di cui dovrebbero preoccuparsi.

Modifica: se sono convinti che nulla di quanto sopra potrebbe accadere, ti consiglio di passare agli attacchi di social engineering sullo schema di autenticazione. Gli schemi di autenticazione più sicuri richiedono ancora l'interazione umana e quindi sono deprimenti vulnerabili.