Rebaixamento de HTTP e riscos de conteúdo misto

O cabeçalho HTTP Strict Transport Security (HSTS) instrui os navegadores a se conectarem a um site somente por HTTPS durante um período especificado. Depois de recebê-lo, o navegador recusa conexões HTTP e atualiza automaticamente os URLs http:// para https://.

Um cabeçalho HSTS típico: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload". O max-age é expresso em segundos (31536000 = 1 ano). Depois de armazenado em cache, o navegador impõe o uso de HTTPS por um ano sem qualquer participação do servidor.

O parâmetro max-age define por quanto tempo o navegador deve impor conexões exclusivamente HTTPS, em segundos. Para sites em produção, os valores recomendados são de pelo menos um ano (31536000).

A diretiva includeSubDomains estende a aplicação do HSTS a todos os subdomínios. Isso impede ataques nos quais um invasor rebaixa a conexão de um subdomínio para HTTP e a usa para roubar cookies definidos sem o sinalizador Secure no domínio principal.

Os navegadores vêm com uma lista codificada de domínios que aceitam somente HTTPS, inclusive na primeira visita. Essa lista, mantida em hstspreload.org, inclui milhares de sites importantes.

O pré-carregamento elimina a vulnerabilidade da primeira visita: sem ele, um visitante de primeira viagem poderia ser interceptado antes de receber o cabeçalho HSTS. Os sites pré-carregados aceitam somente HTTPS desde a primeira solicitação, independentemente do estado do cache do HSTS.

A remoção de SSL, publicada por Moxie Marlinspike na Black Hat 2009, é um ataque MITM que rebaixa conexões HTTPS para HTTP. O invasor intercepta a solicitação HTTP inicial do usuário, faz solicitações HTTPS ao servidor real em nome do usuário e encaminha o conteúdo ao usuário por HTTP.

A vítima vê o conteúdo normalmente, mas por HTTP. Todas as credenciais inseridas são enviadas ao invasor. Antes do HSTS, esse ataque era muito eficaz porque os usuários não percebiam a ausência do cadeado.

O HSTS impede a remoção de SSL porque o navegador se recusa a prosseguir com conexões HTTP para domínios inscritos no HSTS. Mesmo que um invasor tente fornecer uma página por HTTP, o navegador simplesmente se recusa a se conectar e exibe um erro.

A aplicação do HSTS pelo navegador ocorre antes de qualquer solicitação de rede, portanto o invasor não consegue interferir. A única vulnerabilidade restante é a primeira visita, antes que o HSTS seja recebido; o pré-carregamento elimina essa vulnerabilidade.

O conteúdo misto ocorre quando uma página HTTPS carrega recursos por HTTP. O conteúdo misto passivo inclui imagens, áudio e vídeo carregados por HTTP. Esses recursos não podem modificar diretamente a página, mas podem revelar informações do usuário por meio dos cabeçalhos HTTP e permitir rastreamento.

O conteúdo misto ativo inclui scripts, folhas de estilo, iframes e XMLHttpRequests carregados por HTTP. Um script HTTP pode comprometer completamente a segurança da página HTTPS, pois tem acesso total ao DOM e pode ler cookies e dados de formulários.

Os navegadores modernos bloqueiam por padrão o conteúdo misto ativo (scripts, folhas de estilo e iframes por HTTP) quando a página que os contém usa HTTPS. Um erro é exibido no console, e o recurso não é carregado.

A partir do Chrome 81 (2020), os navegadores começaram a atualizar automaticamente o conteúdo misto passivo para HTTPS. Se a versão HTTPS existir, ela será carregada. Caso contrário, o recurso será bloqueado.

O console de desenvolvimento do navegador exibe avisos e erros de conteúdo misto. No Chrome, abra o DevTools, acesse a aba Console e filtre por "Conteúdo misto". Cada recurso bloqueado mostra o URL inseguro que precisa ser atualizado.

O painel Security do DevTools mostra uma visão abrangente da segurança: detalhes do certificado, informações da conexão e uma lista de todos os recursos inseguros da página.

A diretiva "upgrade-insecure-requests" da Content Security Policy (CSP) instrui os navegadores a atualizar automaticamente todas as solicitações HTTP da página para HTTPS. Isso permite lidar com conteúdo antigo que contém URLs HTTP codificados diretamente.

Diferentemente do bloqueio de conteúdo misto, upgrade-insecure-requests tenta buscar primeiro a versão HTTPS. Essa diretiva é útil durante a migração de HTTP para HTTPS, quando seria impraticável atualizar todos os URLs incorporados no conteúdo antigo.

Sem HTTPS, os provedores de serviços de internet (ISP) podem injetar conteúdo nas respostas HTTP. Vários provedores já foram flagrados injetando anúncios em páginas que não os tinham, adicionando pixels de rastreamento ou inserindo páginas de aviso quando os usuários se aproximavam do limite de dados.

Essa forma de injeção de conteúdo é impossível em páginas HTTPS porque a resposta é autenticada e criptografada. Qualquer modificação faria a verificação do MAC do TLS falhar, resultando em um erro de conexão, em vez de exibir conteúdo modificado.

Antes de o navegador receber um cabeçalho HSTS para um domínio, a primeira visita por HTTP fica vulnerável. Um invasor pode interceptar essa solicitação inicial e realizar uma remoção de SSL sem disparar avisos do navegador.

Essa vulnerabilidade de "confiança no primeiro uso" explica a existência da lista de pré-carregamento do HSTS. Enviar um site para a lista de pré-carregamento garante que os navegadores imponham HTTPS para esse domínio desde a primeira solicitação, fechando completamente a janela de vulnerabilidade da primeira visita.

O HSTS instrui os navegadores a impor conexões exclusivamente HTTPS para um domínio durante um período especificado. A lista de pré-carregamento amplia a proteção às primeiras visitas ao codificar as políticas de HSTS nos navegadores.

A remoção de SSL (Moxie Marlinspike, 2009) rebaixa HTTPS para HTTP; o HSTS impede esse ataque. O conteúdo misto ativo (scripts HTTP em páginas HTTPS) é bloqueado pelos navegadores. A diretiva upgrade-insecure-requests do CSP automatiza a migração de HTTP para HTTPS em conteúdo antigo.