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).