Wat is een iframe in een sandbox?

Een iframe in een sandbox is een ingebed browserdocument met extra beperkingen via het sandbox-attribuut van het iframe. Bij een lege sandbox-waarde begint de browser met een beperkende uitgangssituatie; afzonderlijke allow-*-tokens herstellen alleen de mogelijkheden die de ingebedde inhoud nodig heeft. Voor een HTML-voorbeeld is het veiligste bruikbare ontwerp niet 'vertrouw de code', maar 'geef het voorbeeld een eigen grens, ken minimale rechten toe en houd geheimen buiten het experiment'.

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

Een gewoon iframe creëert een geneste browsecontext. Same-origin policy, Permissions Policy, Content Security Policy en de eigen headers van de ingesloten site blijven van belang, maar het frame verliest niet automatisch alle browsermogelijkheden.

Door sandbox toe te voegen, vraagt u de browser extra beperkingen op te leggen. De WHATWG HTML Standard definieert het attribuut als een ongeordende verzameling tokens, gescheiden door spaties. Zonder een token blijft de bijbehorende sandboxbeperking gelden; een token toevoegen heft een bepaalde beperking op.

Die werking wordt gemakkelijk verkeerd begrepen:

<iframe sandbox srcdoc="<p>Static preview</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.

<iframe
  sandbox="allow-scripts allow-forms"
  srcdoc="<button type='button'>Run</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 gedrag van een voorbeeldweergave.

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.

Welke mogelijkheden herstellen veelgebruikte allow-tokens?

Beschouw elk token als een keuze over toegangsrechten, niet als een schakelaar voor gemak.

Sommige tokens beïnvloeden elkaar. Ze afzonderlijk beoordelen is nodig, maar niet genoeg. De oorsprong van het ingesloten document, of het srcdoc of een externe URL gebruikt, de Content Security Policy van de host en elke berichtenbrug tussen frame en bovenliggende pagina beïnvloeden samen 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 allow-same-origin krijgt inhoud in de sandbox een speciale oorsprong die niet aan normale same-origin-controles voldoet. Ontwikkelaars noemen dit vaak een ondoorzichtige of unieke oorsprong.

Voor een inline srcdoc-voorbeeld is die scheiding waardevol. Het voorbeeld kan een document weergeven zonder dezelfde applicatieoorsprong te krijgen als de editorpagina. Het kan niet zomaar de DOM van de bovenliggende pagina benaderen of same-origin-opslag lezen alsof het een ander onderdeel van de host is.

Een 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. De code kan CPU en geheugen gebruiken, zijn eigen DOM aanpassen en communiceren via kanalen die de host bewust aanbiedt. De grens beperkt de rechten; hij certificeert de code niet.

MDN waarschuwt vooral voor het combineren van allow-scripts en allow-same-origin als de ingebedde inhoud dezelfde oorsprong heeft en haar eigen sandboxattribuut kan verwijderen. De les hangt van de context af: herstel niet beide mogelijkheden alleen omdat een voorbeeld zonder die rechten niet werkt.

Hoe stelt het ClockTools-voorbeeld zijn sandbox in?

De live ClockTools realtime HTML-editor bouwt het voorbeeld met srcdoc. Als JavaScript is ingeschakeld, is de sandboxwaarde van het iframe:

allow-scripts allow-forms allow-modals

De implementatie laat bewust allow-same-origin, allow-popups, rechten voor navigatie van de bovenliggende pagina en downloadrechten weg. De interface noemt het voorbeeld een sandbox met ondoorzichtige oorsprong, zodat de keuze voor de oorsprong zichtbaar is in plaats van verborgen in de broncode.

Die configuratie ondersteunt gangbare lesvoorbeelden: scripts kunnen de voorbeeldweergave bijwerken, formulieren kunnen browservalidatie en verzendgedrag demonstreren en modale dialoogvensters kunnen worden getoond. Onbekende code wordt daarmee niet betrouwbaar. De richtlijnen van de editor vragen gebruikers daarom geen geheimen in te voeren en onbekende scripts te beoordelen.

De pagina legt ook consoleberichten vast en toont een paneel voor documentcontroles. Dit zijn functies om het gedrag te volgen, geen sandboxrechten. Een consolepaneel helpt een fout verklaren, maar voorkomt geen verzoek. Een structuurcontrole kan een ontbrekend label signaleren, maar voert geen volledige beveiligingsbeoordeling uit.

Wat bleek uit een controle van de toegangsrechten?

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 ingestelde grens op dat moment. Ze bewijst niet dat elk mogelijk script veilig is en vervangt geen beoordeling van de berichtenbrug, verwerking van externe bronnen, Content Security Policy of toekomstige codewijzigingen.

Welke tokencombinaties verdienen extra voorzichtigheid?

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

allow-scripts plus allow-same-origin

Dit paar kan de isolatie ernstig verzwakken wanneer het ingesloten document dezelfde oorsprong heeft en zijn insluitingsvoorwaarden kan beïnvloeden. Als beide nodig zijn, bied dan niet-vertrouwde inhoud vanaf een bewust afzonderlijke oorsprong aan en analyseer de ontsnappingsroutes. Beschouw het attribuut niet als de enige grens.

Formulieren plus netwerktoegang

allow-forms staat verzending weer toe, maar scripts en gewone HTML-elementen kunnen ook op andere manieren verzoeken versturen. Zet nooit inloggegevens, persoonlijke klantgegevens of bearer-tokens in een niet-vertrouwd voorbeeld in de veronderstelling dat de sandbox ze binnenhoudt.

Pop-ups en het verlaten van de sandbox

Met allow-popups kan een frame een nieuwe browsecontext openen. Met allow-popups-to-escape-sandbox kan die nieuwe context de overgenomen sandboxbeperkingen vermijden. Dat kan nuttig zijn voor een bewust geïsoleerde advertentie of externe link, maar vergroot wat u moet beoordelen.

Navigatie van de bovenliggende pagina

Rechten voor navigatie van de bovenliggende pagina laten het frame onder bepaalde voorwaarden de hostpagina vervangen. Een code-oefenomgeving heeft dat zelden nodig. Als navigatie deel van de les is, overweeg dan de bestemming te onderscheppen en te tonen in plaats van het voorbeeld controle over de bovenliggende pagina te geven.

Wat kan een sandbox niet beschermen?

Een sandbox is één browsermechanisme, geen volledig platform voor het veilig uitvoeren van 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 zijn, zich netjes gedragen of geen oneindige lussen bevatten.
• Het blokkeert niet automatisch elk netwerkverzoek.
• Het schoont HTML niet op 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 controleert niet de toegankelijkheid, semantiek of werking in verschillende browsers.
• 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 ontwerpt u een browservoorbeeld voor code?

Begin met het lege sandbox-attribuut en voeg daarna telkens één mogelijkheid 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 modus zonder JavaScript voor statische inspectie. Voeg bediening voor stoppen, resetten of herladen toe voor voorbeelden die uit de hand lopen. Toon consolefouten zonder gevoelige gegevens van de bovenliggende pagina naar het frame te kopiëren. Behandel externe stylesheets en scripts als netwerkafhankelijkheden waarvan de hosts en toekomstige inhoud buiten de controle van de editor vallen.

Voor een gericht experiment biedt de realtime HTML-editor responsieve breedten, console-opname, controles en een zichtbare sandboxtoestand met ondoorzichtige oorsprong. Voor releasewerk met pakketten, servers, inloggegevens, tests of deployment verplaatst u de code naar een lokale repository en gebruikt u een uitgebreidere ontwikkel- en beveiligingsbeoordeling.