Proteja seus recursos contra ataques na Web com a busca de metadados

Evitar CSRF, XSSI e vazamentos de informações de origem cruzada.

Lukas Weichselbaum

Por que é importante isolar seus recursos da Web?

Muitos aplicativos da Web são vulneráveis a ataques de origem cruzada, como falsificação de solicitações entre sites (CSRF, na sigla em inglês), inclusão de script entre sites (XSSI), ataques de tempo, vazamentos de informações entre origens ou ataques de canal lateral de execução especulativa (Spectre).

Os cabeçalhos de solicitação de busca de metadados permitem que você implante um mecanismo robusto de defesa em profundidade, uma política de isolamento de recursos, para proteger seu aplicativo contra esses ataques comuns de origem cruzada.

É comum que os recursos expostos por um determinado aplicativo da Web sejam carregados somente pelo próprio aplicativo, e não por outros sites. Nesses casos, a implantação de uma política de isolamento de recursos com base em cabeçalhos de solicitação de busca de metadados exige pouco esforço e, ao mesmo tempo, protege o aplicativo contra ataques entre sites.

Compatibilidade com navegadores

Os cabeçalhos da solicitação de busca de metadados são compatíveis com todos os mecanismos de navegador modernos.

Compatibilidade com navegadores

  • Chrome: 76.
  • Borda: 79.
  • Firefox: 90.
  • Safari: 16.4.

Origem

Contexto

Muitos ataques entre sites são possíveis porque a Web é aberta por padrão e o servidor de aplicativos não pode se proteger facilmente contra comunicações originadas de aplicativos externos. Um ataque de origem cruzada típico é falsificação de solicitações entre sites (CSRF, na sigla em inglês), em que um invasor atrai um usuário para um site que ele controla e envia um formulário para o servidor no qual o usuário está conectado. Como o servidor não consegue determinar se a solicitação foi originada de outro domínio (entre sites) e o navegador automaticamente anexa cookies a solicitações entre sites, o servidor executa a ação solicitada pelo invasor em nome do usuário.

Outros ataques entre sites, como a inclusão de scripts entre sites (XSSI) ou vazamentos de informações entre origens, têm natureza semelhante ao CSRF e dependem do carregamento de recursos do aplicativo da vítima em um documento controlado pelo invasor e do vazamento de informações sobre os aplicativos das vítimas. Como os aplicativos não conseguem distinguir com facilidade solicitações confiáveis de solicitações não confiáveis, eles não podem descartar o tráfego malicioso entre sites.

Introdução à busca de metadados

Os cabeçalhos de solicitação de busca de metadados são um novo recurso de segurança de plataforma da Web projetado para ajudar os servidores a se defenderem contra ataques de origem cruzada. Ao fornecer informações sobre o contexto de uma solicitação HTTP em um conjunto de cabeçalhos Sec-Fetch-*, eles permitem que o servidor que responda aplique políticas de segurança antes de processar a solicitação. Isso permite que os desenvolvedores decidam se querem aceitar ou rejeitar uma solicitação com base na forma como ela foi feita e no contexto em que ela será usada, possibilitando responder apenas a solicitações legítimas feitas pelo próprio aplicativo.

Mesma origem
As solicitações originadas de sites veiculados pelo seu próprio servidor (mesma origem) vão continuar funcionando. Uma solicitação de busca de https://site.example para o recurso https://site.example/foo.json em JavaScript faz com que o navegador envie o cabeçalho de solicitação HTTP "Sec Fetch-Site: same-origin".
Entre sites
Solicitações maliciosas entre sites podem ser rejeitadas pelo servidor devido ao contexto adicional na solicitação HTTP fornecida pelos cabeçalhos Sec-Fetch-*. Uma imagem em https://evil.example que definiu o atributo src de um elemento img como "https://site.example/foo.json" faz com que o navegador envie o cabeçalho de solicitação HTTP "Sec-Fetch-Site: cross-site".

Sec-Fetch-Site

Compatibilidade com navegadores

  • Chrome: 76.
  • Borda: 79.
  • Firefox: 90.
  • Safari: 16.4.

Origem

Sec-Fetch-Site informa ao servidor qual site enviou a solicitação. O navegador define esse valor como um dos seguintes:

  • same-origin, se a solicitação foi feita pelo seu próprio aplicativo (por exemplo, site.example)
  • same-site, se a solicitação tiver sido feita por um subdomínio do seu site (por exemplo, bar.site.example).
  • none, se a solicitação foi causada explicitamente pela interação de um usuário com o user agent (por exemplo, clicando em um favorito)
  • cross-site, se a solicitação foi enviada por outro site (por exemplo, evil.example)

Sec-Fetch-Mode

Compatibilidade com navegadores

  • Chrome: 76.
  • Borda: 79.
  • Firefox: 90.
  • Safari: 16.4.

Origem

Sec-Fetch-Mode indica o modo da solicitação. Isso corresponde aproximadamente ao tipo da solicitação e permite distinguir as cargas de recursos das solicitações de navegação. Por exemplo, um destino de navigate indica uma solicitação de navegação de nível superior, enquanto no-cors indica solicitações de recursos, como o carregamento de uma imagem.

Sec-Fetch-Dest

Compatibilidade com navegadores

  • Chrome: 80.
  • Borda: 80.
  • Firefox: 90.
  • Safari: 16.4.

Origem

Sec-Fetch-Dest expõe o destino de uma solicitação, por exemplo, se uma tag script ou img fez com que um recurso fosse solicitado pelo navegador.

