Ho pensato che clienti come Gmail.com e Outlook.com avrebbero messo le e-mail in un iframe per una maggiore sicurezza, ma si scopre che si sanitizzano pesantemente con qualcosa come Caja.
Ma c'è qualche ragione particolare per cui non userebbero iframe, il che aiuterebbe almeno sandbox un po '?
(Caja, ad esempio, ha rilevato una vulnerabilità solo pochi mesi fa - e ritengo che questa vulnerabilità potrebbe essere stato mitigato inserendo e-mail in un iframe)
TL; DR iframe non può sostituire completamente la sterilizzazione, ma è un'ottima funzionalità da utilizzare come sicurezza in profondità. Sfortunatamente, ciò ostacola alcune caratteristiche di facilità d'uso.
Sarei interessante nel sentire una risposta più informata, ma inserirò alcuni punti di cui sono a conoscenza.
La stessa politica di origine funziona in entrambe le direzioni. È fantastico che mantenga il iframe dal vedere il contenuto del documento esterno. Sfortunatamente, se selezioni il testo, il documento esterno non può dire quale testo è stato selezionato in iframe . ( grazie @ paj28 ) Una volta poteva usare la funzione postMessage aggiungendo script alla pagina interna per aggirare questo problema, ma non è comodo. Inoltre, questo non funzionerà se utilizzi iframe sandbox come metodo per disabilitare script s. (che consiglio vivamente)
Dovrai utilizzare Politica di sicurezza del contenuto (ancora, hanshan @ paj28 ) per disabilitare i beacon nel contenuto di iframe d; e anche per disabilitare script e altri potenziali problemi.
Vorrei sottolineare che iframe come originariamente progettato non è completo. L'attributo sandbox potrebbe essere necessario in caso di dubbi sulla disinfezione. Sfortunatamente, la funzione sandbox era solo implementata di recente . Ciò ha un significato sempre minore man mano che i browser più vecchi iniziano a rilasciare i grafici.
Disattivare gli script potrebbe comunque intralciare le funzionalità di facilità d'uso, come il rilevamento del testo selezionato. (È possibile che tu riesca a farla franca con la regola "disabilita gli script e tratta come la stessa origine" di sandbox, ma sembra rischioso.)
Ogni volta che aggiungi i tuoi script o funzionalità interattiva al documento iframe 'd, sarai molto più sicuro se disinfetti ancora quel documento. Mentre iframe sandbox combinato con CSP può coprirti completamente, potrebbe esserci qualcosa che manca a quella formula.
Quindi in sintesi
Per i browser che non supportano sandbox , iframe attenua i rischi significativi per la sicurezza, ma non è in grado di proteggere da molti problemi. La politica di sicurezza dei contenuti potrebbe essere in grado di isolare il contenuto, in larga misura. Ma devi ancora disinfettare per evitare cose come <a target="_top" .
Per i browser che supportano sandbox , combinato con una buona politica di sicurezza dei contenuti, potresti essere in grado di sostituire l'igienizzazione, ma non è consigliabile perché è difficile sapere con certezza se sei sicuro al 100% . (le routine di sanitizzazione sono invece più vecchie e meglio controllate)
Se hai una sanitizzazione (che probabilmente dovresti), e l'igienizzazione è ben controllata, allora iframe s interferisce con la facilità d'uso. D'altra parte, se viene scoperta una falla nella tua disinfezione, allora sarai contento di iframe d il contenuto, usando l'attributo sandbox e CSP per ridurre l'ambito dell'attacco.
Nota a margine: le applicazioni desktop hanno più libertà nella sandboxing delle loro visualizzazioni Web, persino meglio dell'attributo iframe sandbox. Quindi, ad esempio, le app Android potrebbero trarne vantaggio.
Per poter pubblicare qualsiasi contenuto all'interno di un iFrame, Google dovrebbe disabilitare alcuni degli script di framebreaker esistenti del sito (che Google avrebbe aggiunto come attenuazione contro il clickjacking per i vecchi client Web).
Immagino che Google abbia stabilito che il rischio di disabilitare gli script del framebreak sarebbe maggiore della ricompensa del rendering del contenuto in un iFrame.