O que é um iframe em sandbox?

Um iframe em sandbox é um documento de navegador incorporado com restrições extras aplicadas pelo iframe caixa de areia atributo. Com um vazio caixa de areia valor, o navegador inicia a partir de uma linha de base restritiva; indivíduo permitir-* os tokens retornam apenas os recursos de que o conteúdo incorporado precisa. Para uma visualização de HTML, o design útil mais seguro é não “confiar no código”. É “dar à visualização um limite separado, adicionar as permissões mínimas e manter os segredos fora do experimento”.

O que muda quando um iframe é colocado em sandbox?

Um iframe comum cria um contexto de navegação aninhado. A política de mesma origem, a política de permissões, a política de segurança de conteúdo e os próprios cabeçalhos do site enquadrado ainda são importantes, mas o quadro não é automaticamente despojado de todos os recursos do navegador.

Adicionando caixa de areia pede ao navegador para impor um conjunto adicional de restrições. O Padrão WHATWG HTML define o atributo como um conjunto de tokens não ordenado e separado por espaço. A ausência de um token mantém sua restrição de sandbox correspondente em vigor; adicionar um token elimina uma restrição específica.

Essa direção é fácil de interpretar mal:

```html

<iframe sandbox srcdoc="<p>Visualização estática</p>"></iframe>

```

Esta é a forma restritiva. Isso não significa “nenhuma opção de sandbox selecionada”. Isso significa que o sandbox está ativo e nenhum de seus recursos opcionais foi restaurado.

```html

<iframe

sandbox = "permitir scripts permitir formulários"

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

</iframe>

```

Esta versão permite scripts e comportamento de formulário, deixando outras restrições em vigor. O resultado exato da segurança ainda depende da origem do conteúdo e do que o aplicativo ao redor expõe.

Quais restrições se aplicam por padrão?

O padrão completo contém mais detalhes do que uma lista de verificação, mas essas categorias explicam a maior parte do comportamento de visualização.

O Referência de iframe MDN lista os tokens atuais e explica o que cada um restaura. Verifique essa referência em vez de copiar uma lista de tokens antiga em um controle de segurança de longa duração.

O que os tokens de permissão comuns restauram?

Pense em cada token como uma decisão de capacidade, não como uma opção de conveniência.

Alguns tokens interagem. Revisá-los um de cada vez é necessário, mas não suficiente. A origem do documento emoldurado, seja ele srcdoc ou uma URL remota, a Política de Segurança de Conteúdo do host e qualquer ponte de mensagem entre o quadro e o pai afetam o limite.

O diagrama descreve um limite de permissão. Ele não afirma que qualquer conjunto de tokens torne o código arbitrário inofensivo.

Por que uma origem opaca é importante?

Sem permitir a mesma origem, o conteúdo em área restrita é tratado como proveniente de uma origem especial que falha nas verificações normais de mesma origem. Os desenvolvedores costumam chamar isso de origem opaca ou única.

Para uma linha srcdoc visualização, essa separação é valiosa. A visualização pode renderizar um documento sem ser tratado como a mesma origem do aplicativo que a página do editor. Ele não pode simplesmente acessar o DOM do pai ou ler o armazenamento da mesma origem como se fosse outro componente do host.

Origem opaca não significa “offline” ou “rede desativada”. Se os scripts forem permitidos, o código de visualização ainda poderá fazer solicitações de rede permitidas pelas políticas do navegador e pelo destino. Ele pode usar CPU e memória, manipular seu próprio DOM e comunicar-se através de canais que o host expõe deliberadamente. A fronteira reduz a autoridade; não certifica o código.

MDN alerta especialmente sobre a combinação permitir scripts e permitir a mesma origem quando o conteúdo incorporado é da mesma origem e pode remover seu próprio atributo de sandbox. A lição importante é contextual: não restaure ambas as capacidades apenas porque um exemplo falha sem elas.

Como a visualização de ClockTools configura seu sandbox?

O ao vivo Editor ClockTools HTML em tempo real cria a visualização com srcdoc. Quando JavaScript está habilitado, seu valor de sandbox iframe é:

permitir scripts permitir formulários permitir modais

A implementação omite intencionalmente permitir a mesma origem, permitir pop-ups, permissões de navegação superior e permissão de download. A interface rotula a visualização como um caixa de areia opaca, tornando a decisão de origem visível em vez de ocultá-la no código-fonte.

Essa configuração oferece suporte a exemplos de ensino comuns: scripts podem atualizar a visualização, formulários podem exercitar a validação do navegador e o comportamento de envio, e exemplos modais podem ser executados. Não transforma código desconhecido em código confiável. A orientação do próprio editor, portanto, orienta os usuários a evitar segredos e revisar scripts desconhecidos.

