Penso che non sia così, perché l'XSS che non viene salvato da nessuna parte danneggerebbe SOLO l'attaccante.
Ho ragione o ci sono dei casi in cui l'XSS potrebbe danneggiare l'applicazione non-db? (Voglio dire che i dati non vengono salvati ovunque)
Molto sbagliato, la forma base di XSS è XSS riflessa, in cui il carico utile viene inviato nell'URL (ad esempio) dalla vittima stessa.
Questo è più comunemente usato negli attacchi di phishing, in cui l'attaccante crea il link dannoso e lo spedisce per posta elettronica in attacchi di ingegneria sociale alle sue vittime, o lo pubblica su forum pubblici, ecc.
In generale, XSS non ha nulla a che fare con il database (a meno che non sia Persistent / Stored XSS).
Vedi XSS su OWASP per maggiori dettagli.
Ci sono molti modi in cui XSS può sfruttare e fare molti danni senza dover essere immagazzinato in un database. Ricorda che l'XSS può anche essere memorizzato in cookie !
Tuttavia, se parli solo di XSS non persistente, è ancora molto pericoloso, ma più dal punto di vista dell'ingegneria sociale. Questo perché devi distribuire effettivamente il payload XSS invece di diffonderlo da solo. I mezzi di distribuzione del carico utile possono essere ad esempio:
Un buon esempio dei pericoli dell'XSS con o senza un database allegato può essere visto dal Progetto BEEF . Questo mostra alcune delle cose che possono essere fatte al browser di un utente una volta che è stato interessato da un problema XSS.
Se guardi i video di YouTube su questa pagina ci sono alcuni buoni esempi di cosa può essere fatto.
Immagino che se XSS è una vulnerabilità, il prossimo passo è guardare l'iniezione di codice. Usiamo SSI per esempio. Se funziona:
<javascript>alert('x');</javascript>
Quindi è possibile che questo funzioni anche:
<!--#exec cmd="ls /" -->
Non importa cosa, dovresti disinfettare il tuo input.
Altro su SSI injection qui .
Leggi altre domande sui tag web-application appsec xss