Implicações dos cabeçalhos de resposta HTTP para a segurança

Quando um servidor web recebe uma solicitação HTTP, ele a processa e envia uma resposta com o recurso solicitado e informações adicionais na forma de cabeçalhos de resposta HTTP. Esses cabeçalhos fornecem dados importantes, como datas da última modificação, tipos de conteúdo e configurações de cache. Em seguida, o navegador usa essas informações para decidir como exibir ou armazenar o recurso. Esse processo ajuda a garantir uma comunicação eficiente entre servidores web e navegadores.

Do ponto de vista da cibersegurança, os cabeçalhos de resposta HTTP representam possíveis vetores de ataque e oportunidades para adicionar camadas extras de proteção. Eles podem conter dados confidenciais, como tokens de autenticação, cookies e IDs de sessão, que, quando acessados, permitem que invasores burlem controles de autorização ou sequestrem contas de usuários. Mas também podemos usá-los para controlar o cache, especificar o tipo de conteúdo retornado e impedir ataques como cross-site scripting (XSS) e clickjacking.

Os cabeçalhos de resposta HTTP oferecem vários recursos de segurança, incluindo autenticação, rastreamento do user agent, prevenção contra XSS e imposição do uso de HTTPS. Embora certos cabeçalhos HTTP, como Etag, Last-Modified e Content-Type, não sejam úteis para fins de segurança, os cabeçalhos Content Security Policy (CSP), HTTP Strict Transport Security (HSTS) e X-Frame Options ajudam a reforçar a proteção dos nossos servidores.

Este artigo destaca vários cabeçalhos HTTP que afetam a segurança e apresenta boas práticas para usar cabeçalhos de resposta HTTP na proteção de aplicações web.

Como usar cabeçalhos de resposta HTTP para reforçar a segurança

Podemos usar cabeçalhos de resposta HTTP para mitigar vários tipos de vulnerabilidades exploráveis. 

Vulnerabilidades a considerar nos cabeçalhos de resposta HTTP

Os cabeçalhos de resposta HTTP adequados mitigam explorações diretas e também ajudam a lidar com vulnerabilidades que não os envolvem diretamente. Alguns exemplos de diferentes tipos de exploração e vulnerabilidades incluem:

• Falsificação de solicitação entre sites (CSRF): invasores podem usar CSRF, também conhecido como ataque de um clique, para forçar o navegador de um usuário a realizar ações indesejadas em seu nome.

• Sequestro de sessão: invasores obtêm acesso não autorizado ao roubar IDs de sessão de usuários autenticados e sequestrar as sessões existentes sem credenciais, como pares de nome de usuário e senha — burlando os sistemas tradicionais de autenticação.

• Vazamento de dados: os cabeçalhos de resposta HTTP podem conter senhas, números de cartão de crédito e outras informações confidenciais, que podem vazar se a configuração não for feita corretamente.

• Ataques man-in-the-middle (MITM): invasores usam ataques MITM para interceptar, modificar e bloquear comunicações entre duas partes durante uma transação. Nenhuma das partes sabe que está se comunicando com um terceiro não autorizado.

• Ataques de clickjacking: ao explorar falhas em framesets HTML de um site, invasores podem exibir conteúdo falsificado aos usuários. Quando clicam nele, os usuários acabam realizando ações indesejadas ou divulgando informações confidenciais sem perceber.

Manter a segurança das aplicações web é fundamental, especialmente diante de tantas possibilidades de ataque. Nos últimos anos, vimos um aumento nas violações de segurança de grande repercussão e alto impacto. Por exemplo:

• Em um vazamento de dados recente envolvendo a empresa de análise de crédito TransUnion, invasores mantiveram as informações de mais de 50 milhões de pessoas sul-africanas como reféns, exigindo US$ 15 milhões. 

• Plugins de WordPress relacionados ao GDPR podem estar sujeitos a ataques de XSS e CSRF. Um plugin afetou 10.000 sites em 2018, e outro expôs 700.000 sites em 2020. 

• Grandes empresas de tecnologia são sempre alvos atraentes. Felizmente para a Uber, empresa de transporte por aplicativo, as vulnerabilidades de CSRF e sequestro de sessão custaram apenas cerca de US$ 5.000 em recompensas por bugs concedidas.

Com ataques ocorrendo com tanta frequência e em escala tão significativa, fica claro que reforçar e manter a segurança — inclusive por meio de cabeçalhos HTTP — é indispensável. 

Cabeçalhos de resposta HTTP que afetam a segurança

O vazamento de dados é uma vulnerabilidade diretamente relacionada aos cabeçalhos de resposta HTTP. Ataques de CSRF, sequestro de sessão e MITM não envolvem necessariamente esses cabeçalhos. Ainda assim, podemos mitigá-los usando cabeçalhos HTTP seguros — como CSP e HTTP Strict Transport Security (HSTS) — e seguindo boas práticas no uso de outros cabeçalhos que afetam a segurança, como os descritos a seguir.