A página também captura mensagens do console e expõe um painel de verificação de documentos. Esses são recursos de observabilidade, não permissões de sandbox. Um painel de console ajuda a explicar uma falha; isso não impede uma solicitação. Uma verificação estrutural pode sinalizar uma etiqueta ausente; ele não conduz uma análise de segurança completa.

O que uma verificação de capacidade mostrou?

Inspecionei o elemento de visualização renderizado no espaço de trabalho ativo ClockTools em vez de confiar apenas no texto de marketing.

O título do iframe era “Visualização ao vivo HTML”, que também fornece à tecnologia assistiva um rótulo de finalidade para o documento incorporado.

Esta inspeção confirma o limite configurado naquele momento. Isso não prova que todos os scripts possíveis são seguros e não substitui uma revisão da ponte de mensagens, do tratamento de recursos externos, da Política de Segurança de Conteúdo ou de futuras alterações de código.

Quais combinações de tokens merecem cuidado extra?

Use uma revisão baseada em ameaças em vez de uma receita de token universal.

permitir scripts mais permitir a mesma origem

Este par pode enfraquecer seriamente o isolamento quando o documento incorporado é da mesma origem e pode afetar as suas condições de incorporação. Se ambos forem necessários, forneça conteúdo não confiável de uma origem deliberadamente separada e analise os caminhos de fuga em vez de tratar o atributo como o único limite.

Formulários mais acesso à rede

formulários de permissão restaura o envio, mas scripts e elementos HTML comuns também podem enviar solicitações de outras maneiras. Nunca coloque credenciais, dados privados de clientes ou tokens ao portador em uma visualização não confiável e presuma que o sandbox os conterá.

Pop-ups e comportamento de fuga

permitir pop-ups permite que um quadro abra um novo contexto de navegação. permitir que pop-ups escapem da sandbox permite que o novo contexto evite sinalizadores de sandbox herdados. Isso pode ser útil para um anúncio ou link externo deliberadamente isolado, mas expande a superfície de revisão.

Navegação superior

As permissões de navegação superior permitem que o quadro substitua a página host sob condições definidas. Um playground de código raramente precisa disso. Se a navegação fizer parte da lição, considere interceptar e exibir o destino em vez de conceder o controle de visualização sobre a página de nível superior.

O que uma sandbox não pode proteger?

Uma sandbox é um mecanismo de navegador, não uma plataforma completa de código hostil.

• Isso não impede que um usuário abra o mesmo conteúdo diretamente fora do quadro.
• Isso não garante que os scripts permitidos sejam rápidos, educados ou livres de loops infinitos.
• Ele não bloqueia automaticamente todas as solicitações de rede.
• Ele não limpa HTML nem prova que um URL é seguro.
• Ele não protege segredos já colocados na visualização.
• Ela não substitui a validação do lado do servidor para formulários reais.
• Ele não valida acessibilidade, semântica ou comportamento entre navegadores.
• Não protege outro serviço que aceita uma solicitação da versão prévia.

A fronteira também muda com o tempo, à medida que os navegadores e os padrões evoluem. O comportamento dos recursos deve ser testado nos navegadores que o público realmente usa, e a lista de tokens deve ser revisada em relação às especificações atuais.

Como você deve projetar uma visualização do código do navegador?

Comece com o vazio caixa de areia atributo e, em seguida, adicione um recurso por vez. Para cada adição, crie um pequeno teste de aceitação e um teste de abuso correspondente.

Mantenha o protocolo de mensagem do quadro pai restrito. Valide o remetente, o formato da mensagem e os comandos permitidos. Não aceite código arbitrário ou instruções de navegação por meio de uma mensagem genérica de “execução”, a menos que esse seja o produto explicitamente isolado que você pretende construir.

Ofereça um modo JavaScript-off para inspeção estática. Adicione controles de parada, reinicialização ou recarga para exemplos de fuga. Erros de console de superfície sem espelhar dados pai confidenciais no quadro. Trate folhas de estilo e scripts externos como dependências de rede cujos hosts e conteúdos futuros estão fora do controle do editor.

Para um experimento focado, o editor HTML em tempo real expõe larguras responsivas, captura de console, verificações e seu estado de sandbox opaco. Para trabalhos de lançamento envolvendo pacotes, servidores, credenciais, testes ou implantação, mova o código para um repositório local e use um fluxo de trabalho de desenvolvimento e revisão de segurança mais completo.