Defaults.Exposed › Correções › Proteção contra MIME-sniffing (X-Content-Type-Options)

Como corrigir Proteção contra MIME-sniffing (X-Content-Type-Options)

Um cabeçalho de uma linha que impede os navegadores de adivinharem o que um ficheiro realmente é. Sem ele, um ficheiro que alguém carregue para o seu site — ou um ficheiro nas suas próprias páginas — pode ser mal interpretado pelo navegador e executado como código, que é exatamente como alguns ataques transformam um carregamento de aparência inofensiva numa forma de roubar as sessões dos seus clientes.

O essencial para o seu negócio: A ausência deste cabeçalho é um sinal claro e detetável de que o básico não está implementado. Por si só raramente deita um site abaixo, mas combinado com um formulário de carregamento de ficheiros ou conteúdo gerado por utilizadores abre caminho a que um atacante execute código malicioso nos navegadores dos seus visitantes — sequestrando sessões autenticadas, roubando dados de cartão ou de início de sessão e colocando-o do lado errado de uma conversa sobre violação de dados. É uma das correções mais baratas em segurança: uma linha, gratuita, cerca de cinco minutos.

Quanto isto lhe pode custar

• Qualquer página onde clientes ou colaboradores possam carregar ficheiros (avatares, documentos, anexos de apoio, fotos de anúncios) torna-se uma possível rampa de lançamento para ataques do lado do navegador.
• Um atacante pode disfarçar código malicioso de imagem ou ficheiro de texto e fazer o navegador do visitante executá-lo — roubando-lhe a sessão autenticada no seu site.
• Questionários de segurança, verificações de seguro cibernético e compradores empresariais procuram este cabeçalho; a sua ausência lê-se como «não fazem o básico» e pode atrasar ou afundar um negócio.
• Navegadores mais antigos e algumas integrações «adivinham» tipos de conteúdo e podem manusear mal ficheiros de formas que quebram a confiança ou expõem dados.

Por que importa. Quando um servidor é vago sobre o que é um ficheiro, os navegadores tentam adivinhar («sniff») o tipo de conteúdo. Os atacantes exploram esse palpite: carregam um ficheiro que o servidor rotula como imagem, mas constroem o seu conteúdo de forma a que o navegador decida que é, na verdade, JavaScript — e o execute. O cabeçalho X-Content-Type-Options: nosniff diz a cada navegador para parar de adivinhar e confiar no tipo declarado pelo servidor, fechando toda essa categoria de truques. É uma verificação pontuada que vale 25 pontos e é classificada com severidade média quando está em falta.

A versão curta para o proprietário

Há um pressuposto silencioso embutido em todos os navegadores: quando descarrega um ficheiro do seu site, tenta perceber que tipo de ficheiro é. Normalmente confia no seu servidor. Mas se o seu servidor for vago, o navegador vai adivinhar — e a essa adivinhação chama-se MIME-sniffing.

O problema é que os atacantes conseguem manipular o palpite. Conseguem construir um ficheiro que o seu servidor acredita honestamente ser uma imagem inofensiva, mas que o navegador, deixado a adivinhar, decide ser, na verdade, um pedaço de código — e depois executa-o, mesmo dentro do navegador do seu cliente, no seu domínio.

Existe uma instrução de uma linha que desliga a adivinhação: X-Content-Type-Options: nosniff. Diz a cada navegador: «não adivinhes — confia exatamente no que o meu servidor te diz.» É essa toda a correção. É gratuita, demora cerca de cinco minutos e, num site bem construído, não parte nada.

Esta verificação procura esse cabeçalho. Se estiver em falta, perde 25 pontos e é classificado como problema de severidade média — não porque o cabeçalho, sozinho, seja uma catástrofe, mas porque a sua ausência é um sinal fiável de que o básico não foi protegido.

O que isto lhe pode custar

São cenários realistas, ao nível do negócio — não teatro de pior caso.

