Was ist ein Sandbox-Iframe?

Ein Iframe mit Sandbox ist ein eingebettetes Browserdokument, dessen sandbox-Attribut zusätzliche Einschränkungen vorgibt. Bei einem leeren sandbox-Wert gilt eine restriktive Grundkonfiguration. Einzelne allow-*-Tokens geben nur die benötigten Funktionen frei. Für eine HTML-Vorschau lautet ein möglichst sicherer, nützlicher Ansatz nicht „Vertraue dem Code“, sondern „Gib der Vorschau eine eigene Grenze, gewähre nur die nötigen Berechtigungen und halte Geheimnisse aus dem Experiment heraus“.

Was ändert sich, wenn ein Iframe eine Sandbox erhält?

Ein gewöhnlicher Iframe erstellt einen verschachtelten Browserkontext. Same-Origin-Richtlinie, Berechtigungsrichtlinie, Inhaltssicherheitsrichtlinie und die eigenen Header der Frame-Site sind weiterhin wichtig, aber dem Frame werden nicht automatisch alle Browserfunktionen entzogen.

Hinzufügen sandbox fordert den Browser auf, eine zusätzliche Reihe von Einschränkungen aufzuerlegen. Die WHATWG-HTML-Standard definiert das Attribut als einen ungeordneten, durch Leerzeichen getrennten Satz von Token. Wenn kein Token vorhanden ist, bleibt die entsprechende Sandbox-Einschränkung bestehen. Durch das Hinzufügen eines Tokens wird eine bestimmte Einschränkung aufgehoben.

Diese Richtung kann leicht falsch verstanden werden:

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

Dies ist die restriktive Form. Es bedeutet nicht „keine Sandbox-Optionen ausgewählt“. Dies bedeutet, dass die Sandbox aktiv ist und keine ihrer optionalen Funktionen wiederhergestellt wurde.

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

Diese Version erlaubt Skripte und Formularverhalten, während andere Einschränkungen bestehen bleiben. Das genaue Sicherheitsergebnis hängt immer noch davon ab, woher der Inhalt kommt und was die umgebende Anwendung offenlegt.

Welche Einschränkungen gelten standardmäßig?

Die vollständige Norm ist ausführlicher als eine einzelne Checkliste. Diese Kategorien erklären aber den Großteil des Vorschauverhaltens.

Die MDN-Iframe-Referenz listet die aktuellen Token auf und erklärt, was jedes einzelne wiederherstellt. Überprüfen Sie diese Referenz, anstatt eine alte Tokenliste in eine langlebige Sicherheitskontrolle zu kopieren.

Welche Funktionen geben die üblichen allow-Tokens wieder frei?

Betrachten Sie jedes Token als Entscheidung über eine Berechtigung, nicht als bloßen Komfortschalter.

Einige Token interagieren. Es ist notwendig, sie einzeln zu überprüfen, aber nicht ausreichend. Der Ursprung des gerahmten Dokuments, ggf srcdoc oder eine Remote-URL, die Inhaltssicherheitsrichtlinie des Hosts und jede Nachrichtenbrücke zwischen Frame und übergeordnetem Frame wirken sich alle auf die Grenze aus.

Das Diagramm beschreibt eine Berechtigungsgrenze. Es wird nicht behauptet, dass ein Tokensatz beliebigen Code unschädlich macht.

Warum ist ein opaker Ursprung wichtig?

Ohne allow-same-originSandbox-Inhalte werden so behandelt, als kämen sie von einem speziellen Ursprung, der die normalen Prüfungen auf denselben Ursprung nicht besteht. Entwickler nennen dies oft einen undurchsichtigen oder einzigartigen Ursprung.

Für eine Inline-Vorschau mit srcdoc ist diese Trennung wertvoll. Die Vorschau kann ein Dokument darstellen, ohne denselben Anwendungsursprung wie die Editorseite zu erhalten. Sie kann nicht einfach auf das DOM des übergeordneten Dokuments oder dessen Same-Origin-Speicher zugreifen, als wäre sie eine weitere Host-Komponente.

