Che cos'è un iframe in sandbox?

Un iframe sandbox è un documento del browser incorporato con restrizioni aggiuntive applicate dagli iframe sandbox attributo. Con un vuoto sandbox valore, il browser inizia da una linea di base restrittiva; individuo allow-* i token restituiscono solo le funzionalità necessarie al contenuto incorporato. Per un'anteprima HTML, il design utile più sicuro non è "fidarsi del codice". Si tratta di "dare all'anteprima un confine separato, aggiungere le autorizzazioni minime e mantenere i segreti fuori dall'esperimento".

Cosa cambia quando un iframe è in modalità sandbox?

Un normale iframe crea un contesto di navigazione annidato. La same-origin policy, la Permissions Policy, la Content Security Policy e le intestazioni del sito incorporato restano rilevanti, ma il frame non viene automaticamente privato di tutte le funzionalità del browser.

Aggiunta sandbox chiede al browser di imporre una serie aggiuntiva di restrizioni. Il standard HTML di WHATWG definisce l'attributo come un insieme di token non ordinato e separato da spazi. L'assenza di un token mantiene in vigore la corrispondente restrizione sandbox; l'aggiunta di un token elimina una particolare restrizione.

È facile fraintendere questo meccanismo:

<iframe sandbox srcdoc="<p>Static preview</p>"></iframe>

Questa è la forma restrittiva. Ciò non significa “nessuna opzione sandbox selezionata”. Significa che la sandbox è attiva e nessuna delle sue funzionalità opzionali è stata ripristinata.

<iframe
  sandbox="allow-scripts allow-forms"
  srcdoc="<button type='button'>Run</button>">
</iframe>

Questa versione consente script e comportamenti dei moduli lasciando in atto altre restrizioni. L'esatto risultato in termini di sicurezza dipende ancora dalla provenienza del contenuto e da cosa espone l'applicazione circostante.

Quali restrizioni si applicano per impostazione predefinita?

Lo standard completo contiene più dettagli di un elenco di controllo, ma queste categorie spiegano la maggior parte del comportamento dell'anteprima.

Il riferimento MDN sugli iframe elenca i token correnti e spiega cosa ripristina ciascuno. Controlla quel riferimento invece di copiare un vecchio elenco di token in un controllo di sicurezza di lunga durata.

Cosa ripristinano i token di autorizzazione comuni?

Considera ogni token una decisione sulle funzionalità da autorizzare, non un'opzione da attivare per comodità.

Alcuni token interagiscono. Rivederli uno alla volta è necessario ma non sufficiente. L'origine del documento incorniciato, se lo è srcdoc o un URL remoto, la politica di sicurezza dei contenuti dell'host e qualsiasi ponte di messaggio tra frame e elemento principale influiscono tutti sul confine.

Il diagramma descrive un confine di autorizzazione. Non afferma che un insieme di token possa rendere innocuo qualsiasi codice.

Perché è importante un’origine opaca?

Senza allow-same-origin, i contenuti sandbox vengono considerati come provenienti da un'origine speciale che non supera i normali controlli della stessa origine. Gli sviluppatori spesso la chiamano origine opaca o unica.

Per un in linea srcdoc anteprima, quella separazione è preziosa. L'anteprima può eseguire il rendering di un documento senza essere trattata come la stessa origine dell'applicazione della pagina dell'editor. Non può semplicemente raggiungere il DOM del genitore o leggere la memoria della stessa origine come se fosse un altro componente dell'host.

Origine opaca non significa "offline" o "rete disabilitata". Se gli script sono consentiti, il codice di anteprima potrebbe comunque effettuare richieste di rete consentite dai criteri del browser e dalla destinazione. Può utilizzare CPU e memoria, manipolare il proprio DOM e comunicare attraverso i canali che l'host espone deliberatamente. Il confine riduce l'autorità; non certifica il codice.

MDN mette in guardia in particolare dalla combinazione allow-scripts e allow-same-origin quando il contenuto incorporato ha la stessa origine e può rimuovere il proprio attributo sandbox. La lezione importante è contestuale: non ripristinare entrambe le capacità semplicemente perché un esempio fallisce senza di esse.

Come configura la sandbox l'anteprima di ClockTools?

Lo strumento online editor HTML in tempo reale di ClockTools costruisce l'anteprima con srcdoc. Quando JavaScript è abilitato, il suo valore sandbox iframe è:

allow-scripts allow-forms allow-modals

L'implementazione omette intenzionalmente allow-same-origin, allow-popups, autorizzazioni di navigazione in alto e autorizzazione di download. L'interfaccia etichetta l'anteprima come an sandbox opaca, rendendo visibile la decisione sull'origine anziché nasconderla nel codice sorgente.

Questa configurazione supporta i comuni esempi didattici: gli script possono aggiornare l'anteprima, i moduli possono mostrare la convalida e l'invio gestiti dal browser e gli esempi con finestre modali possono funzionare. Non rende attendibile il codice sconosciuto. Per questo le istruzioni dell'editor invitano a non inserire dati segreti e a esaminare gli script che non si conoscono.