• O «anexo inofensivo» que não era. Tem um portal de apoio ou um marketplace onde os clientes carregam ficheiros — recibos, fotos, documentos. Um atacante carrega um ficheiro que o seu sistema guarda e serve como imagem. Sem o nosniff, o navegador de uma vítima adivinha que o ficheiro é, na verdade, um script e executa-o — roubando discretamente a sessão autenticada desse visitante no seu site. Agora o atacante é o visitante: faz encomendas, lê mensagens, altera dados. Só descobre quando os clientes começam a queixar-se de atividade que não fizeram.

• O negócio que trava num questionário de segurança. A equipa de compras de um cliente maior faz uma análise automática do seu site antes de assinar. Cabeçalhos de segurança em falta aparecem de imediato. Mesmo que nada tenha sido alguma vez explorado, o relatório diz «cabeçalhos básicos de segurança web ausentes», e de repente está a responder a perguntas de remediação e a empurrar a data de fecho por semanas — por uma correção que teria levado cinco minutos.

• A renovação do seguro cibernético que fica mais difícil. Cada vez mais seguradoras correm análises externas antes de cotar ou renovar. Um perfil de cabeçalhos limpo é prova barata de higiene; um em falta é uma pequena nota negativa que, empilhada com outras, empurra o prémio para cima ou as condições para baixo.

• O golpe na reputação que não desfaz facilmente. Se um incidente de sequestro de sessão remontar a um ficheiro servido a partir do seu domínio, a história não é «faltava um cabeçalho obscuro» — é «[a sua empresa] expôs contas de clientes». É essa a versão de que os clientes se lembram, e custa muito mais do que a correção alguma vez custaria.

Nenhum destes cenários exige um atacante sofisticado. O abuso de MIME-sniffing é bem compreendido e automatizado, que é exatamente por que os analisadores assinalam o cabeçalho em falta com tanta firmeza.

O que isto é, na realidade

Quando um navegador recebe um ficheiro, o servidor deve rotulá-lo com um tipo de conteúdo (por exemplo, image/png para uma imagem PNG ou text/html para uma página web). Historicamente, os navegadores não confiavam totalmente nesse rótulo — em parte porque alguns servidores erravam — por isso espreitavam os bytes reais do ficheiro e decidiam por si. Essa espreitadela é o MIME-sniffing.

Era uma conveniência que se tornou um passivo. Se um atacante conseguir pôr um ficheiro no seu site (através de um formulário de carregamento, um campo de comentários, um documento importado) e influenciar o seu conteúdo, pode construir algo que o servidor rotula de forma inócua mas que o navegador deteta como script executável. O navegador executa-o então no seu domínio, com toda a confiança que o seu domínio carrega.

O X-Content-Type-Options: nosniff elimina por completo a adivinhação. Com ele definido, diz-se ao navegador: usa o tipo declarado pelo servidor e mais nada. Um ficheiro rotulado como imagem é tratado como imagem, ponto final — mesmo que o seu conteúdo pareça script. O vetor de ataque fecha-se.

O que é «bom»: cada resposta do seu site — páginas e recursos por igual — carrega exatamente este cabeçalho:

X-Content-Type-Options: nosniff

Não há outro valor válido nem nada a afinar. Se a sua CDN e o seu servidor o adicionarem ambos (de modo que vê nosniff, nosniff), está bem e conta na mesma como aprovado.

Como corrigir (gratuito, ~5 minutos)

Entregue esta secção a quem gere o seu site — o seu responsável de TI, o seu programador web ou o apoio de alojamento. A correção é gratuita e rápida; não há nada a comprar. O que está a pedir é simples: «Adiciona o cabeçalho de resposta X-Content-Type-Options: nosniff a cada página e recurso do site.»

Eis o pormenor para eles, por plataforma comum.

Cloudflare (ou uma CDN/proxy semelhante) — muitas vezes o sítio mais rápido para o fazer, cobrindo todo o site de uma vez:

