Segurança de iFrames Embutidos: Boas Práticas para Developers Web (PT-PT)

Use Sandbox nos seus iFramesUtilize sempre o atributo sandbox para restringir as capacidades do iFrame, impedindo que conteúdo não fidedigno execute scripts, aceda ao armazenamento local ou submeta formulários.

Implemente CSP RobustoUtilize cabeçalhos Content Security Policy (CSP) para controlar quais recursos a sua página pode carregar e executar, visando especificamente os iFrames para prevenir problemas de conteúdo misto e injeção de scripts.

Utilize X-Frame-Options & CSP Frame-AncestorsProteja o seu site contra clickjacking ao definir X-Frame-Options para DENY ou SAMEORIGIN, e para navegadores modernos, use a diretiva mais granular frame-ancestors no seu CSP.

Seja Cauteloso com Conteúdo ExternoAnalise minuciosamente qualquer conteúdo de terceiros incorporado via iFrames, pois está implicitamente a confiar nas suas práticas de segurança. Prefira soluções que ofereçam fortes garantias de segurança ou permitam processamento do lado do servidor.

A Espada de Dois Gumes dos iFrames: Conveniência vs. Segurança

iFrames (Inline Frames) são uma parte integrante do desenvolvimento web moderno, permitindo que os developers incorporem conteúdo de outras fontes nas suas páginas web de forma transparente. Seja um vídeo do YouTube, um portal de pagamento, um widget de redes sociais ou um fluxo de verificação de identidade, os iFrames oferecem uma flexibilidade incomparável. No entanto, este poder vem com uma ressalva de segurança significativa. Sem as devidas precauções, os iFrames podem tornar-se vetores para vários ataques, incluindo clickjacking, cross-site scripting (XSS) e fuga de dados. À medida que as aplicações web se tornam mais complexas e interligadas, compreender e implementar as melhores práticas de segurança para iFrames já não é opcional; é uma necessidade.

O principal desafio com os iFrames reside no facto de estar essencialmente a permitir que conteúdo externo seja executado no contexto da sua própria página. Este conteúdo externo pode não aderir aos mesmos padrões de segurança da sua aplicação, ou pode até ser malicioso. Portanto, o objetivo da segurança de iFrames é isolar este conteúdo incorporado o máximo possível, limitando o seu potencial para interagir ou comprometer o seu documento pai e os dados do utilizador.

Medidas Essenciais de Segurança para iFrames: Sandboxing e CSP

1. O Atributo sandbox: A Sua Primeira Linha de Defesa

O atributo HTML5 sandbox é, sem dúvida, a funcionalidade de segurança mais crítica para iFrames. Permite aplicar um conjunto rigoroso de restrições ao conteúdo dentro do iFrame, isolando-o do resto da sua página. Por predefinição, incluir simplesmente o atributo sandbox sem quaisquer valores aplica as restrições mais rigorosas, tratando essencialmente o conteúdo do iFrame como se viesse de uma origem única e impedindo a execução de scripts, a submissão de formulários e o acesso ao armazenamento local.

Embora altamente seguro, o sandbox predefinido pode ser demasiado restritivo para muitos casos de uso. Pode levantar seletivamente as restrições fornecendo palavras-chave específicas como valores para o atributo sandbox:

• allow-forms: Permite a submissão de formulários.
• allow-modals: Permite que o iFrame abra janelas modais (como alert(), confirm(), prompt()).
• allow-popups: Permite popups (por exemplo, window.open()).
• allow-popups-to-escape-sandbox: Permite que documentos em sandbox abram novas janelas sem herdar as restrições do sandbox.
• allow-pointer-lock: Permite a API de bloqueio do ponteiro.
• allow-same-origin: Permite que o conteúdo do iFrame seja tratado como sendo da mesma origem que o documento pai, o que é frequentemente necessário para que o conteúdo incorporado funcione corretamente (por exemplo, aceder a cookies, armazenamento local). Use com extrema cautela.
• allow-scripts: Permite a execução de JavaScript. Esta é uma permissão poderosa e só deve ser concedida a fontes fidedignas.
• allow-top-navigation: Permite que o iFrame navegue no contexto de navegação de nível superior (ou seja, altere o URL da janela pai).

