Sicurezza di iframe tra domini

5

Quanto è sfruttabile un sito che ascolta i messaggi del browser da chiunque?

Sto lavorando su un sito in cui ho trovato alcuni problemi di iframe. Il caso è che il sito A ha un iframe del sito B, e il sito A ascolta i "messaggi" di ovunque e quindi può eseguire due diverse azioni quando arriva un messaggio:

  • Imposta document.location="dati del messaggio in arrivo"
  • Crea un modulo e imposta il valore dell'attributo dell'azione su "dati del messaggio in arrivo", aggiungilo al DOM e quindi invia il modulo.

Ciò significa che posso configurare il sito Evil, includere un iframe del sito A e quindi iniziare a inviare messaggi arbitrari, ad esempio "javascript: alert (1)", che in entrambi i casi precedenti eseguirà il javascript nell'iframe contesto. Prima di riferire questo alle persone per cui lavoro, ho bisogno di uno scenario in cui questo sarebbe un grosso problema. Ed è qui che diventa complicato, perché non riesco davvero a trovare uno scenario in cui questo sarebbe un problema significativo. Le idee che ho sono:

  • Posso eseguire javascript nel contesto del sito A, ma non riesco ad ottenere i cookie a causa di SoP.
  • Potrei impostare un ascoltatore chiave sul sito Evil e fare in modo che un iframe del sito riempia lo schermo chiedendo un accesso, in questo modo raccogliendo gli accessi per il sito A. Ciò richiederebbe un po 'di ingegneria sociale per funzionare correttamente.

Ma questo è il meglio che posso inventare, quindi la mia domanda è: ho completamente trascurato qualcosa? Googling in giro non offre altre opzioni.

EDIT:

Ovviamente questo apre il sito A (per chi lavoro) per XSS attraverso il sito B (che è una società semi conosciuta, ma ancora). Un altro punto su cui sto pensando è perché mai qualcuno farebbe QUALCHE COSA? Crea un modulo e invia e rispondi con alcuni dati ricevuti? Non riesco a capire un buon motivo per farlo in questo modo, forse qualcuno di voi brave persone può?

EDIT2:

Sembra che non ci sia modo di aggirare la stessa politica di origine anche se posso eseguire javascript arbitrario nel contesto del sito A attraverso l'iframe che si trova su Site Evil. Quindi non c'è nulla su questa 'vulnerabilità' che lo rende diverso da un utente malintenzionato per fare in modo che un utente faccia clic su un link arbitrario.

    
posta sboutzen 14.07.2016 - 15:32
fonte

2 risposte

2

Non darò il "how-to" (exploit), ma:

  • Puoi recuperare i cookie (come detto nei commenti, ma solo quelli non-HTTP).
  • Puoi ignorare tutte le protezioni CSRF (come se fossero basate su Referer / Origin intestazioni HTTP).
  • Puoi mostrare un popup che chiede all'utente di accedere (e quindi rubare la password).
  • È possibile scaricare qualsiasi file arbitrario (incluso .exe) e l'utente si fiderà sicuramente di esso poiché proviene da un sito Web attendibile.
  • Puoi uccidere la reputazione dell'azienda includendo un'immagine scioccante o altro.
  • Puoi incorporare un malware / virus nell'URI (fai un semplice exploit con una stringa EICAR base64ed all'interno di un data uri)

Fai come suggerito per risolvere questo problema: accetta solo domini in entrata fidati e convalida i dati prima di inserirli nel modulo e così via (non hai bisogno dell'URI completo nei dati del messaggio, a meno che tu non voglia davvero inviare il modulo a qualsiasi dominio e qualsiasi protocollo).

    
risposta data 07.04.2017 - 15:34
fonte
1

Potresti sicuramente dirottare la sessione ottenendo i cookie, se puoi eseguire il Javascript in quella pagina / frame inviando il messaggio.

Refer: Come inviare il dominio incrociato post richiesta tramite javascript

Il requisito minimo qui è che avrai bisogno di un server che controlli. In modo che tu possa configurare l'intestazione Access-Control-Allow-Origin della risposta generata per la tua richiesta AJAX.

    
risposta data 15.07.2016 - 19:33
fonte

Leggi altre domande sui tag