Cabeçalho HTTP Strict Transport Security

O cabeçalho de resposta HSTS protege aplicações contra ataques MITM, vazamentos de dados e clickjacking. Ele força toda a comunicação entre o navegador e o servidor a ocorrer por conexões HTTPS, em vez de HTTP simples. Isso impede que invasores redirecionem o tráfego por meio de servidores proxy maliciosos para acessar ou manipular dados confidenciais transmitidos, sem que nenhuma das partes perceba.

O HSTS contém informações sobre as políticas de segurança de um site, como:

• Por quanto tempo a conexão permanecerá ativa (idade máxima).

• Se o escopo da proteção inclui subdomínios.

• Quais tipos de certificados aceitar.

Para aproveitar ao máximo o cabeçalho de resposta HSTS, devemos sempre definir um valor de idade máxima. Ele deve corresponder ao período durante o qual queremos que os clientes se lembrem de se conectar com segurança antes de enviar outra solicitação pelo túnel TLS/SSL.

Cabeçalho Content-Security-Policy

A CSP é importante para se defender de diferentes tipos de ataque. Ela permite que desenvolvedores criem listas de permissão para recursos e suas origens, definam diretivas, decidam se scripts inline ou eval() são permitidos e determinem se atributos de estilo podem ser usados em HTML.

O cabeçalho de resposta HTTP Content-Security-Policy permite especificar os domínios e recursos permitidos ou bloqueados no conteúdo de um site. Ele protege contra XSS e as vulnerabilidades mencionadas anteriormente, além de outras atividades maliciosas, como clickjacking, injeção de dados, injeção de código, CSRF e acesso não autorizado a informações confidenciais. A CSP contém diretivas que determinam como os navegadores devem lidar com solicitações de fontes não confiáveis fora do nosso domínio, inclusive ao carregar scripts, imagens e outros recursos exploráveis.

Veja algumas orientações para configurar o cabeçalho CSP e se defender proativamente contra vulnerabilidades:

• Sempre que possível, prefira políticas que bloqueiem atividades em vez de permiti-las. Assim, as solicitações de fontes não confiáveis fora do seu domínio serão bloqueadas por padrão.

• Use subdomínios curinga (prefixo *.<your-domain-name> antes do seu domínio principal).

• Restrinja o acesso a fontes confiáveis conhecidas, em vez de permitir solicitações de qualquer fonte. Inclua também diretivas que determinem como os navegadores devem lidar com certas solicitações de fontes não confiáveis fora do nosso domínio, como o carregamento de scripts, imagens e outros recursos exploráveis.

Uma postura de segurança rigorosa garante que somente clientes autorizados possam visualizar informações confidenciais e impede vazamentos de dados por rotas subsequentes não previstas. Também podemos usar mecanismos rigorosos de validação, como Subresource Integrity (SRI), que ajudam a verificar a integridade dos recursos de um site e garantem que um invasor não os tenha adulterado. 

Ao combinar SRI com CSP, podemos garantir que somente recursos de terceiros confiáveis e não corrompidos sejam carregados em nossas páginas web.

Cabeçalho X-Content-Type-Options

Podemos usar o cabeçalho X-Content-Type-Options para instruir os navegadores a nunca tentar detectar automaticamente o tipo de arquivo ou conteúdo servido. Isso dificulta muito a injeção de código malicioso em um site, pois o navegador não poderá analisar nem executar arquivos de script arbitrários enviados junto com o conteúdo. Dessa forma, o cabeçalho X-Content-Type-Options atua como uma linha de defesa contra conteúdo malicioso e ataques de XSS.

Ao configurar e usar esse cabeçalho, garanta que todos os sites sirvam conteúdo com tipos MIME definidos de forma estrita. Evite usar curingas (*) sempre que possível nesses valores. Especificar os tipos de arquivo corretos informa aos navegadores exatamente quais recursos esperar, eliminando a necessidade de detectá-los. 

Cabeçalho X-Frame-Options

X-Frame-Options protege aplicações web contra ataques de clickjacking. Ele contém uma diretiva que informa ao navegador se o conteúdo pode ser exibido dentro de um elemento <iframe> em um site de terceiros. 

Há duas diretivas usadas com frequência. DENY impede qualquer tentativa de incorporar o recurso solicitado em outros sites. SAMEORIGIN permite a solicitação somente se ambas as páginas estiverem hospedadas sob a mesma política de origem. Essa configuração ajuda a se defender contra clickjacking e outras vulnerabilidades de segurança relacionadas a XSS.

