Defaults.Exposed › Correções › Proteção contra clickjacking (X-Frame-Options)

Como corrigir Proteção contra clickjacking (X-Frame-Options)

Uma instrução de uma linha que diz aos navegadores para não deixarem outros sites carregarem o seu site, em segredo, dentro deles próprios. Sem ela, um burlão pode esconder as suas páginas reais, com o cliente já autenticado, por trás de uma página falsa e levar os seus clientes a clicar em coisas que nunca pretenderam — aprovar um pagamento, alterar uma palavra-passe, conceder acessos.

O essencial para o seu negócio: Um fraudador pode envolver de forma invisível o seu site real dentro de um site falso e roubar dinheiro ou acessos às contas dos seus clientes autenticados — e, para o cliente, parece que foi o seu site que o fez. A correção é gratuita e ocupa um programador cerca de 15 minutos; deixá-la de fora é uma falha conhecida que tanto criminosos como compradores cautelosos detetam em segundos.

Quanto isto lhe pode custar

• Um burlão esconde o seu ecrã real de início de sessão ou de pagamento por trás de uma página de aparência inofensiva e leva um cliente a «confirmar» uma transferência ou uma alteração de definições sem se aperceber — o cliente culpa-o a si, não ao atacante.
• A área da conta do cliente, já autenticada, é carregada de forma invisível por cima de uma página do tipo «Ganhou — clique para receber»; o clique aprova, na verdade, uma alteração real na conta do cliente, e é a si que chega a chamada de apoio irritada.
• A equipa de TI de um potencial cliente faz uma verificação de segurança rápida antes de assinar, vê que o seu site pode ser incorporado por qualquer pessoa e marca-o como um risco que atrasa ou mata o negócio.
• A sua marca torna-se o isco de uma campanha de fraude; os clientes apanhados recordam-na como «a empresa cujo site deixou isto acontecer».
• Uma auditoria ou uma análise de seguro cibernético lista a ausência de proteção contra clickjacking como uma falha de higiene básica — barata de corrigir, embaraçosa de ter sido assinalada.

Por que importa. Esta é uma definição gratuita, de uma única linha, que demora minutos a adicionar e fecha toda uma categoria de truques dirigidos aos seus clientes autenticados. Na nossa pontuação é uma verificação de segurança web que vale pontos a sério, classificada como de severidade elevada, porque um cabeçalho em falta deixa um buraco conhecido e fácil de detetar que os criminosos automatizam e os compradores procuram.

O que é isto, em palavras simples

Quando alguém visita o seu site, o navegador pode também ser instruído a carregar o seu site dentro de outro site — como uma pequena janela incorporada numa página maior. Isso parece inofensivo, e às vezes é. Mas é o mecanismo por trás de um ataque chamado clickjacking.

Eis o truque. Um burlão constrói a sua própria página e carrega discretamente o seu site real dentro dela — de forma invisível, tornando-o totalmente transparente. Depois sobrepõe o seu próprio conteúdo: um botão chamativo, um «Reproduzir vídeo», um «Receba o seu prémio». O seu cliente vê a página do atacante e clica no que parece ser um botão inofensivo. Mas, como o seu site real está, invisível, por baixo do cursor, o clique acaba na sua página — a confirmar um pagamento, a alterar uma palavra-passe, a aprovar um acesso, a aceitar uma permissão. O cliente julga ter clicado numa coisa; clicou noutra, num site em que confia.

A proteção contra clickjacking é uma instrução curta e invisível que o seu site envia ao navegador de cada visitante, dizendo, na prática:

«Não deixes outros sites carregarem-me dentro deles. Se alguém tentar, recusa.»

Os navegadores modernos obedecem automaticamente. Com ela ativada, o truque simplesmente não funciona — a cópia incorporada do seu site recusa-se a carregar. Sem ela, o seu site é alvo livre para ser usado como a camada escondida de uma fraude, e o cliente apanhado vai associar tudo isto à sua marca, não à do atacante.

O que isto lhe pode custar

São cenários realistas, do dia a dia. Nunca nomeamos uma empresa real; estas são ilustrações de como a falha é explorada.