Melhor Prática: Utilize sempre o atributo sandbox. Comece com o predefinido (sem valores) e adicione apenas as permissões mínimas necessárias. Por exemplo, se estiver a incorporar um formulário de pagamento, pode precisar de allow-forms allow-scripts, mas definitivamente não iria querer allow-same-origin a menos que seja absolutamente necessário e minuciosamente verificado.

<iframe src="https://trusted-payment-gateway.com/form" sandbox="allow-forms allow-scripts"></iframe>

2. Content Security Policy (CSP): Controlo do Carregamento de Conteúdo

Content Security Policy (CSP) é um poderoso mecanismo de segurança que ajuda a mitigar vários tipos de ataques, incluindo XSS e injeção de dados. Ao definir um CSP através de um cabeçalho HTTP (Content-Security-Policy) ou de uma tag <meta>, pode especificar quais as fontes de conteúdo que são permitidas para serem carregadas e executadas pelo navegador.

Para a segurança de iFrames, o CSP é crucial de duas formas principais:

• Proteger o Pai do iFrame: Um CSP forte na sua página pai pode impedir que um iFrame explorado carregue scripts ou conteúdo maliciosos na sua aplicação principal.
• Proteger o iFrame do Pai (e vice-versa): A diretiva frame-src controla especificamente as fontes válidas para iFrames. A diretiva frame-ancestors dita quais as origens que são permitidas para incorporar o recurso atual (a sua página) num iFrame, prevenindo o clickjacking.

Exemplo de Cabeçalho CSP:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; frame-src 'self' https://trusted-iframe-source.com; frame-ancestors 'self';

Este CSP permite scripts apenas da sua própria origem e de trusted-cdn.com, e permite iFrames apenas da sua própria origem e de trusted-iframe-source.com. Crucialmente, frame-ancestors 'self' garante que a sua página só pode ser incorporada por ela própria, prevenindo eficazmente o clickjacking.

Proteção Contra Clickjacking: X-Frame-Options e frame-ancestors

Clickjacking (redirecionamento de interface do utilizador) é um ataque onde um site malicioso sobrepõe um iFrame transparente do seu site sobre o seu próprio, enganando os utilizadores a clicar em elementos do seu site enquanto pensam que estão a interagir com o site malicioso. Isto pode levar a ações não autorizadas, como fazer compras, alterar configurações ou revelar informações sensíveis.

1. Cabeçalho HTTP X-Frame-Options

O cabeçalho HTTP X-Frame-Options é uma forma tradicional de prevenir o clickjacking. Diz aos navegadores se uma página pode ser renderizada num <frame>, <iframe>, <embed> ou <object>.

• X-Frame-Options: DENY: A página não pode ser exibida num frame, independentemente do site que tenta fazê-lo. Esta é a opção mais segura.
• X-Frame-Options: SAMEORIGIN: A página só pode ser exibida num frame na mesma origem que a própria página.

Melhor Prática: A menos que precise explicitamente que a sua página seja incorporada por outros sites (e, nesse caso, use frame-ancestors com cuidado), defina X-Frame-Options: DENY para todas as páginas que lidam com ações sensíveis do utilizador.

2. Diretiva frame-ancestors do CSP

A diretiva frame-ancestors dentro do Content Security Policy é uma alternativa mais moderna e flexível a X-Frame-Options. Permite especificar múltiplas origens que são permitidas para incorporar o seu conteúdo.

Exemplo:

Content-Security-Policy: frame-ancestors 'self' https://partner-site.com;

Isto permite que a sua página seja incorporada por ela própria e por partner-site.com. Se ambos X-Frame-Options e frame-ancestors estiverem presentes, frame-ancestors geralmente terá precedência nos navegadores modernos. É uma boa prática usar ambos para uma compatibilidade mais ampla com os navegadores.

Gestão e Comunicação Responsável de Dados

Quando os iFrames precisam de comunicar com a sua janela pai (ou vice-versa), o acesso direto a JavaScript é geralmente bloqueado pela Política de Mesma Origem. O método seguro recomendado para comunicação entre origens é window.postMessage().

Utilizar window.postMessage() de Forma Segura