O ideal é garantir que todos os recursos servidos pela aplicação web incluam sempre X-Frame-Options — DENY em vez de SAMEORIGIN. Também devemos usar o nível máximo de proteção como padrão, pois nunca é possível ter certeza de quando e como o conteúdo pode sair do escopo da nossa política de origem. 

Cabeçalho Referrer-Policy

O cabeçalho Referrer-Policy controla o compartilhamento de informações de referência entre diferentes aplicações ou sites. Ele contém quatro diretivas principais — none, no-referrer, no-referrer-when-downgrade e origin — que determinam como o navegador compartilha a URL de referência com outros sites ou aplicações durante a navegação. 

Podemos configurar esse cabeçalho de acordo com nossas necessidades para garantir que dados confidenciais não sejam expostos acidentalmente enquanto os usuários navegam por diferentes propriedades web ou domínios.

O ideal é definir Referrer-Policy como no-referrer para que os cabeçalhos de solicitação não incluam informações de referência quando os usuários clicarem em links externos. Essa configuração preserva a privacidade deles ao impedir que dados pessoais vazem por canais não previstos.

Como definir cabeçalhos de segurança em JavaScript 

A seção a seguir apresenta três ferramentas que podemos usar para definir cabeçalhos de segurança ao desenvolver com JavaScript. Vale lembrar que você também pode aplicá-las a outras linguagens e ecossistemas.

Depois de analisar cada ferramenta, vamos mostrar um exemplo prático de como usá-la para definir cabeçalhos de segurança.

Helmet para Express.js

Helmet é um conjunto de cabeçalhos de resposta HTTP relacionados à segurança que ajudam a proteger aplicações web contra ataques e vulnerabilidades. Helmet para Express.js é uma extensão do pacote Helmet, criada especificamente para funcionar com o framework Express.js. Ele oferece nove funções menores de middleware que definem cabeçalhos de resposta HTTP específicos relacionados à segurança para as aplicações.

A configuração do Helmet para Express.js é simples. Primeiro, instale o Helmet com este comando:

1npm install helmet

Em seguida, use o código abaixo para importar o framework Express e o pacote Helmet e usar suas funções de middleware. Assim, podemos definir os cabeçalhos de resposta:

1const express = require("express");
2const helmet = require("helmet");

Depois, use este código para criar uma instância de uma aplicação Express, atribuí-la a uma variável e começar a usar as funções de middleware do Helmet:

1const app = express();
2app.use(helmet());

A inicialização do Helmet define vários cabeçalhos de segurança, incluindo os cinco que discutimos acima. Podemos personalizar opções individuais de cabeçalho no Helmet para Express.js adicionando-as ao middleware helmet() com o código a seguir:

1app.use(
2  helmet({
3    X-Frame-Options: { policy: "DENY" },
4  })
5);

Helmet para Fastify

Helmet para Fastify é um pacote de middleware que permite adicionar cabeçalhos de segurança importantes ao framework web Fastify. Essencialmente, ele encapsula o Helmet e aceita as mesmas opções.

Instale o Helmet para Fastify executando:

1npm i @fastify/helmet.

Em seguida, importe o framework Fastify e o Helmet para Fastify com este código:

1const fastify = require('fastify');
2const helmet = require('@fastify/helmet');

Depois, registre o plugin Helmet na aplicação executando este código:

1fastify.register(helmet);

Este comando definirá automaticamente os cabeçalhos básicos de segurança.

check-my-headers

Check-my-headers é uma ferramenta de CLI gratuita que podemos usar para testar rapidamente os cabeçalhos HTTP do nosso site e identificar possíveis vulnerabilidades. Além de gratuita, ela é independente de framework: verifica nossos cabeçalhos sem levar em conta o que usamos para configurá-los.

Podemos instalá-la globalmente com npm install -g check-my-headers e executar uma análise rápida usando npx check-my-headers https://yourwebsite.com na CLI.

Conclusão 

Vários cabeçalhos de resposta HTTP importantes afetam a segurança na web, e seguir as práticas recomendadas para usá-los cria uma camada extra de proteção para aplicações web. Os cinco cabeçalhos abordados aqui ajudam a proteger contra várias vulnerabilidades, como ataques CSRF, sequestro de sessão, vazamento de dados, ataques man-in-the-middle (MITM) e clickjacking — ameaças que podem causar danos significativos e, muitas vezes, irreparáveis. Entender como os cabeçalhos de resposta HTTP podem enfraquecer ou reforçar a segurança é um passo importante para reduzir esses vetores de ataque comuns.

Configurar e usar corretamente os cabeçalhos de resposta é essencial para a segurança na web. Eles protegem a privacidade dos usuários e oferecem mais flexibilidade para proteger a comunicação entre servidores web e clientes.