Se sei veramente sicuro che il codice iniettato possa essere eseguito solo dalla stessa persona che l'ha iniettato, allora potrebbe effettivamente essere classificato come "auto-XSS", come menzionato in un commento a la tua domanda. Apparentemente per sfruttare l'attacco di un hacker che deve fare affidamento sull'ingegneria sociale, cercando di ingannare gli altri utenti per iniettare il codice da sé ed eseguirlo.
MODIFICATO PER AGGIUNGERE LO SCENARIO CSRF
La risposta di Anders suggerisce uno scenario CSRF ma non sono d'accordo con questo (e non ho abbastanza reputazione per commentare ancora lì). Tuttavia mi sono appena reso conto che una vulnerabilità di CSRF può effettivamente aiutare l'aggressore a sfruttare il tuo XSS. Anders ha suggerito di utilizzare CSRF per accedere come utente malintenzionato e reindirizzare alla pagina precedentemente infetta. In questo modo ti troverai nell'esecuzione di js arbitrari, ma sei loggato come attaccante ed esegui js nella pagina privata dell'attaccante. Ciò sembra inutile per me. L'opzione apparentemente giusta sarebbe quella di utilizzare CSRF per iniettare il codice dannoso direttamente nella pagina della vittima. Funzionerebbe in questo modo:
- la vittima è attualmente loggata sul tuo sito web
- la vittima visita un sito Web dannoso che utilizza CSRF per iniettare l'XSS nella propria pagina privata (ad esempio una richiesta POST a un modulo che modifica le impostazioni del proprio profilo e inserisce js nel campo vulnerabile)
- la vittima visita la propria pagina privata e ... ora vi è iniettato js
Questo ovviamente richiede che il modulo sul tuo sito Web utilizzato per iniettare js sia vulnerabile a CSRF (ad esempio perché il modulo non richiede un token segreto nascosto), quindi un utente malintenzionato può costringere la vittima a fare una richiesta al tuo sito Web con gravi conseguenze senza il consenso della vittima, ad esempio cambiando impostazioni, password o in questo caso specifico iniettando js. Leggi su CSRF se devi capirne di più.