È possibile sfruttare una vulnerabilità XSS su una pagina per eseguire codice su un'altra pagina?

Question

È possibile sfruttare una vulnerabilità XSS su una pagina per eseguire codice su un'altra pagina?

#1 da (5 voti)
#2 da (0 voti)

3

Diciamo che la pagina A è vulnerabile a XSS, ma non contiene nulla di interessante per un utente malintenzionato. Pagina Un link alla pagina B che non è vulnerabile a XSS, ma contiene un target di alto valore per un utente malintenzionato (come un modulo di accesso per rubare le password da). Sia la pagina A che la pagina B si trovano sullo stesso dominio.

È possibile sfruttare la vulnerabilità XSS sulla pagina A per eseguire codice a pagina B quando la vittima lo visita, quindi puoi rubare la password della vittima quando viene inserita nel modulo di accesso?

Sospetto che giocare con frame o iframe possa far parte della soluzione qui, quindi una domanda di follow up naturale è se è possibile rilevare la vulnerabilità XSS alla pagina A con l'aiuto della politica di sicurezza del contenuto o qualcosa di simile?

web-application xss content-security-policy

posta Anders 09.05.2016 - 22:31

fonte

2 risposte

0

1. Cambia il link

Come suggerito da AadvarkSoup nei commenti, un utente malintenzionato può modificare l'attributo href del collegamento sulla pagina A, quindi, anziché la pagina B, passa a http://evil-pishin-site.com/login . La maggior parte degli utenti probabilmente non noterebbe il cambio di dominio, in quanto non si aspetta che cambi.

2. Simula la pagina B

Come suggerisce Xavier59 nella sua risposta - quando l'utente fa clic sul collegamento alla pagina B, modifica l'aspetto della pagina A in modo che corrisponda all'apperance della pagina B, ma in realtà non segui il link alla pagina B.

3. Usa un iframe

Rimuovi tutto il contenuto dalla pagina A, e invece lo riempi con un iframe con la pagina A in esso. Poiché le pagine A e B appartengono alla stessa origine, l'utente malintenzionato potrà accedere alla pagina B nell'iframe (dopo che l'utente ha fatto clic sul collegamento lì) dalla pagina modificata A contenente l'iframe.

L'impostazione dell'intestazione content-security-policy: frame-ancestors 'none' sulla pagina B interromperà questo approccio, ma ti impedirà anche di caricarlo in un iframe per motivi legittimi se vorresti farlo.

Conclusione

Poiché solo n. 3 può essere protetto, sembra che non ci sia un buon modo per contenere una vulnerabilità XSS alla pagina vulnerabile.

risposta data 11.05.2016 - 11:17

fonte

Leggi altre domande sui tag web-application xss content-security-policy

SSL negoziare un protocollo troppo basso? DES Decrittografia seguita da Crittografia, produrrà il testo originale?

score 5 · Accepted Answer

L'autore dell'attacco potrebbe aggiungere un attributo evento onclick sul diverso link della pagina. Quando l'utente fa clic su un link, penserà che ha un semplice bug di disconnessione, invece di quello, l'evento onclick ha caricato una pagina di connessione falsa. Ma sei ancora nel dominio e puoi persino manipolare l'url con history.pushState(); come esempio.