1. O «confirmar» invisível. Um cliente está autenticado no portal da sua conta num separador. Cai numa página (de um anúncio, de um e-mail, de um resultado de pesquisa) que promete algo apelativo e mostra um grande botão «Continuar». Escondido por baixo desse botão está o seu controlo real «Confirmar transferência» ou «Alterar e-mail», carregado a partir da sessão autenticada do próprio cliente. Ele clica em «Continuar» — e autoriza, sem o saber, uma alteração na conta real que tem consigo. Para ele, e para a sua equipa de apoio, parece que foi ele que o fez no seu site.

2. O sequestro de definições. Um atacante incorpora a sua página de definições da conta e sobrepõe-lhe um jogo ou inquérito inocente. Alguns cliques nos sítios certos alteram silenciosamente uma definição — adicionar o e-mail do atacante como endereço de recuperação, conceder uma permissão a uma aplicação ou desativar um alerta de segurança. A conta fica discretamente comprometida, e nada parecia errado na altura.

3. O negócio que trava. Um cliente maior envia o seu questionário de segurança habitual antes de assinar. Uma linha pergunta se o seu site define proteção contra incorporação (X-Frame-Options / CSP frame-ancestors). O seu contacto de TI tem de responder «não», e o departamento de compras faz uma pausa enquanto corre a corrigir uma definição gratuita de 15 minutos que agora parece uma bandeira vermelha perante um comprador.

4. A campanha que usa a marca como isco. Como as suas páginas reais e de confiança podem ser incorporadas, um atacante usa o seu início de sessão ou checkout como a camada convincente de uma campanha de phishing mais ampla. Os clientes apanhados não culpam o atacante na sombra — recordam-no como a vez em que «o seu site» os deixou ser burlados.

5. A nota da auditoria. A análise de uma seguradora, ou um auditor a rever a sua postura de segurança, lista a ausência de proteção contra clickjacking entre as conclusões. É um item de manual, de higiene básica; tê-lo assinalado sinaliza que as proteções fáceis e gratuitas não estavam ativas — o que tinge a forma como o resto da sua segurança é avaliada.

O fio condutor: o dano cai sobre um cliente real, autenticado, a fazer algo que não pretendia — e leva o seu nome, não o do atacante.

O que isto é, na realidade

Quando um navegador pede uma página ao seu site, o servidor devolve a página mais alguns «cabeçalhos» invisíveis — instruções extra que o navegador lê mas que o visitante nunca vê. A proteção contra clickjacking é entregue através destes cabeçalhos. Há dois, e a nossa verificação é aprovada se qualquer um estiver presente:

1. O cabeçalho mais antigo — X-Frame-Options:

X-Frame-Options: SAMEORIGIN

Este é o controlo de longa data e amplamente suportado. Aceita um de dois valores práticos:

• SAMEORIGIN — o seu próprio site pode incorporar as suas páginas, mas nenhum site externo pode. O valor seguro por omissão para quase toda a gente.
• DENY — ninguém pode incorporar as suas páginas, incluindo o senhor. Use isto só se o seu site nunca incorporar o seu próprio conteúdo.

2. O cabeçalho moderno — Content-Security-Policy frame-ancestors:

Content-Security-Policy: frame-ancestors 'self';

Este é o controlo mais recente e flexível, e aquele para que apontam as normas atuais. Faz o mesmo trabalho mas permite-lhe ser preciso sobre quem o pode incorporar:

• frame-ancestors 'self' — equivalente a SAMEORIGIN.
• frame-ancestors 'none' — equivalente a DENY.
• frame-ancestors 'self' https://parceiro.exemplo.com — o seu próprio site mais um parceiro nomeado e de confiança, e mais ninguém.

O que é «bom»

A configuração mais forte usa ambos: frame-ancestors para navegadores modernos (e pela precisão de nomear quem pode incorporar) e X-Frame-Options: SAMEORIGIN como recurso para clientes mais antigos. A nossa verificação é satisfeita por qualquer um deles isoladamente — mas, como ambos são gratuitos e levam os mesmos poucos minutos, não há razão para não definir os dois.

Um pormenor importante que o seu programador deve saber: um cabeçalho Content-Security-Policy-Report-Only não impõe nada — apenas reporta. Se quiser que a proteção contra clickjacking surta efeito, ela tem de vir de um cabeçalho que imponha (uma Content-Security-Policy normal com frame-ancestors, ou o X-Frame-Options), não de um apenas-de-relatório.

Como corrigir (gratuito, ~15 minutos)