Como usar o Fetch Metadata para se proteger contra ataques de origem cruzada

As informações extras fornecidas por esses cabeçalhos de solicitação são bem simples, mas o contexto extra permite que você crie uma lógica de segurança avançada no lado do servidor, também conhecida como política de isolamento de recursos, com apenas algumas linhas de código.

Como implementar uma política de isolamento de recursos

Uma política de isolamento de recursos impede que seus recursos sejam solicitados por sites externos. O bloqueio desse tráfego atenua as vulnerabilidades comuns da Web entre sites, como CSRF, XSSI, ataques de temporização e vazamentos de informações entre origens. Esta política pode ser ativada para todos os endpoints do seu aplicativo e vai permitir todas as solicitações de recursos provenientes do seu próprio aplicativo, bem como navegações diretas (por uma solicitação HTTP GET). Os endpoints que deveriam ser carregados em um contexto entre sites (por exemplo, endpoints carregados usando o CORS) podem não ser incluídos nessa lógica.

Etapa 1: permitir solicitações de navegadores que não enviam metadados de busca

Nem todos os navegadores oferecem suporte à busca de metadados. Por isso, você precisa permitir solicitações que não definam cabeçalhos Sec-Fetch-* verificando a presença de sec-fetch-site.

if not req['sec-fetch-site']:
  return True  # Allow this request

Etapa 2: permitir solicitações iniciadas pelo mesmo site e pelo navegador

Todas as solicitações que não se originam de um contexto de origem cruzada (como evil.example) serão permitidas. Especificamente, essas são solicitações que:

  • vindo do seu próprio aplicativo. Por exemplo, uma solicitação de mesma origem em que site.example solicita site.example/foo.json sempre será permitida;
  • se originam dos seus subdomínios;
  • São explicitamente causados pela interação de um usuário com o user agent (por exemplo, navegação direta ou clique em um favorito etc.).
if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
  return True  # Allow this request

Etapa 3: permitir a navegação simples de nível superior e o uso de iframes

Para garantir que seu site ainda possa ser vinculado a outros sites, permita uma navegação simples (HTTP GET) de nível superior.

if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
  # <object> and <embed> send navigation requests, which we disallow.
  and req['sec-fetch-dest'] not in ('object', 'embed'):
    return True  # Allow this request

Etapa 4: desative os endpoints destinados à veiculação de tráfego entre sites (opcional)

Em alguns casos, o aplicativo pode fornecer recursos que precisam ser carregados entre sites. Esses recursos precisam ser isentos por caminho ou endpoint. Confira alguns exemplos desses endpoints:

  • Endpoints que precisam ser acessados em origens diferentes: se o aplicativo estiver veiculando endpoints com o CORS ativado, será necessário desativá-los explicitamente do isolamento de recursos para garantir que as solicitações entre sites para esses endpoints ainda sejam possíveis.
  • Recursos públicos (por exemplo, imagens, estilos etc.): Os recursos públicos e não autenticados que precisam ser de origem cruzada carregáveis de outros sites também podem ser isentos.
if req.path in ('/my_CORS_endpoint', '/favicon.png'):
  return True

Etapa 5: rejeitar todas as outras solicitações entre sites e não de navegação

Qualquer outra solicitação entre sites será rejeitada por esta política de isolamento de recursos e, assim, protegerá seu aplicativo contra ataques comuns entre sites.

Exemplo:o código a seguir demonstra a implementação completa de uma política de isolamento de recursos robusta no servidor ou como um middleware para negar solicitações de recursos potencialmente maliciosas entre sites, permitindo solicitações de navegação simples:

# Reject cross-origin requests to protect from CSRF, XSSI, and other bugs
def allow_request(req):
  # Allow requests from browsers which don't send Fetch Metadata
  if not req['sec-fetch-site']:
    return True

  # Allow same-site and browser-initiated requests
  if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
    return True

  # Allow simple top-level navigations except <object> and <embed>
  if req['sec-fetch-mode'] == 'navigate' and req.method == 'GET'
    and req['sec-fetch-dest'] not in ('object', 'embed'):
      return True

  # [OPTIONAL] Exempt paths/endpoints meant to be served cross-origin.
  if req.path in ('/my_CORS_endpoint', '/favicon.png'):
    return True

  # Reject all other requests that are cross-site and not navigational
  return False

Como implantar uma política de isolamento de recursos

  1. Instale um módulo como o snippet de código acima para registrar e monitorar o comportamento do seu site e garantir que as restrições não afetem nenhum tráfego legítimo.
  2. Corrija possíveis violações isentando endpoints legítimos de origem cruzada.
  3. Aplique a política descartando solicitações que não estejam em conformidade.

Identificar e corrigir violações de políticas

É recomendável testar a política sem efeitos colaterais. Para isso, ative-a primeiro no modo de relatório no código do lado do servidor. Como alternativa, é possível implementar essa lógica no middleware ou em um proxy reverso, que registra todas as violações que sua política pode produzir quando aplicada ao tráfego de produção.

De acordo com nossa experiência de lançamento de uma política de isolamento de recursos de metadados de busca no Google, a maioria dos aplicativos é compatível por padrão com essa política e raramente exige a isenção de endpoints para permitir o tráfego entre sites.

Como aplicar uma política de isolamento de recursos

Depois de verificar se a política não afeta o tráfego de produção legítimo, você já pode aplicar restrições, garantindo que outros sites não poderão solicitar seus recursos e protegendo os usuários contra ataques entre sites.

Leitura adicional