Perché gli iframe sono considerati pericolosi e un rischio per la sicurezza?

125

Perché gli iframe sono considerati pericolosi e un rischio per la sicurezza? Qualcuno può descrivere un esempio di un caso in cui può essere utilizzato in modo dannoso?

html  security  iframe 
— Daniel T.
fonte
5
Sembra una vecchia storia di mogli. La finestra del browser è fondamentalmente solo un grande iframe.
— Bill Criswell
1
È già stato chiesto su
— stackoverflow
1
@Samich - No, si tratta di best practice, non specificamente di problemi di sicurezza (e l'unico problema di sicurezza a cui riesco a pensare deriva da terze parti che utilizzano iframe)
— Quentin
Non tanta sicurezza in quanto non è considerata una best practice, vedere: stackoverflow.com/questions/1081315/why-developers-hate-iframes Erano molto più popolari quando le persone progettavano anche con tabelle, i div tutto tranne che eliminano la necessità di iframe.
— RandomUs1r
Stranamente un articolo è apparso quasi un decennio dopo che suggerisce che inserire qualsiasi cosa che contenga un modulo in un iframe, isolato da tutti i tuoi javascript di terze parti, ecc., È forse necessario per proteggere i moduli dalla raccolta. hackernoon.com/…
— GordonM

Risposte:

84

Non appena visualizzi contenuti da un altro dominio, in pratica ti fidi di quel dominio per non diffondere malware.

Non c'è niente di sbagliato negli iframe di per sé. Se controlli il contenuto dell'iframe, sono perfettamente al sicuro.

— Diodeus - James MacFarlane
fonte
19
Non appena ti colleghi a contenuti di un altro dominio, ecc. Ecc ... Non c'è niente di specifico iframe in questo.
— Quentin
5
Un browser correttamente implementato (noto anche come agente utente) non consentirà ai contenuti dell'iframe di fuoriuscire al di fuori dell'iframe. Se il documento host (quello contenente l' <iframe>elemento) ha uno stile appropriato e suggerisce che l'iframe contiene contenuti non attendibili, non ci sono problemi. Modulo di vulnerabilità reali nel browser, ovviamente. In breve, un <iframe>è sicuro quanto un <a href>.
— Mikko Rantalainen
2
Che ne dici di un iframe nascosto che appartiene allo stesso dominio? È totalmente sicuro?
— Ciaran Gallagher
2
Nascosto <iframe>dallo stesso dominio può causare rischi per la sicurezza se il contenuto all'interno dell'iframe nascosto può essere modificato dall'autore dell'attacco. Ciò consentirà all'attaccante di estendere l'attacco XSS all'interno del nascosto <iframe>a qualsiasi pagina del tuo sito che fa riferimento a detto <iframe>contenuto. Vedi stackoverflow.com/a/9428051/334451 per i dettagli.
— Mikko Rantalainen
È interessante notare che un iFrame potrebbe effettivamente essere un'utile protezione dal caso inverso. Se hai molti script di terze parti sul tuo sito, devi isolare i moduli da essi. Un modo suggerito per farlo era inserire il modulo nella sua pagina minimale senza javascript di terze parti e visualizzarlo in un iframe nella pagina host. hackernoon.com/…
— GordonM
140

L' IFRAMEelemento può rappresentare un rischio per la sicurezza se il tuo sito è incorporato in un IFRAMEsito ostile . Google "clickjacking" per maggiori dettagli. Si noti che non importa se si utilizza <iframe>o meno. L'unica vera protezione da questo attacco è aggiungere l'intestazione HTTP X-Frame-Options: DENYe sperare che il browser conosca il suo lavoro.

Inoltre, l' elemento IFRAME può rappresentare un rischio per la sicurezza se una qualsiasi pagina del tuo sito contiene una vulnerabilità XSS che può essere sfruttata . In tal caso, l'attaccante può espandere l'attacco XSS a qualsiasi pagina all'interno dello stesso dominio che può essere persuaso a caricare all'interno di una <iframe>pagina con vulnerabilità XSS. Questo perché il contenuto dalla stessa origine (stesso dominio) è autorizzato ad accedere al contenuto genitore DOM (praticamente esegue JavaScript nel documento "host"). L'unico vero metodo di protezione da questo attacco è aggiungere l'intestazione HTTP X-Frame-Options: DENYe / o codificare sempre correttamente tutti i dati inviati dagli utenti (cioè, non avere mai una vulnerabilità XSS sul tuo sito - più facile a dirsi che a farsi).

Questo è il lato tecnico del problema. Inoltre, c'è il problema dell'interfaccia utente. Se insegni ai tuoi utenti a fare affidamento sul fatto che la barra degli URL non dovrebbe cambiare quando fanno clic sui collegamenti (ad es. Il tuo sito utilizza un grande iframe con tutto il contenuto effettivo), gli utenti non noteranno nulla in futuro neanche in caso di effettiva sicurezza vulnerabilità. Ad esempio, potresti avere una vulnerabilità XSS all'interno del tuo sito che consente all'autore dell'attacco di caricare contenuti da una fonte ostile all'interno del tuo iframe. Nessuno è stato in grado di distinguere perché la barra degli URL sembra ancora identica al comportamento precedente (non cambia mai) e il contenuto "sembra" valido anche se proviene da un dominio ostile che richiede le credenziali dell'utente.

Se qualcuno afferma che l'utilizzo di un <iframe>elemento sul tuo sito è pericoloso e causa un rischio per la sicurezza, non capisce quale <iframe>elemento lo fa o sta parlando della possibilità di <iframe>vulnerabilità correlate nei browser. La sicurezza del <iframe src="...">tag è uguale <img src="..."o <a href="...">fintanto che non ci sono vulnerabilità nel browser. E se c'è una vulnerabilità adeguata, potrebbe essere possibile attivarla anche senza utilizzare <iframe>, <img>o <a>element, quindi non vale la pena considerare questo problema.

Tuttavia, tieni presente che il contenuto di <iframe>può avviare la navigazione di primo livello per impostazione predefinita . Cioè, il contenuto all'interno di <iframe>può aprire automaticamente un collegamento sulla posizione della pagina corrente (la nuova posizione sarà visibile nella barra degli indirizzi). L'unico modo per evitarlo è aggiungere un sandboxattributo senza valore allow-top-navigation. Ad esempio <iframe sandbox="allow-forms allow-scripts" ...>,. Sfortunatamente, sandbox disabilita anche tutti i plugin, sempre. Ad esempio, i contenuti di Youtube non possono essere sottoposti a sandbox perché Flash Player è ancora necessario per visualizzare tutti i contenuti di Youtube. Nessun browser supporta l'utilizzo di plug-in e la disabilitazione della navigazione di primo livello allo stesso tempo.

Tieni presente che X-Frame-Options: DENYprotegge anche dall'attacco del canale laterale delle prestazioni di rendering in grado di leggere il contenuto tra le origini (noto anche come " Pixel Perfect Timing Attacks ").

— Mikko Rantalainen
fonte
Bello, ma non dovrebbe "This is because content from the same origin (same domain) is allowed to access the parent content DOM (practically execute JavaScript in the "host" document)."essere riformulato nella direzione del documento (genitore) contenente una vulnerabilità XSS al documento (figlio) nell'iframe?
— Shuzheng,
@Shuzheng la vulnerabilità va in entrambi i modi e, se la utilizzi <iframe>su una pagina, consente di estendere la vulnerabilità dal contenuto all'interno dell'iframe al documento host. La domanda riguardava l' <iframe>essere pericolosi e se il documento host ha una vulnerabilità XSS, non hai davvero bisogno <iframe>dell'elemento.
— Mikko Rantalainen
13

Suppongo che iFrame cross-domain poiché presumibilmente il rischio sarebbe inferiore se lo controllassi da solo.

  • Il clickjacking è un problema se il tuo sito è incluso come iframe
  • Un iFrame compromesso potrebbe visualizzare contenuti dannosi (immagina che l'iFrame mostri una casella di accesso invece di un annuncio)
  • Un iframe incluso può effettuare determinate chiamate JS come alert e prompt che potrebbero infastidire il tuo utente
  • Un iframe incluso può reindirizzare tramite location.href (yikes, immagina un frame 3p che reindirizza il cliente da bankofamerica.com a bankofamerica.fake.com)
  • Il malware all'interno del frame 3p (java / flash / activeX) potrebbe infettare l'utente
— Joe Zack
fonte
2

"Pericoloso" e "Rischio per la sicurezza" non sono le prime cose che vengono in mente quando le persone menzionano iframe ... ma possono essere usati negli attacchi di clickjacking .

— Quentin
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.