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

Evite vazamentos de CSRF, XSSI e informações entre origens.

Lukas Weichselbaum

Por que é importante isolar seus recursos da Web?

Muitos aplicativos da Web são vulneráveis a ataques cross-origin, como falsificação de solicitação entre sites (CSRF), inclusão de script entre sites (XSSI), ataques de temporização, vazamentos de informações cross-origin ou ataques de canal lateral de execução especulativa (Spectre).

Os cabeçalhos de solicitação Buscar metadados permitem implantar um mecanismo de defesa em profundidade robusto, uma política de isolamento de recursos, para proteger seu aplicativo contra esses ataques comuns entre origens.

É comum que os recursos expostos por um determinado aplicativo da Web sejam carregados apenas 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

• 76
• 79
• 90
• 16,4

Origem

Contexto

Muitos ataques entre sites são possíveis porque a Web está aberta por padrão e o servidor de aplicativos não pode se proteger facilmente da comunicação originada 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 identificar se a solicitação foi originada em outro domínio (entre sites) e o navegador anexa automaticamente 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 script entre sites (XSSI) ou vazamentos de informações entre origens, têm natureza semelhante ao CSRF e dependem do carregamento de recursos de um aplicativo vítima em um documento controlado pelo invasor e do vazamento de informações sobre os aplicativos da vítima. Como os aplicativos não conseguem distinguir facilmente as solicitações confiáveis das não confiáveis, eles não podem descartar o tráfego malicioso entre sites.

Além dos ataques a recursos, conforme descrito acima, as referências de janela também podem levar a vazamentos de informações entre origens e ataques Spectre. É possível evitá-los definindo o cabeçalho de resposta Cross-Origin-Opener-Policy como same-origin.

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.

Entre sites

As solicitações maliciosas entre sites podem ser rejeitadas pelo servidor devido ao contexto adicional na solicitação HTTP fornecida pelos cabeçalhos Sec-Fetch-*.

Sec-Fetch-Site

Compatibilidade com navegadores

• 76
• 79
• 90
• 16,4

Origem

O 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 do usuário com o user agent (por exemplo, clicar em um marcador)
• cross-site, se a solicitação foi enviada por outro site (por exemplo, evil.example)

Sec-Fetch-Mode

Compatibilidade com navegadores

• 76
• 79
• 90
• 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

• 80
• 80
• 90
• 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 entre origens

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 mitiga vulnerabilidades comuns de sites cruzados, como CSRF, XSSI, ataques de tempo e vazamentos de informações de origem cruzada. 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 o Fetch Metadata

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.

Observação: todos os exemplos a seguir são códigos Python.

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

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

Todas as solicitações que não tiverem origem em um contexto entre origens (como evil.example) serão permitidas. Mais especificamente, 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;
• Originam-se de seus subdomínios.
• São causadas explicitamente pela interação do usuário com o agente do usuário (por exemplo, navegação direta ou clicando em um favorito etc.).

if req['sec-fetch-site'] in ('same-origin', 'same-site', 'none'):
  return True  # Allow this request

Caso seus subdomínios não sejam totalmente confiáveis, torne a política mais rígida bloqueando solicitações de subdomínios removendo o valor same-site.

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

A lógica acima protege os endpoints do seu app de serem usados como recursos por outros sites, mas permite a navegação e a incorporação de nível superior (por exemplo, carregamento em um <iframe>). Para melhorar ainda mais a segurança, use cabeçalhos de Buscar metadados para restringir as navegações entre sites a apenas um conjunto permitido de páginas.

Etapa 4: desativar endpoints destinados a veicular tráfego entre sites (opcional)

Em alguns casos, o app pode fornecer recursos que devem ser carregados em vários sites. Esses recursos precisam ser isentos por caminho ou endpoint. Confira alguns exemplos de 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

Atenção: antes de desativar partes do seu app dessas restrições de segurança, verifique se elas são estáticas e não contêm informações sensíveis do usuário.

Etapa 5: rejeitar todas as outras solicitações que são 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.

Por padrão, as solicitações que violam sua política precisam ser rejeitadas com uma resposta HTTP 403. No entanto, dependendo do seu caso de uso, também é possível considerar outras ações, como: Registrar apenas violações. Isso é muito útil para testar a compatibilidade da política e encontrar endpoints que talvez precisem ser desativados. - Como modificar a solicitação. Em alguns casos, considere realizar outras ações, como redirecionar para a página de destino e descartar credenciais de autenticação (por exemplo, cookies). No entanto, isso pode enfraquecer as proteções de uma política baseada em metadados de busca.

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

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 site e garantir que as restrições não afetem o 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.

Como identificar e corrigir violações da política

Recomendamos que você teste sua política sem efeitos colaterais, ativando-a primeiro no modo de relatórios 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 implementação 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 que a política não afeta o tráfego legítimo de produção, você pode aplicar restrições, garantindo que outros sites não solicitem seus recursos e protegendo seus usuários contra ataques entre sites.

Atenção : rejeite as solicitações inválidas antes de executar verificações de autenticação ou qualquer outro processamento da solicitação para evitar revelar informações sensíveis de tempo.

Leitura adicional

• Especificação de cabeçalhos de solicitação de metadados de busca do W3C
• Playground de metadados de busca
• Palestra do Google I/O: como proteger apps da Web com recursos modernos da plataforma (slides)