Ein opaker Ursprung bedeutet weder „offline“ noch „Netzwerk deaktiviert“. Bei erlaubten Skripten kann Vorschaucode weiterhin Anfragen stellen, die Browserrichtlinien und Ziel zulassen. Er kann CPU und Speicher nutzen, sein eigenes DOM verändern und über bewusst vom Host bereitgestellte Kanäle kommunizieren. Die Grenze schränkt Befugnisse ein, zertifiziert den Code aber nicht.

MDN warnt insbesondere vor Kombinationen allow-scripts und allow-same-origin wenn der eingebettete Inhalt denselben Ursprung hat und sein eigenes Sandbox-Attribut entfernen kann. Die wichtige Lektion ist kontextabhängig: Stellen Sie nicht beide Funktionen wieder her, nur weil ein Beispiel ohne sie fehlschlägt.

Wie konfiguriert die ClockTools-Vorschau ihre Sandbox?

Der live verfügbare HTML-Echtzeiteditor von ClockTools erstellt die Vorschau mit srcdoc. Bei aktiviertem JavaScript lautet der Sandbox-Wert seines Iframes:

allow-scripts allow-forms allow-modals

Die Implementierung verzichtet bewusst darauf allow-same-origin, allow-popups, Top-Navigationsberechtigungen und Download-Berechtigungen. Die Benutzeroberfläche kennzeichnet die Vorschau als Sandbox mit opakem Ursprung, sodass die Entscheidung über den Ursprung sichtbar ist und nicht im Quellcode verborgen bleibt.

Diese Konfiguration unterstützt übliche Lehrbeispiele: Skripte können die Vorschau aktualisieren, Formulare die Browservalidierung und das Absenden demonstrieren, und modale Dialoge können ausgeführt werden. Unbekannter Code wird dadurch nicht vertrauenswürdig. Deshalb fordert der Editor dazu auf, keine Geheimnisse einzugeben und unbekannte Skripte zu prüfen.

Die Seite erfasst außerdem Konsolenmeldungen und bietet einen Bereich zur Dokumentenprüfung. Diese Funktionen machen das Verhalten nachvollziehbar, sind aber keine Sandbox-Berechtigungen. Die Konsole hilft, Fehler zu erklären, verhindert jedoch keine Anfrage. Eine Strukturprüfung kann eine fehlende Beschriftung melden, ersetzt aber keine vollständige Sicherheitsprüfung.

Was zeigte eine Berechtigungsprüfung?

Ich habe das gerenderte Vorschauelement im Live-Arbeitsbereich ClockTools überprüft, anstatt mich nur auf Marketingtext zu verlassen.

Der Iframe-Titel lautete „Live HTML preview“. Damit erhält das eingebettete Dokument auch für assistive Technologien eine Beschriftung seines Zwecks.

Diese Inspektion bestätigt die konfigurierte Grenze zu diesem Zeitpunkt. Es beweist nicht, dass jedes mögliche Skript sicher ist, und es ersetzt nicht eine Überprüfung der Nachrichtenbrücke, der Handhabung externer Ressourcen, der Inhaltssicherheitsrichtlinie oder zukünftiger Codeänderungen.

Welche Token-Kombinationen verdienen besondere Vorsicht?

Verwenden Sie eine bedrohungsbasierte Überprüfung anstelle eines universellen Token-Rezepts.

allow-scripts plus allow-same-origin

Diese Kombination kann die Isolation stark schwächen, wenn das eingebettete Dokument denselben Ursprung hat und seine Einbettungsbedingungen beeinflussen kann. Werden beide Funktionen benötigt, stellen Sie nicht vertrauenswürdige Inhalte unter einem bewusst getrennten Ursprung bereit. Prüfen Sie die Möglichkeiten zum Verlassen der Sandbox, statt das Attribut als einzige Grenze zu behandeln.

Formulare plus Netzwerkzugriff