• Use uma Response Header Transform Rule (Rules → Transform Rules → Modify Response Header) para definir X-Content-Type-Options como nosniff para todos os pedidos. Isto aplica-o em todo o site sem tocar no servidor de origem.

Nginx — adicione dentro do bloco server (ou location) relevante:

add_header X-Content-Type-Options "nosniff" always;

A palavra-chave always garante que é enviado também nas respostas de erro. Recarregue o Nginx depois de guardar.

Apache — requer o mod_headers ativado; na configuração do site ou no .htaccess:

Header always set X-Content-Type-Options "nosniff"

IIS / alojamento Windows — no web.config, dentro de <system.webServer>:

<httpProtocol>
  <customHeaders>
    <add name="X-Content-Type-Options" value="nosniff" />
  </customHeaders>
</httpProtocol>

Node / Express — defina-o para cada resposta:

app.use((req, res, next) => {
  res.setHeader('X-Content-Type-Options', 'nosniff');
  next();
});

(Ou use o pacote helmet, que define este e vários outros cabeçalhos de segurança por omissão.)

Sites Google Workspace / Microsoft 365: estes gerem o seu e-mail e documentos, não o alojamento do seu site público, por isso o cabeçalho não se define aí — define-se onde o seu site é realmente servido (a sua CDN, servidor web ou construtor de sites). Se usa um construtor de sites alojado (Squarespace, Wix, Shopify e semelhantes), muitos adicionam este cabeçalho por si automaticamente; verifique o resultado em vez de assumir, e pergunte ao apoio deles se estiver em falta.

Depois de implementar, verifique. Volte a correr a análise, ou peça ao seu programador para verificar os cabeçalhos de resposta nas ferramentas de programador do navegador (separador Network → clicar em qualquer pedido → Response Headers) e confirmar que X-Content-Type-Options: nosniff está presente. Teste o site brevemente para confirmar que nada estilizado ou com script partiu — num site bem construído, nada partirá.

Erros comuns

• Defini-lo só na página inicial. O cabeçalho tem de estar em todas as respostas — incluindo imagens, scripts, folhas de estilo e ficheiros carregados — porque são esses os recursos que o sniffing afeta. Aplique-o ao nível do servidor ou da CDN para que seja universal, não página a página.
• Um erro de escrita no valor. O único valor válido é nosniff. Qualquer outra coisa (um valor em branco, um erro ortográfico) falha a verificação e não dá proteção nenhuma. O analisador reporta o valor que viu de facto, para conseguir detetar um erro de escrita.
• Assumir que substitui uma Content Security Policy. O nosniff é uma camada. Não controla que scripts podem correr — esse é o trabalho da CSP. Adicione o nosniff agora como vitória rápida e trate de uma CSP adequada como o seguimento maior.
• Remover o «duplicado». Se tanto a sua CDN como a origem o definirem, vai vê-lo duas vezes. É inofensivo — não perca tempo a retirar um.
• Pagar por isto. É uma alteração de configuração gratuita. Monitorização, auditorias e painéis de carteira são legitimamente pagos; adicionar um único cabeçalho não é.

Entregue isto ao seu responsável de TI

O resumo técnico: esta verificação inspeciona os cabeçalhos de resposta HTTP e é aprovada quando X-Content-Type-Options está presente e o seu valor (sem distinção de maiúsculas/minúsculas) contém nosniff — incluindo o caso multi-origem nosniff, nosniff, em que uma CDN e a origem o definem ambas. Ausente ou qualquer valor que não seja nosniff falha. É uma verificação pontuada P2 que vale 25 pontos, classificada com severidade média quando falha, e mapeia para o OWASP Top 10 A05 (Security Misconfiguration). A remediação é um único cabeçalho de resposta estático aplicado a todas as respostas; não há parâmetros nem valores alternativos válidos. Defina-o na borda (CDN) para cobertura de todo o site, ou no servidor web com semântica always para que seja emitido também nas respostas de erro, depois confirme nos cabeçalhos de resposta.

Perguntas frequentes