È pericoloso servire l'input dell'utente senza escape come risposta HTML allo stesso utente? [duplicare]

1

Comprendo il motivo per cui consentire l'inserimento di codice JS arbitrario nella memoria persistente (ad esempio, in una tabella di database che contiene commenti dell'utente) è un'enorme vulnerabilità poiché potrebbe finire per essere servita ad altri utenti.

Ma diciamo che l'input dell'utente senza escape non viene mai utilizzato o memorizzato ovunque a parte venga sostituito nella risposta HTML immediatamente inviata allo stesso utente? Questo apre qualsiasi vulnerabilità?

In altre parole, c'è qualche danno nel rinviare all'utente la risposta HTML che contiene (nel peggiore dei casi) codice JS arbitrario creato dallo stesso utente?

    
posta max 03.11.2016 - 07:22
fonte

1 risposta

2

Non dovresti assolutamente farlo. Perché sbagliare se è così facile fare bene? Dovresti avere dei meccanismi che automaticamente codificano in HTML tutte le variabili di output (che cattureranno la maggior parte ma non tutti i problemi XSS); Se devi considerare i pericoli per ogni uscita, a un certo punto commetterai un errore.

L'XSS in un'area utente può ancora essere sfruttato se esistono anche altre vulnerabilità, utilizzando CSRF o posizionando il payload XSS in un account che l'utente malintenzionato controlla e quindi con la registrazione forzata della vittima in quell'account (tramite Login CSRF, Session Fixation, o varie altre vulnerabilità).

L'XSS riflesso in un'area utente può anche essere sfruttato tramite CSRF, o eventualmente tramite ClickJacking, se il browser consente di trascinare / rilasciare in una cornice. A seconda dell'applicazione, potrebbero esserci anche ulteriori casi d'angolo che consentono uno sfruttamento di questo problema.

    
risposta data 03.11.2016 - 08:15
fonte

Leggi altre domande sui tag