allow-forms gibt das Absenden wieder frei. Skripte und gewöhnliche HTML-Elemente können aber auch auf anderen Wegen Anfragen senden. Geben Sie niemals Zugangsdaten, private Kundendaten oder Bearer-Tokens in eine nicht vertrauenswürdige Vorschau ein und nehmen Sie nicht an, die Sandbox halte sie zurück.

Popups und Verlassen der Sandbox

allow-popups Lässt einen Frame einen neuen Browserkontext öffnen. allow-popups-to-escape-sandbox Lässt den neuen Kontext geerbte Sandbox-Flags vermeiden. Das kann bei einer bewusst isolierten Anzeige oder einem externen Link sinnvoll sein, erweitert aber die Bewertungsoberfläche.

Navigation auf oberster Ebene

Berechtigungen zur Navigation auf oberster Ebene erlauben dem Iframe unter bestimmten Bedingungen, die Hostseite zu ersetzen. Eine Code-Experimentierumgebung benötigt das selten. Gehört Navigation zur Übung, erwägen Sie, das Ziel abzufangen und anzuzeigen, statt der Vorschau Kontrolle über die übergeordnete Seite zu geben.

Was kann eine Sandbox nicht schützen?

Eine Sandbox ist ein Browsermechanismus und keine vollständige Plattform für feindlichen Code.

• Es hindert einen Benutzer nicht daran, denselben Inhalt direkt außerhalb des Frames zu öffnen.
• Es ist keine Garantie dafür, dass zulässige Skripte schnell, höflich oder frei von Endlosschleifen sind.
• Es blockiert nicht automatisch jede Netzwerkanfrage.
• Es bereinigt weder HTML noch beweist es, dass eine URL sicher ist.
• Bereits in der Vorschau platzierte Geheimnisse werden nicht gesichert.
• Es ersetzt nicht die serverseitige Validierung für echte Formulare.
• Zugänglichkeit, Semantik oder browserübergreifendes Verhalten werden nicht überprüft.
• Es schützt keinen anderen Dienst, der eine Anfrage aus der Vorschau akzeptiert.

Die Grenze ändert sich auch im Laufe der Zeit, da sich Browser und Standards weiterentwickeln. Das Funktionsverhalten sollte in den Browsern getestet werden, die die Zielgruppe tatsächlich verwendet, und die Token-Liste sollte anhand der aktuellen Spezifikationen überprüft werden.

Wie sollte man eine Browsercode-Vorschau gestalten?

Beginnen Sie mit dem Leeren sandbox Attribut hinzufügen und dann jeweils eine Funktion hinzufügen. Erstellen Sie für jede Ergänzung einen kleinen Akzeptanztest und einen entsprechenden Missbrauchstest.

Halten Sie das Nachrichtenprotokoll des übergeordneten Frames eng. Überprüfen Sie den Absender, die Nachrichtenform und die zulässigen Befehle. Akzeptieren Sie keinen willkürlichen Code oder Navigationsanweisungen über eine allgemeine „Ausführen“-Nachricht, es sei denn, es handelt sich dabei um das explizit isolierte Produkt, das Sie erstellen möchten.

Bieten Sie einen Modus ohne JavaScript für statische Prüfungen an. Ergänzen Sie Stoppen, Zurücksetzen oder Neuladen für außer Kontrolle geratene Beispiele. Zeigen Sie Konsolenfehler an, ohne sensible Daten des übergeordneten Dokuments in den Iframe zu übertragen. Behandeln Sie externe Stylesheets und Skripte als Netzwerkabhängigkeiten, deren Hosts und künftige Inhalte außerhalb der Kontrolle des Editors liegen.

Für ein gezieltes Experiment stellt der Echtzeit-HTML-Editor responsive Breiten, Konsolenerfassung, Prüfungen und den Status seiner Sandbox mit opakem Ursprung bereit. Überführen Sie den Code für Veröffentlichungsarbeiten mit Paketen, Servern, Zugangsdaten, Tests oder Deployment in ein lokales Repository und nutzen Sie einen umfassenderen Entwicklungs- und Sicherheitsprüfungsprozess.