Utilizzo degli iframe nel codice non sicuro della sandbox

18

Sto cercando di creare una piattaforma estensibile, in cui il mio sito fornirà un modello e alcune viste (sia lato client, nel browser) che siti di terze parti potrebbero aggiungere anche le proprie visualizzazioni. L'obiettivo qui è che solo il mio modello farà richieste HTTP al mio server, e le visualizzazioni di terze parti faranno solo chiamate API alla mia piattaforma, niente di più (potrebbero anche "chiamare casa" se lo desiderano, ma non devono toccare tutto ciò che non è esplicitamente esposto a loro attraverso l'API).

La soluzione proposta consiste nel creare un iframe invisibile per ogni estensione di terze parti, utilizzando solo postMessage per comunicare con loro ( Modifica : per essere una "vista" corretta deve essere visibile, ovviamente, ma in alternativa può semplicemente avere il ruolo di "controller", delegando il rendering di componenti visivi alla pagina principale potrebbe essere usato se aggiungesse vantaggi di sicurezza, ma idealmente no). Sarebbe questo correttamente "sandbox" il codice? Presumo che:

  • Non saranno in grado di accedere al DOM della pagina principale, né effettuare chiamate JavaScript arbitrarie su di esso, né effettuare richieste Ajax sul mio dominio, a causa della politica della stessa origine;
  • Potrebbero fare richieste GET sul mio server (incluso il caricamento di script da esso), ma finché uso i token CSRF dove è importante, dovrei andare bene. Questa situazione non è diversa dall'avere due schede aperte nello stesso browser, una delle quali autenticata con il rispettivo sito;
  • Non saranno in grado di fare clic sull'utente, poiché se i loro iframe sono invisibili; Suppongo anche che non possano renderli visibili o ridimensionarli, poiché ciò comporterebbe l'accesso al DOM della pagina padre, è corretto?
  • Loro possono spam Window.alert (o peggio: Window.prompt ), console.log o accedere ad altri elementi "globali". Questo è il problema peggiore che ho identificato finora, e ancora incapace di pensare a modi per evitarlo.
    • Chiarire: il problema qui è la possibilità di provare a impersonare il sito principale, visualizzando ad esempio un messaggio che richiede la password.
    • Inoltre, correggimi se sbaglio - sto assumendo che JavaScript negli iframe abbia accesso uguale a quelle risorse, e che la pagina padre non possa negarlo.
  • Loro possono incorporare flash o altri plug-in che potrebbero presentare vulnerabilità di sicurezza. Il fatto che sia in un iframe, tuttavia, non lo rende peggiore sotto nessun punto di vista, o sbaglio?

Queste supposizioni sono corrette, c'è qualcos'altro di cui dovrei essere a conoscenza? Sarà necessario un certo livello di fiducia da parte degli utenti (l'idea è che ogni utente dovrebbe essere in grado di scegliere le estensioni a suo piacimento, indipendentemente dal fatto che il mio sito le approvi o meno, mentre alla fine porta le conseguenze delle sue scelte), ma Mi piacerebbe fare tutto il possibile per mitigare tali rischi.

Aggiornamento: vorrei chiarire un po 'la domanda, in base alle domande poste dai commentatori. Ci sono molti motivi per includere script di terze parti in una pagina: pubblicità, analisi, interazione con i social network, ecc. Questo è un problema di sicurezza, in realtà è uno dei motivi per cui le persone usano AdBlock o NoScript (quindi puoi scegliere selettivamente quali domini sono autorizzati a eseguire codice nel tuo browser). Di solito il sito si fida delle terze parti di cui include gli script, ma non sempre (le applicazioni di Facebook, ad esempio, possono essere fatte da chiunque - ma corrono all'interno di una pagina di Facebook), e ho visto iframes usati per "isolare" terze parti contenuto della festa.

Sebbene un'opzione per la comunicazione tra siti nel browser abbia due schede aperte (o finestre) che usano postMessage per scambiare messaggi, una singola pagina offre un'esperienza più fluida. Le implicazioni complete dell'utilizzo degli iframe (visibili o invisibili) e della sua fattibilità nei contenuti non sicuri della sandbox sono la mia principale preoccupazione in questa domanda e IMHO è applicabile anche a un pubblico più ampio (vedi paragrafo sopra).

Nel mio caso particolare, sto cercando di evitare che i contenuti incorporati impersonino il sito principale (vedi chiarimenti nel quarto punto in alto) e per proteggere gli utenti in generale da altri fastidi il più lontano possibile. Mentre ogni utente avrà la possibilità di scegliere le proprie estensioni, essendo in definitiva responsabile delle conseguenze, vorrei attenuare eventuali problemi noti che sono alla mia portata (e cercare di educare gli utenti a quelli che non lo sono).

    
posta mgibsonbr 19.05.2012 - 02:57
fonte

