Vazamentos XS: o que são e como evitá-los
17 de julho de 2023
0 minutos de leituraVazamentos entre sites (XS leaks) são uma categoria de vulnerabilidade de segurança na web que permite que hackers obtenham informações confidenciais da sessão de navegação de uma pessoa em outros sites ou aplicativos web. Aplicações web modernas compartilham dados por meio de vários recursos e APIs — uma funcionalidade que pode ser explorada por invasores para acessar esses dados.
Em última análise, os vazamentos XS expõem informações confidenciais que podem ser usadas por agentes mal-intencionados para diversos fins ilícitos, como obter acesso não autorizado a sistemas ou bancos de dados sigilosos.
Neste artigo, vamos explicar melhor o que são vazamentos XS e como eles acontecem. Em seguida, veremos exemplos práticos de como evitá-los.
Como acontecem os vazamentos XS
As aplicações web modernas são extremamente complexas e abrangem vários domínios com diferentes níveis de confiança. Por isso, para oferecer uma experiência de navegação integrada, os sites precisam compartilhar informações. Embora os desenvolvedores tenham tornado essa comunicação relativamente segura, os recursos dos sites e dos navegadores apresentam vulnerabilidades inerentes.
Os vazamentos XS acontecem quando invasores exploram essas vulnerabilidades para obter acesso não autorizado a dados privados de usuários. Ao manipular vários recursos da web — como cookies, APIs JavaScript, folhas de estilo CSS e elementos HTML — e aproveitar canais laterais e vulnerabilidades específicas de aplicações, invasores podem extrair informações confidenciais de outros sites que a pessoa acessa. Além disso, esses ataques acontecem silenciosamente, sem que a pessoa saiba ou dê consentimento.
Quais são os tipos de vazamento XS?
Há vários tipos de vazamento XS que podem ser usados por invasores. Vamos conhecer alguns deles.
Ataques de temporização
Em um ataque de temporização, um agente mal-intencionado tenta coletar informações confidenciais do sistema medindo o tempo necessário para executar diferentes ações. O hacker envia scripts especialmente elaborados ao site-alvo para fazer chamadas de API, solicitações AJAX ou tentar acionar solicitações de recursos que exigem compartilhamento de recursos entre origens (CORS). Em seguida, analisa a duração desses processos para deduzir como o site funciona ou trata os dados.
Por exemplo, um invasor pode observar quanto tempo a validação no servidor leva ao enviar diferentes tipos de entrada — como combinações de nome de usuário e senha — por solicitações entre origens. Depois, pode usar diferenças perceptíveis no tempo para avaliar se uma tentativa de login foi bem-sucedida ou descobrir se uma pessoa é administradora ou usuária comum. Essas informações orientam os próximos passos do invasor.
Contagem de frames
Em ataques de contagem de frames, o hacker cria vários iFrames aninhados que apontam para diferentes URLs de um site-alvo. Em seguida, aproveita a funcionalidade CORS do site para verificar quantos frames o navegador da pessoa carrega ao visitar essas URLs.
Imagine um invasor que cria vários iFrames aninhados para áreas protegidas de um site, como as páginas de configurações da conta e do histórico de pedidos. Quando alguém acessa uma página que contém os iFrames injetados pelo invasor, ele conta quantos frames carregaram e quantos não carregaram. Com essas informações, pode deduzir as restrições da conta — como requisitos de autenticação ou níveis de associação — e descobrir se uma pessoa específica tem privilégios de acesso ou já interagiu com determinadas áreas do site-alvo.
Sondagem de cache
A sondagem de cache explora os caches do navegador, que armazenam conteúdo da web localmente nos dispositivos dos usuários. Para executar esse ataque, o hacker cria um site malicioso que solicita recursos específicos — como imagens ou scripts — do site-alvo. Os recursos solicitados têm características distintas, como tamanhos de arquivo ou tempos de carregamento incomuns.
Os invasores medem a rapidez com que os recursos carregam quando alguém visita o site malicioso, seja diretamente do servidor-alvo, seja de versões em cache no navegador da pessoa. Depois, o agente mal-intencionado usa essas informações para deduzir se os recursos já estavam no cache local do navegador.
Assim como a contagem de frames, as informações obtidas por meio da sondagem de cache podem orientar a personalização de campanhas de phishing, revelar relações entre contas separadas usadas em vários serviços e plataformas online e ser usadas para coordenar ataques mais sofisticados.
Quais são os mecanismos por trás dos vazamentos XS?
Os ataques de vazamento XS manipulam funcionalidades inerentes dos navegadores e usam técnicas de observação indireta para obter acesso não autorizado a dados confidenciais. Entre os mecanismos que contribuem para o sucesso de um ataque de vazamento XS estão:
Exploração de recursos do navegador — Os invasores usam funcionalidades do navegador, como pré-busca, pré-renderização e várias APIs, como Fetch ou WebSockets. Eles podem extrair informações confidenciais de usuários sem violar diretamente a Política de Mesma Origem (SOP), manipulando ou combinando esses recursos com outras técnicas, como a sondagem de cache.
Canais laterais — São caminhos indiretos pelos quais os invasores coletam informações confidenciais. Em vez de acessar os dados diretamente, eles observam variações em fatores como o tempo de renderização ou os padrões de carregamento de recursos nos navegadores dos usuários, devido às restrições de segurança impostas pelas políticas SOP nas aplicações web.
Comunicação entre origens — Os invasores também podem ter como alvo métodos de comunicação entre origens, como a API postMessage e os web workers. Assim, podem interceptar ou manipular mensagens entre diferentes origens incorporadas em iFrames na mesma página.
Vulnerabilidades exploradas por vazamentos XS
Usando os mecanismos descritos acima, os invasores podem acessar informações confidenciais sem violar diretamente políticas de segurança como CORS e SOP, adotadas pela maioria dos sites modernos.
Essas medidas não impedem a ocorrência de vazamentos XS. Os invasores podem usar canais laterais para contornar as proteções da SOP, aproveitar configurações incorretas de CORS e combinar outras vulnerabilidades em um ataque mais coordenado.
CORS e SOP controlam como recursos de diferentes origens interagem. A SOP impede que páginas da web acessem dados ou conteúdo carregados de outro domínio, garantindo que os scripts sejam executados no contexto da própria origem. O CORS amplia essa política ao permitir solicitações específicas entre origens, quando o servidor autoriza explicitamente o acesso aos recursos por meio de cabeçalhos HTTP. Em teoria, essa combinação permite uma comunicação segura entre sites e impede interações maliciosas entre domínios, como ataques de falsificação de solicitação entre sites (CSRF) e acesso não autorizado a dados.
No entanto, como os vazamentos XS exploram canais laterais e a exposição indireta de dados, os invasores podem contornar a SOP ao deduzir informações confidenciais de outra origem. Da mesma forma, uma configuração incorreta ou uma implementação insegura de CORS em uma aplicação web pode levar ao vazamento de informações.
Outra forma de executar técnicas de vazamento XS é combinar a exploração de vulnerabilidades. O cross-site scripting (XSS) funciona bem em conjunto com vazamentos XS. Depois de explorar uma vulnerabilidade XSS, o invasor também pode tentar provocar vazamentos XS por meio de vários recursos ou APIs do navegador que expõem informações por canais laterais.
Um agente mal-intencionado pode combinar esses dois vetores de ataque para obter dados confidenciais do domínio comprometido e coletar informações adicionais entre origens sem violar diretamente a SOP.
Quais são as consequências dos vazamentos XS?
Os ataques de vazamento XS podem ter consequências graves, como a exposição de informações confidenciais, quando o invasor obtém acesso a dados sigilosos, incluindo informações pessoais ou financeiras. Depois, pode manipular, roubar ou usar indevidamente as informações privadas de uma pessoa sem consentimento.
O sequestro de sessão também pode ser uma consequência de ataques de vazamento XS. Isso acontece quando um invasor assume o controle de uma sessão ativa de uma pessoa e pode fazer alterações não autorizadas em seu nome. Essas consequências colocam em risco a privacidade e a segurança das pessoas e prejudicam a confiança em plataformas e serviços online.
É importante observar que os vazamentos XS costumam ser considerados parte de técnicas de ataque ou vulnerabilidades mais amplas. Vazamentos de dados de grande repercussão, que ganham destaque na mídia, podem não ter os vazamentos XS como principal vetor de ataque. Ainda assim, invasores podem usar vazamentos XS para realizar ataques mais coordenados.
Boas práticas para reduzir o risco de ataques de vazamento XS
Não existe uma solução única para evitar vazamentos XS, mas é possível reduzir significativamente os riscos associados. Nas próximas seções, apresentamos boas práticas para reduzir esses vazamentos, com demonstrações práticas de como implementá-las.
Use uma Política de Segurança de Conteúdo
Implemente uma Política de Segurança de Conteúdo (CSP) robusta para limitar as fontes de conteúdo que o navegador pode carregar nos seus sites. Essa prática reduz possíveis vazamentos de informações causados por invasores que exploram XSS ou outras vulnerabilidades baseadas em injeção.
Você pode implementar a CSP usando um cabeçalho de resposta HTTP chamado Content-Security-Policy, como mostrado abaixo:
Neste exemplo, nenhum recurso externo pode ser carregado (default-src), a menos que outras diretivas o especifiquem explicitamente. Só podemos carregar scripts (script-src), imagens (img-src), folhas de estilo (style-src) e fontes (font-src) do nosso domínio (self) ou da API do Google (googleapis.com).
Uma CSP bem definida ajuda a impedir solicitações não autorizadas entre origens e a execução de código embutido, especificando as fontes permitidas para conteúdo como scripts, imagens, folhas de estilo e outros.
Defina o atributo SameSite para os cookies
O atributo SameSite de um cookie informa ao navegador se ele deve incluir o cookie em solicitações externas. Em JavaScript, por exemplo, ele aparece assim:
O cookie username contém JohnDoe como valor, e o caminho / significa que o cookie estará disponível em todas as páginas do nosso domínio. A palavra-chave Secure garante que o cookie seja transmitido apenas por conexões HTTPS. Por fim, definimos o atributo SameSite como:
None— O cookie será anexado se for enviado por um canal HTTPS seguro.Lax— Esse é o comportamento padrão dos navegadores baseados no Chromium. O cookie será enviado em solicitaçõesGETfeitas durante uma navegação de nível superior,Strict— O cookie nunca será enviado para fora do nosso domínio.
Definir o atributo SameSite dos cookies como Strict impede o envio deles em solicitações entre sites e reduz o risco de ataques CSRF e de alguns ataques de vazamento XS, como os que envolvem medições de tempo.
Reduza o uso de dados confidenciais em URLs
Reduzir o uso de dados confidenciais em URLs é uma prática essencial de cibersegurança. Dados confidenciais, como credenciais de usuário ou informações de identificação pessoal (PII), nunca devem ser incluídos em URLs, pois invasores podem acessá-los facilmente pelo histórico do navegador, pelos registros do servidor, pelos cabeçalhos de referência e por links compartilhados sem sanitização.
Veja algumas formas de reduzir o uso de dados confidenciais:
Usar solicitações
POSTcom HTTPS em vez de incluir dados confidenciais em URLsUsar tokens de sessão em vez de transmitir diretamente credenciais de usuário ou PII
Implemente a limitação de taxa
Outra boa prática é aplicar a limitação de taxa em endpoints confidenciais, especialmente naqueles vulneráveis a tentativas de enumeração ou força bruta. Essa estratégia limita o número de solicitações que um invasor pode fazer em determinado período e reduz a eficácia dos ataques de vazamento XS. Há bibliotecas ou soluções de middleware para implementar a limitação de taxa em várias linguagens de programação e frameworks web.
No Node.js com Express, por exemplo, você precisa instalar o middleware express-rate-limit com o comando npm install express-rate-limit. Depois, você pode configurar o limitador de requisições no servidor da seguinte forma:
Essa medida é mais eficaz quando combinada com outras. Ela reforça a segurança da sua aplicação contra ataques de vazamento XS que dependem de várias requisições ao servidor para coletar informações.
Configure o CORS corretamente
Configure o CORS corretamente na sua aplicação para impedir que domínios não autorizados façam requisições de origem cruzada e acessem recursos protegidos. Configure os cabeçalhos CORS, como Access-Control-Allow-Origin, de forma adequada para permitir que apenas origens confiáveis façam requisições de origem cruzada, sem usar curingas desnecessários (*) na lista de origens permitidas.
Se um servidor permite qualquer origem (*) no cabeçalho Access-Control-Allow-Origin ou usa origens geradas dinamicamente sem validar corretamente os dados fornecidos pelo usuário (como um referenciador), os invasores podem explorar essa configuração fazendo requisições de origem cruzada a partir de sites maliciosos.
Use integrações como Snyk Code
Snyk Code ajuda você a identificar e corrigir vulnerabilidades de segurança ao se integrar ao seu fluxo de desenvolvimento. Ele verifica dependências, alerta sobre vulnerabilidades, sugere e aplica correções e monitora continuamente seu projeto em busca de problemas de segurança. Por exemplo, ao criar uma aplicação com Node.js e Express.js, Snyk Code pode ajudar a proteger contra vulnerabilidades causadas pela ausência de cabeçalhos de segurança com um processo simples:
Verifique as dependências — Depois de integrar o Snyk ao seu projeto, você pode verificar as dependências e procurar vulnerabilidades conhecidas nos pacotes.
Identifique o problema — Se faltarem cabeçalhos de segurança, Snyk Code detectará a vulnerabilidade e alertará você. Por exemplo, o Snyk pode identificar que falta o cabeçalho CSP na sua aplicação, que ajuda a proteger contra ataques XSS.
Sugira uma correção — O Snyk recomendará uma correção para a vulnerabilidade identificada. No caso de cabeçalhos de segurança ausentes, pode sugerir a adição do middleware helmet à sua aplicação Express.js. O Helmet é um pacote popular que ajuda a configurar vários cabeçalhos de segurança para sua aplicação por padrão.
O Snyk também pode continuar monitorando seu projeto em busca de novas vulnerabilidades ou atualizações das já existentes. Você receberá alertas se surgirem outros problemas, para acompanhar continuamente a segurança do seu projeto.
Como controlar vazamentos XS
Os vazamentos XS permitem que invasores obtenham informações confidenciais da sessão de navegação de uma pessoa em outro site. Hackers exploram recursos do navegador, canais laterais e comunicações entre origens. Algumas técnicas comuns de vazamento XS incluem ataques de temporização, contagem de frames e sondagem de cache.
Não existe um método garantido para evitar vazamentos XS, mas seguir as práticas recomendadas neste artigo pode reduzir significativamente os riscos e proteger informações confidenciais dos usuários contra acesso ou divulgação não autorizados.
Comece a jogar Capture the Flag
Aprenda a resolver desafios de Capture the Flag assistindo à gravação sob demanda do nosso workshop virtual introdutório.