window.postMessage() permite que as janelas comuniquem entre si de forma segura através de diferentes origens. No entanto, é crucial usá-lo corretamente para evitar vulnerabilidades.

• Verifique sempre a origem do remetente: Ao receber uma mensagem, verifique sempre a propriedade event.origin para garantir que a mensagem veio de uma fonte esperada.
• Especifique a origem alvo: Ao enviar uma mensagem, forneça a origem alvo exata (por exemplo, iframeWindow.postMessage('olá', 'https://expected-origin.com');) em vez de '*'. Usar '*' significa que qualquer janela pode potencialmente receber a sua mensagem, o que é um risco de segurança.
• Sanitize os dados recebidos: Trate quaisquer dados recebidos via postMessage() como entrada não fidedigna e sanitize-os antes de os usar para prevenir XSS.

Exemplo (Pai a enviar para iFrame):

const iframe = document.getElementById('myIframe');
iframe.contentWindow.postMessage('Olá do pai!', 'https://trusted-iframe-source.com');

Exemplo (iFrame a receber do pai):

window.addEventListener('message', (event) => {
  if (event.origin !== 'https://parent-domain.com') {
    // Mensagem não da origem esperada, ignorar ou registar.
    return;
  }
  console.log('Mensagem do pai:', event.data);
  // Processar dados, mas sanitize-os primeiro!
});

Como o Didit Ajuda com Fluxos de Trabalho Incorporáveis Seguros

O Didit, como plataforma de identidade tudo-em-um, utiliza frequentemente componentes incorporáveis para os seus fluxos de verificação de identidade. A nossa abordagem é construída com a segurança no seu cerne, compreendendo a necessidade crítica de um iFrame robusto e isolamento do fluxo de trabalho. O Didit fornece links de verificação alojados seguros e SDKs Web que são projetados para integrar-se perfeitamente, aderindo aos mais altos padrões de segurança.

• Links de Verificação Alojados: O Didit gera URLs seguras e únicas para cada sessão de verificação. Estes links redirecionam os utilizadores para um ambiente alojado e isolado pelo Didit, separando completamente o processo de verificação sensível do domínio da sua aplicação. Isto elimina a necessidade de sandboxing complexo de iFrames da sua parte para a verificação central.
• SDK Web com Forte Isolamento: Para cenários que exigem incorporação em contexto, o SDK Web do Didit é projetado para operar dentro de um iFrame seguro, aproveitando os atributos sandbox mais estritos necessários. Gerimos as complexidades da comunicação segura entre origens usando postMessage(), garantindo que apenas os dados necessários e sanitizados são trocados entre o iFrame e a sua aplicação.
• Conformidade e Certificações: O Didit é certificado SOC 2 Tipo II e ISO 27001, e está em conformidade com o GDPR. A nossa infraestrutura e processos são construídos para lidar com dados de identidade sensíveis de forma segura, reduzindo a sua carga de conformidade e risco.
• Exposição Mínima de Dados: A arquitetura do Didit é "privacy-by-design". Para verificação biométrica, as selfies são processadas em memória e eliminadas, e a sua aplicação recebe valores booleanos (por exemplo, 'verificado'), nunca dados biométricos brutos. Isto minimiza a informação sensível manuseada em qualquer componente incorporável.

Ao utilizar as soluções incorporáveis seguras e pré-construídas do Didit, as empresas podem integrar verificação de identidade avançada sem se tornarem especialistas em segurança de iFrames, permitindo-lhes focar-se no seu produto principal, garantindo a confiança do utilizador e a proteção de dados.

Pronto para Começar?

Garantir a segurança dos seus iFrames é um passo crítico na construção de uma aplicação web resiliente e fidedigna. Ao aplicar diligentemente o sandboxing, CSP, X-Frame-Options e práticas seguras de postMessage(), pode aproveitar o poder do conteúdo incorporado sem expor os seus utilizadores ou a sua aplicação a riscos desnecessários. Explore as soluções de verificação de identidade seguras do Didit para ver como é fácil integrar segurança robusta nos seus fluxos de trabalho.

Ver Preços Didit | Explorar Documentação Didit | Experimente uma Demonstração