Luan Herrera

Este artigo tem como objetivo introduzir o conceito de XSLeaks e explicar alguns dos ataques mais comuns dessa nova classe de vulnerabilidades web, além de trazer exemplos concretos de problemas que foram achadas no mundo real. O que é a same-origin policy? Antes de introduzir o conceito de XSLeaks, é necessário primeiro entender o que é a same-origin policy e seu objetivo. Ela é uma das principais políticas de segurança da web e restringe como documentos e scripts carregados por uma origem podem interagir com recursos de outras origens. A same-origin policy determina que apenas sites que possuem a mesma origem (<scheme> :// <hostname> [ : <port> ]) podem ler um ao outro, e que sites de origens diferentes são impedidos de fazer o mesmo. Um site malicioso, por exemplo, é impedido de ler a resposta do site bancário de outros usuários, já que a origem do site do atacante é diferente do site do banco. A imagem abaixo (em inglês) ajuda a ilustrar o exemplo descrito acima. É importante notar que apesar de não ser possível ler a resposta de sites de origens diferentes, ainda assim é possível fazer uma requisição. É por esse mesmo motivo que ataques como Cross-site request forgery (CSRF) existem, já que o atacante não está preocupado em ler a resposta, e sim, em realizar uma mudança de estado em uma aplicação de outra origem. O que são os XSLeaks? Cross-site leaks (XSLeaks) é uma classe de vulnerabilidades relativamente nova que utilizam os diversos canais laterais (side-channels) existentes na web para vazar informações de outras origens sem infringir na same-origin policy. Ataques que miram tais vulnerabilidades abusam da habilidade limitada que origens diferentes tem de interagir umas com as outras, em conjunto com as diversas funcionalidades implementadas pelos navegadores (navegações, requisições, enviar mensagens, APIs específicas) para inferir dados dos usuários através das informações que acabam sendo expostas por essas funcionalidades. Os dados vazados durante os ataques de XSLeaks são bastante variados e dependem do tipo da aplicação. Alguns dos mais comuns são: 1. Estado do usuário (logado, deslogado). 2. Vazamento da identidade do usuário. 3. Vazamento do resultado de pesquisas na aplicação. Tipos de ataques Ataques de tempo Os ataques de tempo foram um dos primeiros ataques de canal lateral na web a serem explorados e datam mais de 13 anos (https://scarybeastsecurity.blogspot.com/2009/12/cross-domain-search-timing.html). A ideia é relativamente simples: uma página maliciosa faz requisições para páginas de outras origens e mede o tempo que cada requisição demora para concluir. Requisições com respostas maiores demoram mais tempo para concluir do que respostas menores. Com isso, um atacante pode inferir informações sobre o estado da página — por exemplo, se um atacante realizasse o ataque em uma aplicação que quando o usuário está logado na sua conta a resposta é maior que quando ele não está, ele seria capaz de vazar essa informação apenas medindo a variação de tempo que as requisições demoram para concluir e comparando-as. Um problema bastante comum nos ataques de tempo é sua sensibilidade à instabilidade da rede, o que resulta na necessidade de um grande número de requisições e medições para que se tenha certeza estatística da estimativa do tamanho das respostas. Contagem de iframes Existem alguns atributos de janelas que são expostos para páginas de outras origens e, apesar de serem poucos, um deles em especial pode ser utilizado como oráculo para inferir informações. Por exemplo, o atributo length serve para medir a quantidade de iframes em uma janela e pode ser acessado através de uma referência para uma janela ou iframe. Esse ataque é útil em páginas que possuem iframes e o que pode ser inferido vai depender de cada aplicação. Eventos de erro Toda vez que uma requisição é feita, o servidor a processa e determina qual é o status code (https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status) da resposta que será enviada. O navegador permite que qualquer página infira o valor do status code (de forma limitada) através de diversas formas. Uma delas é através dos eventos load e error. Se uma requisição é carregada dentro de uma tag script, por exemplo, e o status code da resposta retornada está na faixa de 2xx, o evento de load será emitido. Já se a resposta estiver na faixa de 4xx, o evento de error será emitido. Um exemplo clássico desse ataque é deduzir se o usuário está logado ou não em uma aplicação — na maioria das vezes a aplicação retorna o status code 401 ou 404 se uma rota é acessada sem o usuário estar autenticado e retorna o status code 200 quando o usuário está autenticado. Utilizando esse ataque seria possível vazar essa informação. Sondagem do cache A ideia por trás da sondagem do cache se resume em detectar se um recurso de outra origem foi cacheado pelo browser ou não. Antigamente os ataques elaborados consistiam em vazar o histórico de navegação das vítimas checando se imagens de sites populares estavam armazenadas no cache do usuário (o que indicava que o usuário já havia acessado aquele site), mas com a evolução de pesquisa sobre esse tipo de ataque e com a descoberta da técnica de expulsão do cache (http://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html), os ataques se tornaram mais severos. O ataque é realizado medindo o tempo que uma requisição demora para concluir — se a resposta vier do cache o tempo será muito pequeno. Se vier da rede, será maior. Exemplos de ataques no mundo real No artigo Facebook exploit – Confirm website visitor identities, o pesquisador utilizou a técnica de escutar os eventos de erro para vazar a identidade do usuário que estava acessando a página maliciosa. Já no artigo XS-Searching Google’s bug tracker to find out vulnerable source code o pesquisador utilizou uma variação do ataque de tempo (utilizando a Cache API) para medir o tempo que as respostas demoravam para serem adicionadas no cache e assim vazar informações sobre relatórios privados do issue tracker do Google. Em Patched Facebook Vulnerability Could Have Exposed Private Information About You and Your Friends o pesquisador utilizou a técnica de contagem de frames para vazar informações pessoais da conta do Facebook do usuário. No artigo Mass XS-Search using Cache Attack o pesquisador utilizou a sondagem do cache para vazar informações de diversos serviços do Google, incluindo o histórico de pesquisa do usuário, vídeos assistidos, notas privadas, etc. No artigo Google Books X-Hacking, o pesquisador utilizou a técnica de contagem de frames (com a ajuda do XSS Auditor) para vazar os livros que o usuário havia pesquisado, coleções privadas, livros comprados e livros lidos. Para saber mais: https://xsleaks.dev https://github.com/xsleaks/xsleaks https://portswigger.net/daily-swig/xs-leak