Wat is een iframe in een sandbox?

Een iframe in een sandbox is een ingebed browserdocument waarop extra beperkingen worden toegepast door de iframes zandbak attribuut. Met een leeg zandbak waarde, de browser vertrekt vanuit een beperkende basislijn; individueel toestaan-* tokens retourneren alleen de mogelijkheden die de ingebedde inhoud nodig heeft. Voor een preview van HTML is het veiligste bruikbare ontwerp niet ‘vertrouw op de code’. Het is “geef de preview een aparte grens, voeg de minimale rechten toe en houd geheimen buiten het experiment.”

Wat verandert er als een iframe in de sandbox wordt geplaatst?

Een gewoon iframe creëert een geneste browsecontext. Het beleid van dezelfde oorsprong, het machtigingenbeleid, het inhoudsbeveiligingsbeleid en de headers van de ingelijste site zijn nog steeds van belang, maar het frame wordt niet automatisch ontdaan van alle browsermogelijkheden.

Toevoegen zandbak vraagt de browser om een extra reeks beperkingen op te leggen. De WHATWG HTML Standaard definieert het attribuut als een ongeordende, door spaties gescheiden set tokens. De afwezigheid van een token zorgt ervoor dat de overeenkomstige sandboxbeperking behouden blijft; het toevoegen van een token heft een bepaalde beperking op.

Die richting is gemakkelijk verkeerd te lezen:

```html

<iframe sandbox srcdoc="<p>Statisch voorbeeld</p>"></iframe>

```

Dit is de beperkende vorm. Het betekent niet dat er “geen sandbox-opties geselecteerd zijn.” Dit betekent dat de sandbox actief is en dat geen van de optionele mogelijkheden is hersteld.

```html

<iframe

sandbox="allow-scripts allow-forms"

srcdoc="<button type='button'>Uitvoeren</button>">

</iframe>

```

Deze versie staat scripts en formuliergedrag toe, terwijl andere beperkingen van kracht blijven. Het exacte beveiligingsresultaat hangt nog steeds af van waar de inhoud vandaan komt en wat de omliggende applicatie blootlegt.

Welke beperkingen zijn standaard van toepassing?

De volledige standaard bevat meer details dan één checklist, maar deze categorieën verklaren het meeste voorbeeldgedrag.

De MDN iframe-referentie vermeldt de huidige tokens en legt uit wat ze allemaal herstellen. Controleer die referentie in plaats van een oude tokenlijst te kopiëren naar een langdurige beveiligingscontrole.

Wat laten de algemene tokens toe om te herstellen?

Beschouw elk token als een capaciteitsbeslissing, niet als een gemaksschakelaar.

Sommige tokens werken op elkaar in. Het is noodzakelijk, maar niet voldoende om ze één voor één te beoordelen. De oorsprong van het ingelijste document, of dat nu zo is srcdoc of een externe URL, het Content Security Policy van de host en een eventuele berichtbrug tussen frame en ouder hebben allemaal invloed op de grens.

Het diagram beschrijft een toestemmingsgrens. Er wordt niet beweerd dat welke tokenset dan ook willekeurige code onschadelijk maakt.

Waarom is een ondoorzichtige oorsprong belangrijk?

Zonder laat-dezelfde-oorsprong toe, wordt inhoud in een sandbox behandeld alsof deze afkomstig is van een speciale oorsprong die niet voldoet aan de normale controles van dezelfde oorsprong. Ontwikkelaars noemen dit vaak een ondoorzichtige of unieke oorsprong.

Voor een inline srcdoc preview, die scheiding is waardevol. Het voorbeeld kan een document weergeven zonder te worden behandeld als dezelfde toepassingsoorsprong als de editorpagina. Het kan niet eenvoudigweg de DOM van de ouder bereiken of opslag van dezelfde oorsprong lezen alsof het een ander onderdeel van de host is.

Ondoorzichtige oorsprong betekent niet ‘offline’ of ‘netwerk uitgeschakeld’. Als scripts zijn toegestaan, kan de voorbeeldcode nog steeds netwerkverzoeken doen die het browserbeleid en de bestemming toestaan. Het kan CPU en geheugen gebruiken, zijn eigen DOM manipuleren en communiceren via kanalen die de host opzettelijk blootlegt. De grens vermindert de autoriteit; het certificeert de code niet.

MDN waarschuwt vooral voor combineren allow-scripts en laat-dezelfde-oorsprong toe wanneer de ingesloten inhoud dezelfde oorsprong heeft en zijn eigen sandbox-attribuut kan verwijderen. De belangrijke les is contextueel: herstel niet beide mogelijkheden alleen maar omdat een voorbeeld zonder deze mogelijkheden mislukt.

Hoe configureert de ClockTools preview de sandbox?

De levende ClockTools realtime HTML-editor bouwt de preview met srcdoc. Wanneer JavaScript is ingeschakeld, is de iframe-sandboxwaarde:

allow-scripts allow-formulieren allow-modals

De implementatie laat dit bewust achterwege laat-dezelfde-oorsprong toe, allow-pop-ups, navigatierechten bovenaan en downloadrechten. De interface bestempelt het voorbeeld als een ondoorzichtige zandbak, waardoor de oorsprongsbeslissing zichtbaar wordt in plaats van deze in de broncode te verbergen.