Entregue esta secção a quem gere o seu site — o seu responsável de TI, programador web ou apoio de alojamento. A correção é gratuita. São um ou dois cabeçalhos de resposta, ou uma regra na sua CDN. Não há nada a comprar.

A verificação é aprovada quando ou um cabeçalho X-Frame-Options (definido como DENY ou SAMEORIGIN) ou uma diretiva CSP frame-ancestors estiver presente. A configuração recomendada, à prova de bala, adiciona ambos.

Passo 1 — Decidir quão restritivo ser

• A maioria das empresas: SAMEORIGIN / frame-ancestors 'self'. O seu próprio site continua a funcionar; os externos são bloqueados.
• Se o seu site nunca incorpora as suas próprias páginas: DENY / frame-ancestors 'none' para o bloqueio máximo.
• Se um parceiro genuíno tiver de incorporar uma página específica: nomeie-o explicitamente com frame-ancestors 'self' https://parceiro.exemplo.com; e mais ninguém entra.

Passo 2 — Adicionar os cabeçalhos (escolha a sua plataforma)

Nginx — dentro do seu bloco server:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache — garanta que o mod_headers está ativado, depois no seu virtual host:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

Microsoft IIS — no web.config, dentro de <customHeaders>:

<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Content-Security-Policy" value="frame-ancestors 'self';" />

Cloudflare (ou uma CDN semelhante): vá a Rules → Transform Rules → Modify Response Header e adicione duas regras que definam X-Frame-Options como SAMEORIGIN e Content-Security-Policy como frame-ancestors 'self'; em todas as respostas. Este é o caminho mais fácil se não tiver acesso direto ao servidor.

Já envia uma Content-Security-Policy por outros motivos? Não crie um segundo cabeçalho CSP — adicione frame-ancestors à sua política existente. Dois cabeçalhos CSP podem entrar em conflito.

Construtores de sites (Squarespace, Wix, Shopify e semelhantes): estas plataformas definem muitas vezes a proteção contra incorporação por si, por isso pode já passar sem ter nada a fazer. Se a nossa verificação a assinalar, o controlo costuma estar nas definições de segurança da plataforma, ou adiciona-o na CDN à frente do site. (Nota: o Google Workspace e o Microsoft 365 alimentam o seu e-mail, não o seu site — este cabeçalho define-se onde o seu site público realmente vive, não na administração do Workspace/365.)

Passo 3 — Recarregar e verificar

Recarregue o servidor web ou implemente a regra da CDN, depois abra o seu site real e verifique os cabeçalhos de resposta — ferramentas de programador do navegador → separador Network → clicar no pedido da página → Response Headers, ou qualquer ferramenta gratuita de verificação de cabeçalhos. Confirme que o(s) cabeçalho(s) aparece(m) nas respostas de páginas reais, não só na página inicial. Depois volte a correr a verificação.

Erros comuns

• Usar uma CSP apenas-de-relatório e julgar que protege. A Content-Security-Policy-Report-Only só reporta violações — não impõe nada. Precisa de um cabeçalho que imponha para a proteção surtir efeito.
• Definir dois cabeçalhos Content-Security-Policy separados. Se já tem uma CSP, adicione-lhe frame-ancestors em vez de emitir uma segunda política; cabeçalhos CSP em conflito podem produzir comportamentos inesperados.
• Definir DENY quando o seu próprio site incorpora as suas páginas. O DENY bloqueia toda a incorporação, incluindo a sua. Se alguma parte do seu site usa iframes de si mesmo, use antes SAMEORIGIN / frame-ancestors 'self', ou parte as suas próprias páginas.
• Proteger só a página inicial. As páginas que mais importam para o clickjacking são as que exigem autenticação — definições da conta, confirmação de pagamento, administração. Garanta que os cabeçalhos são aplicados em todo o site, não só na página de entrada.
• Assumir que o HTTPS ou o cadeado já cobrem isto. A cifragem e a proteção contra incorporação não têm relação. Um certificado perfeito não faz nada para impedir que as suas páginas sejam incorporadas.
• Confiar em soluções antigas. O JavaScript de «frame-busting» (scripts que tentam sair de frames) não é fiável e pode ser contornado. Os cabeçalhos são a correção certa, imposta pelo navegador.

Perguntas frequentes