2 risposte

10

Hai detto che caricerai il contenuto di terze parti in un iframe, ma i contenuti di terze parti saranno ospitati dallo stesso dominio del tuo contenuto principale o verranno pubblicati da un dominio separato?

Se il contenuto di terze parti è ospitato nello stesso dominio della pagina principale, allora no, il tuo approccio è totalmente insicuro . Il contenuto in un iframe ha accesso completo agli script alla pagina principale, se viene servito dalla stessa origine (grosso modo, lo stesso dominio). Leggi la politica sulla stessa origine.

Un approccio più ragionevole è quello di ospitare il contenuto dell'estensione di terze parti su un dominio diverso rispetto alla tua pagina principale. Se lo fai, allora sì, il tuo approccio offre una sicurezza ragionevole . Il contenuto dell'estensione sarà sandbox e non sarà in grado di fare confusione con la pagina principale (per la maggior parte). Ci sono alcuni rischi rimanenti, indicati di seguito:

  • Il contenuto di terze parti nell'iframe può navigare nella pagina principale (ad es. impostando window.location o top.location ). Pertanto, i contenuti di terze parti sostituiscono l'intera pagina con il contenuto scelto dalla terza parte. Ciò potrebbe consentire attacchi di phishing o spoofing. Un utente di avviso potrebbe notare tali attacchi, poiché l'URL nella barra degli indirizzi del browser cambierà, ma alcuni utenti potrebbero non accorgersene.

  • L'estensione di terze parti può ancora caricare contenuti non soddisfacenti nel proprio iframe (ad es., porno, annunci, ecc.).

  • L'estensione di terze parti può ancora provare a montare attacchi di download drive-by sui tuoi utenti. Se i tuoi utenti hanno un browser vulnerabile, potrebbero essere infettati dall'attacco (ovviamente questo può essere vero se visitano un sito malevolo, non c'è nulla riguardo iframes che aumenta il rischio - semplicemente non lo fa andare via , sia).

  • I contenuti di terze parti possono riprodurre film o suoni, possibilmente fastidiosi.

  • L'estensione di terze parti potrebbe essere in grado di montare attacchi click-jacking sulla pagina principale. (Si dice che l'iframe sarà invisibile, ma non sono sicuro di quali siano i metodi specifici necessari per garantire che questa sia una difesa robusta contro il click-jacking. Ci sono un sacco di stranezze del browser là fuori.)

  • È importante che il tuo sito utilizzi forti difese CSRF. In caso contrario, il contenuto di terze parti sarà in una posizione perfetta per montare attacchi CSRF.

Molti di questi rischi sono relativamente minori e potrebbero essere accettabili nella maggior parte dei casi, ma volevo delinearli per te e per gli altri.

Un approccio alternativo consiste nell'utilizzare un sistema per sandboxing Javascript (questi possono anche essere pensati come un modo costruire un "iframe virtuale"). Vedi, ad esempio, Caja , SES , ADsafe , FBJS e Sandbox Web di Microsoft.

Potresti anche consultare ifram in sandbox , ma non penso che siano supportato su tutti i browser, quindi non puoi fare affidamento su questo meccanismo per sicurezza ancora (purtroppo).

Vedi anche Di quali rischi dovrei essere a conoscenza prima di consentire la pubblicazione di annunci sul mio sito web? , Problemi di sicurezza che utilizzano iframe , Come eseguire la scansione di Javascript per il codice dannoso? .

Inoltre, per i dettagli sulle stranezze del browser relative alla politica della stessa origine e a quel tipo di argomento, consiglio vivamente Manuale sulla sicurezza del browser .

    
risposta data 21.05.2012 - 01:28
fonte
2

Se visiti questa demo vedrai che il codice si rileva in una cornice (può essere modificato per rilevare cosa pagina attiva) che cambia l'URL. Un URL che può impersonare il sito principale. (sidenote noto che google e yahoo sono venuti in bianco e credo che i loro header mandino "X-Frame-Options: SAMEORIGIN")

Non so molto sul controllo di Windows, quindi potrebbe essere possibile per un'altra finestra chiudere il tuo sito e avviare un'altra finestra per impersonarlo. Ma da un punto di vista DOM e javascript dovrebbe essere sicuro che il loro codice venga eseguito senza causare danni ai tuoi utenti. Tuttavia, ingannare gli utenti è un'altra storia.

    
risposta data 20.05.2012 - 10:30
fonte

Leggi altre domande sui tag