La pagina acquisisce inoltre i messaggi della console ed espone un pannello di controllo dei documenti. Queste sono funzionalità di osservabilità, non autorizzazioni sandbox. Un pannello della console aiuta a spiegare un errore; non impedisce una richiesta. Un controllo strutturale può segnalare un'etichetta mancante; non conduce una revisione completa della sicurezza.

Cosa ha mostrato la verifica delle funzionalità?

Ho esaminato l'elemento di anteprima renderizzato nell'area di lavoro live ClockTools anziché fare affidamento solo sul testo di marketing.

Il titolo dell'iframe era «Anteprima HTML in tempo reale», un'etichetta che indica anche alle tecnologie assistive lo scopo del documento incorporato.

Questa ispezione conferma il confine configurato in quel momento. Non dimostra che ogni possibile script sia sicuro e non sostituisce una revisione del bridge di messaggi, della gestione delle risorse esterne, della politica di sicurezza dei contenuti o di future modifiche al codice.

Quali combinazioni di token meritano maggiore cautela?

Esamina le minacce concrete anziché adottare una combinazione universale di token.

allow-scripts insieme a allow-same-origin

Questa coppia può indebolire seriamente l'isolamento quando il documento incorporato ha la stessa origine e può influenzarne le condizioni di incorporamento. Se sono necessari entrambi, fornire contenuto non attendibile da un'origine deliberatamente separata e analizzare i percorsi di fuga anziché trattare l'attributo come unico confine.

Moduli e accesso alla rete

allow-forms riabilita l'invio, ma gli script e i normali elementi HTML possono inviare richieste anche in altri modi. Non inserire mai credenziali, dati privati dei clienti o bearer token in un'anteprima non attendibile dando per scontato che la sandbox ne impedisca la fuoriuscita.

Popup e uscita dalla sandbox

allow-popups consente a un frame di aprire un nuovo contesto di navigazione. allow-popups-to-escape-sandbox consente al nuovo contesto di evitare i flag sandbox ereditati. Ciò può essere utile per una pubblicità volutamente isolata o un collegamento esterno, ma espande la superficie della recensione.

Navigazione della pagina principale

I permessi di navigazione della pagina principale consentono al frame di sostituire la pagina host in condizioni definite. Un ambiente per sperimentare con il codice ne ha raramente bisogno. Se la navigazione fa parte della lezione, valuta di intercettare e mostrare la destinazione invece di dare all'anteprima il controllo della pagina principale.

Cosa non può proteggere una sandbox?

Una sandbox è un meccanismo del browser, non una piattaforma completa per gestire codice ostile.

• Non impedisce a un utente di aprire lo stesso contenuto direttamente all'esterno del frame.
• Non garantisce che gli script consentiti siano veloci, poco invasivi o privi di cicli infiniti.
• Non blocca automaticamente ogni richiesta di rete.
• Non sanifica l'HTML né dimostra che un URL sia sicuro.
• Non protegge i segreti già inseriti nell'anteprima.
• Non sostituisce la convalida lato server per i moduli reali.
• Non convalida l'accessibilità, la semantica o il comportamento tra browser.
• Non protegge un altro servizio che accetta una richiesta dall'anteprima.

Il confine cambia anche nel tempo man mano che i browser e gli standard si evolvono. Il comportamento delle funzionalità dovrebbe essere testato nei browser effettivamente utilizzati dal pubblico e l'elenco dei token dovrebbe essere rivisto rispetto alle specifiche attuali.

Come progettare un'anteprima di codice nel browser?

Inizia dal vuoto sandbox attributo, quindi aggiungi una funzionalità alla volta. Per ogni aggiunta, crea un piccolo test di accettazione e un corrispondente test di abuso.

Limita il protocollo di messaggistica tra pagina contenitore e frame allo stretto necessario. Convalida il mittente, la struttura dei messaggi e i comandi consentiti. Non accettare codice arbitrario o istruzioni di navigazione tramite un messaggio generico «execute», a meno che questa funzione non faccia parte del prodotto esplicitamente isolato che intendi realizzare.

Offri una modalità con JavaScript disattivato per l'ispezione statica. Aggiungi comandi di arresto, ripristino o ricaricamento per gli esempi fuori controllo. Mostra gli errori della console senza copiare nel frame dati sensibili della pagina contenitore. Considera fogli di stile e script esterni come dipendenze di rete i cui host e contenuti futuri sono al di fuori del controllo dell'editor.

Per un esperimento mirato, lo strumento strumento di editing HTML in tempo reale offre larghezze per verificare il layout responsivo, acquisizione dei messaggi della console, controlli e indicazione dello stato della sandbox opaca. Per un rilascio che coinvolga pacchetti, server, credenziali, test o distribuzione, trasferisci il codice in un repository locale e adotta una procedura più completa di sviluppo e verifica della sicurezza.