Die configuratie ondersteunt algemene onderwijsvoorbeelden: scripts kunnen de preview bijwerken, formulieren kunnen browservalidatie en indieningsgedrag uitoefenen, en modale voorbeelden kunnen worden uitgevoerd. Het verandert onbekende code niet in vertrouwde code. De eigen richtlijnen van de redacteur vertellen gebruikers daarom dat ze geheimen moeten vermijden en onbekende scripts moeten bekijken.

De pagina legt ook consoleberichten vast en toont een documentcontrolepaneel. Dit zijn observatiefuncties, geen sandbox-machtigingen. Een consolepaneel helpt bij het verklaren van een storing; het staat een verzoek niet in de weg. Een structurele controle kan een ontbrekend label signaleren; het voert geen volledige veiligheidsbeoordeling uit.

Wat bleek uit een capaciteitencheck?

Ik inspecteerde het gerenderde voorbeeldelement in de live ClockTools werkruimte in plaats van alleen op marketingtekst te vertrouwen.

De titel van het iframe was 'Live HTML preview', waardoor ondersteunende technologie ook een doellabel krijgt voor het ingesloten document.

Deze inspectie bevestigt de op dat moment geconfigureerde grens. Het bewijst niet dat elk mogelijk script veilig is, en het vervangt niet een beoordeling van de berichtenbrug, de omgang met externe bronnen, het inhoudsbeveiligingsbeleid of toekomstige codewijzigingen.

Welke tokencombinaties verdienen extra voorzichtigheid?

Gebruik een op bedreigingen gebaseerde beoordeling in plaats van een universeel tokenrecept.

allow-scripts plus laat-dezelfde-oorsprong toe

Dit paar kan de isolatie ernstig verzwakken wanneer het ingesloten document dezelfde oorsprong heeft, en kan de insluitingsomstandigheden beïnvloeden. Als beide nodig zijn, serveer dan niet-vertrouwde inhoud van een opzettelijk gescheiden oorsprong en analyseer de ontsnappingspaden in plaats van het attribuut als de enige grens te behandelen.

Formulieren plus netwerktoegang

toestemmingsformulieren herstelt de indiening, maar scripts en gewone HTML elementen kunnen ook op andere manieren verzoeken verzenden. Plaats nooit inloggegevens, persoonlijke klantgegevens of dragertokens in een niet-vertrouwde preview en ga ervan uit dat de sandbox deze zal bevatten.

Pop-ups plus ontsnappingsgedrag

allow-pop-ups laat een frame een nieuwe browsercontext openen. allow-popups-to-escape-sandbox zorgt ervoor dat de nieuwe context overgenomen sandbox-vlaggen vermijdt. Dat kan handig zijn voor een bewust geïsoleerde advertentie of externe link, maar vergroot wel het reviewoppervlak.

Topnavigatie

Met machtigingen voor topnavigatie kan het frame de hostpagina vervangen onder gedefinieerde voorwaarden. Een codespeeltuin heeft dat zelden nodig. Als navigatie deel uitmaakt van de les, overweeg dan om de bestemming te onderscheppen en weer te geven in plaats van de voorbeeldcontrole over de pagina op het hoogste niveau te geven.

Wat kan een sandbox niet beschermen?

Een sandbox is één browsermechanisme, geen compleet platform met vijandige code.

• Het weerhoudt een gebruiker er niet van om dezelfde inhoud direct buiten het frame te openen.
• Het garandeert niet dat toegestane scripts snel, beleefd of vrij van oneindige lussen zijn.
• Het blokkeert niet automatisch elk netwerkverzoek.
• Het zuivert HTML niet en bewijst niet dat een URL veilig is.
• Het beveiligt geen geheimen die al in het voorbeeld zijn geplaatst.
• Het vervangt server-side validatie voor echte formulieren niet.
• Het valideert de toegankelijkheid, semantiek of cross-browser gedrag niet.
• Het beschermt geen andere service die een verzoek uit de preview accepteert.

De grens verandert ook in de loop van de tijd naarmate browsers en standaarden evolueren. Het gedrag van functies moet worden getest in de browsers die het publiek daadwerkelijk gebruikt, en de tokenlijst moet worden beoordeeld aan de hand van de huidige specificaties.

Hoe moet u een voorbeeld van een browsercode ontwerpen?

Begin met het lege zandbak attribuut en voeg vervolgens één mogelijkheid tegelijk toe. Maak voor elke toevoeging een kleine acceptatietest en een bijbehorende misbruiktest.

Houd het berichtprotocol voor het bovenliggende frame beperkt. Valideer de afzender, berichtvorm en toegestane opdrachten. Accepteer geen willekeurige code of navigatie-instructies via een generiek ‘execute’-bericht, tenzij dat het expliciet geïsoleerde product is dat u van plan bent te bouwen.

Bied een JavaScript-uitmodus aan voor statische inspectie. Voeg stop-, reset- of herlaadbedieningen toe voor weggelopen voorbeelden. Surface-consolefouten zonder gevoelige bovenliggende gegevens in het frame te spiegelen. Behandel externe stylesheets en scripts als netwerkafhankelijkheden waarvan de hosts en toekomstige inhoud buiten de controle van de editor vallen.

Voor een gericht experiment is de realtime HTML-editor onthult responsieve breedtes, console-opname, controles en de ondoorzichtige sandbox-status. Voor releasewerkzaamheden waarbij pakketten, servers, inloggegevens, tests of implementatie betrokken zijn, verplaatst u de code naar een lokale opslagplaats en gebruikt u een vollediger ontwikkelings- en veiligheidsbeoordelingsworkflow.