1. Introdução
Historicamente, o Cross-Site Script Inclusion (XSSi) nomeia uma vulnerabilidade frequentemente esquecida para aqueles que buscam o desenvolvimento seguro de aplicações, sendo, muitas vezes, completamente desconhecida.
Essa mesma sensação de esquecimento também permeia o meio científico da cibersegurança, que hoje vem de um hiato no desenvolvimento de pesquisas relevantes a respeito do tema. Como consequência, o material disponível online, acerca de XSSi, frequentemente não corresponde com a realidade prática, por uma questão de mudança em mecanismos cruciais, bases para a vulnerabilidade. Além disso, materiais de consulta para aqueles que buscam entender e testar a vulnerabilidade, frequentemente utilizados como “cheat sheet”, também sofrem de desatualização.
Por consequência, ao se analisar todo um universo de materiais sobre XSSi disponíveis, tem-se a sensação de que “pararam no tempo”. Portanto, surge a necessidade de um estudo aprofundado a respeito da atual situação e prevalência da vulnerabilidade nos dias de hoje.
A condução deste trabalho de pesquisa teve por finalidade explorar técnicas já conhecidas e documentadas por pesquisadores anteriores, porém, no contexto dos navegadores atuais, entendendo o funcionamento atual dos mecanismos de inclusão de recursos. Além disso, buscou-se extrapolar os trabalhos já realizados, explorando propostas de cenários práticos e jogando luz em discussões a respeito do impacto de inclusões de recursos distintos, ainda pouco discutidos por outros pesquisadores.
2. Definindo XSSi
Podemos definir XSSi não apenas como uma vulnerabilidade, mas, sim, como sendo toda uma classe de vulnerabilidades que partem do abuso de mecanismos similares. Em resumo, podemos definir essas vulnerabilidades como uma inclusão de recursos inicialmente projetados para não serem incluídos no contexto de uma página de origem em um domínio pertencente a um agente malicioso. O vetor de ataque consiste no acesso, por parte do usuário, em uma página maliciosa que, de maneira implícita, realiza requisição para um domínio legítimo para a inclusão destes recursos, abusando de uma sessão pré-existente com a anexação de cookies de sessão pertencentes ao usuário. A vulnerabilidade ocorre localmente no contexto do navegador do usuário alvo. Para o acesso do atacante aos dados, é necessário manipulação através do JavaScript.
2.1. Política de mesma origem
Um dos mecanismos críticos para a segurança web no contexto dos navegadores é a política de mesma origem, tendo por objetivo gerar isolamento entre páginas oriundas de origens distintas, como contextos isolados, evitando interação e violação da privacidade entre os recursos pertencentes a cada contexto.
A definição de uma origem se dá pelo seguinte: protocolo, domínio e porta. Todos os três devem ser iguais para se considerar uma mesma origem. Por exemplo: https://sidechannel.blog:443 é a mesma origem de https://sidechannel.blog:443/en, pois, em ambos os casos, o protocolo, domínio e porta são os mesmos. Caso tivesse, por exemplo, http://sidechannel.blog:80, seria considerada de origem distinta, afinal o protocolo e a porta não são os mesmos.
Na prática, podemos ver, de maneira simples, a política em ação. Em uma página, iremos abrir uma outra, pertencente a uma mesma origem, como uma variável, e tentar acessar o seu conteúdo. Note que é possível:
Ao realizar a mesma ação, porém abrindo uma página de origem distinta, não é possível:
Apesar de sua importância, a política de mesma origem possui algumas exceções, por exemplo:
Hiperlinks: a navegação através do clique em links é algo comum e é um exemplo pra essa exceção, a qual consiste na referenciação e redirecionamento entre páginas.
Scripts: scripts externos podem ser incluídos, sendo que não se limita ao JavaScript. Outros recursos podem ser tratados como scripts pelo navegador, sendo um exemplo alguns casos de JSON (JavaScript Object Notation).
Mídias: imagens são um exemplo de mídias que podem ser incluídas como uma exceção para a política de mesma origem.
Forms: uma página pode realizar uma requisição do tipo POST para outra. Essa exceção é a base para a vulnerabilidade Cross-Site Request Forgery (CSRF).
2.2. SameSite Cookie
Um dos mecanismos comumente utilizados para identificação de uma sessão de usuário são os cookies, sendo estes definidos pelo desenvolvedor da aplicação web e armazenados localmente no navegador do usuário. Ao se definir um cookie, atributos também podem ser definidos, sendo o “SameSite” um desses, o qual responsável por definir o comportamento do navegador em relação ao cookie ao tratar de requisições de origem cruzada.
O atributo foi implementado, no primeiro navegador popular, no dia 25 de maio de 2016, com o lançamento da versão “51” do Google Chrome, sendo hoje suportado por todos os navegadores de maior popularidade. Surgiu como uma necessidade como mecanismo de prevenção a ataques de Cross-Site Request Forgery (CSRF), porém, refletindo também na Cross-Site Script Inclusion (XSSi), uma vez que ambas partem da necessidade de requisições de origem cruzada.
O atributo pode receber os seguintes valores:
Strict: o cookie somente é enviado em requisições para uma mesma origem.
Lax: na data de publicação deste artigo, este é o valor padrão quando não é explicitamente declarado pela aplicação. É enviado em requisições cruzadas só quando oriundo de navegação de um site a outro. Por exemplo, ao se clicar em um link.
None: o cookie será enviado em todas as requisições, sem restrições de origem. O cookie deverá ser definido com o atributo Secure=true.
3. Trabalhos anteriores
Anteriormente, outros pesquisadores exploraram o tema, servindo de alicerce para o desenvolvimento deste. Vejamos quais são os pesquisadores e o resultado das pesquisas de cada um deles.
3.1. Jeremiah Grossman
Em 2016, Jeremiah Grossman publicou em seu blog a descrição de um ataque contra o Gmail, sendo possível o comprometimento da lista de contatos de um usuário, armazenada em um vetor JSON (JavaScript Object Notation), gerado dinamicamente.
O ataque descrito consistia no acesso pela vítima de um link malicioso, contendo uma solicitação de inclusão deste JSON armazenado sob domínio do Gmail, sendo utilizado cookies de sessão, permitindo, portanto, a inclusão deste JSON contendo dados do usuário no contexto da página maliciosa.
Apesar de descrever pela primeira vez uma vulnerabilidade XSSi, Grossman não criou o nome ou a classe de vulnerabilidades, sendo esses fatos atribuídos a Cristoph Kern em 2007, com a publicação de seu livro “Foundations of Security What Every Programmer Needs to Know”.
3.2. Takeshi Terada
Em 2015, Takeshi Terada publicou seu trabalho demonstrando que arquivos CSV (Comma-Separated Values) também eram passíveis de exploração via XSSi, sendo inovador ao demonstrar um alvo que não era tratado como script pelo navegador, definindo o conceito de “Non-Script-XSSi”.
3.3. Sebastian Lekies
Sebastian Lekies foi um dos pesquisadores responsáveis por publicação de pesquisa, no ano de 2015, sendo interessante tanto para o estudo da vulnerabilidade quanto do contexto de exploração no período do estudo. Foi uma publicação direcionada para o estudo de código JavaScript gerado, dinamicamente, de acordo com as informações de um usuário previamente identificado pelos cookies de sessão.
Foi feito um estudo empírico, consistindo na análise do Alexa Top 150 sites, tendo apenas como pré-requisito a possibilidade de cadastro pelos pesquisadores. Após isso, conduziu-se uma busca por código JavaScript dinâmico, seguido de investigação da possibilidade de vulnerabilidade por XSSi. Além do artigo, outro material disponível sobre a pesquisa é a palestra conduzida por Lekies para a Black Hat, em 2016, sendo apresentado também a seguinte tabela com os resultados da pesquisa:
Outro dado interessante, contido na pesquisa, consiste no estudo do caso de alvos contendo scripts dinâmicos, porém não explorados. Foi atribuído esse fato a dois casos: arquivos no qual o caminho também era gerado dinamicamente e, portanto, imprevisíveis, ou quando existia a checagem de origem da requisição para inclusão daquele recurso.
4. Testes
Para estudo da XSSi e sua aplicação nos dias atuais, objetivo deste trabalho, foram conduzidos testes empíricos. Para isso, foram configuradas duas máquinas armazenadas em nuvem e disponíveis via internet.
A primeira consiste em uma aplicação web propositalmente vulnerável. A aplicação conta com uma página de login que gera um cookie com os seguintes atributos: SameSite=none e Secure=true. A aplicação possui uma área autenticada contando com os seguintes arquivos: um arquivo JSONP (JSON with padding), um arquivo JavaScript e uma imagem.
A segunda consiste em uma aplicação web simulando uma página maliciosa. Para cada caso contido na aplicação vulnerável, há um cenário de exploração via XSSi. Para ambas as máquinas o sistema operacional utilizado foi o Debian 6.1.76-1 e o servidor web foi o Apache 2.4.57. Para simular a máquina do usuário, foi utilizado o sistema operacional Windows 11 Enterprise Evaluation 22H2. Os navegadores utilizados foram sempre na configuração padrão após a instalação.
4.1. Navegador Firefox
Em um primeiro momento, notou-se que o navegador Firefox, quando em versões mais antigas permitia a ocorrência da vulnerabilidade, algo que já não ocorria em versões mais recentes do mesmo. Portanto, buscou-se definir a partir de qual versão esse comportamento mudou, como mudou e por que mudou.
Com a testagem de versões aleatórias, descobriu-se que o comportamento mudou a partir da versão 102.1.0esr, de 26 de julho de 2022. Anteriormente, as inclusões ocorriam normalmente:
Após isso, a requisição de inclusão ainda ocorria, porém, sem a anexação de cookies, tornando impossível a exploração da vulnerabilidade:
Com a análise das notas sobre a versão, não foi possível definir exatamente o que foi alterado no navegador para a mudança no comportamento referente aos cookies. Após questionar em um fórum direcionado ao Firefox, também não foi possível chegar a uma conclusão a respeito.
4.2. Outros navegadores
Após a análise do Firefox, iniciou-se o estudo de diversos navegadores populares para compreensão do comportamento. Para todos os casos, a versão analisada foi a mais recente no momento da pesquisa, além de utilizar as configurações padrões sem qualquer modificação após a instalação, em um ambiente desktop.
Com o estudo, foram identificados dois casos: aqueles que permitiam a ocorrência da vulnerabilidade e aqueles que não permitiam, em comportamento similar ao observado nas versões recentes do Firefox, realizando a requisição, porém sem a utilização de cookies. Aqueles que permitem a vulnerabilidade foram denominados “vulnerável”, os resultados podem ser observados na seguinte tabela:
5. Mitigação
As mitigações da vulnerabilidade podem ser divididas em duas: para o cliente e para o servidor. Para os clientes, é interessante a utilização de navegadores com uma maior maturidade em termos de segurança e privacidade, além disso, cuidados básicos devem sempre ser tomados e também auxiliam neste caso. Deve-se sempre desconfiar de links desconhecidos, ofertas muito vantajosas, mensagens com senso de urgência etc. Além disso, evitar fornecer informações pessoais para aplicações, sempre fornecendo apenas o necessário e investigando o nível de maturidade e segurança daquela aplicação.
No caso do servidor, em um primeiro momento deve-se ter atenção ao criar cookies de sessão, utilizando de maneira correta o atributo “SameSite” evitando uma política muito permissiva, impedindo a inserção em requisições de origem cruzada. Também deve-se separar o código JavaScript dos dados dinamicamente gerados, utilizando JSON por exemplo. Deve-se também atentar para não utilizar o formato JSONP (JSON with padding), uma vez que são tratados como script pelo navegador, não sendo protegidos pela política de mesma origem. Mídias estáticas também devem ser armazenadas com nomes e caminhos imprevisíveis e aleatórios, evitando a possibilidade de desenvolvimento de uma página maliciosa para inclusão da mesma.
6. Cenários de ataque
Com a análise dos dados anteriores, é possível compreender cenários de ataque em que a vulnerabilidade pode ocorrer. São fictícios, porém baseados em cenários cotidianos.
6.1. Documentos pessoais
A empresa fictícia “Zebra Químicos” realiza a venda de produtos químicos controlados e, portanto, exige uma foto do documento de identificação de seus clientes. Esta é armazenada em um servidor web, em uma caminho previsível como {número do documento}_doc.jpeg e somente acessível externamente para o usuário dono do documento, identificado por um cookie de sessão mal configurado.
Ao acessar uma rede social pertencente ao “Zebra Químicos”, um agente malicioso identifica uma avaliação feita por “José”, comprador habitual da empresa. Com isso, o atacante busca o número do documento do José em um vazamento de dados, montando com essa informação uma página maliciosa direcionando José como alvo. O atacante envia a José uma mensagem se passando por um vendedor da “Zebra Químicos”, induzindo o mesmo a acessar a página maliciosa. Desse modo, a imagem do documento de José é comprometida.
6.2. Mensageiro
A aplicação mensageira “ZebraZap” utiliza uma lista de contatos para que o usuário mantenha salvo dados a respeito das pessoas na qual costuma conversar através da aplicação. Esses dados são exibidos ao usuário através de um código JavaScript dinâmico: ao ser requisitado, o usuário é identificado por um cookie de sessão mal configurado, e o arquivo é preenchido com a lista de contatos para esse usuário.
Um agente malicioso divulga publicamente um grupo no mensageiro “ZebraZap” para compartilhamento de cursos online de pentest, atraindo bastante usuários para o grupo. O download é finalmente disponibilizado, consistindo em um link para um domínio externo, justificado pelo atacante devido a uma limitação quanto ao tamanho dos arquivos permitidos no “ZebraZap”. Com isso, os usuários que acessarem o link, sofrem com o comprometimento de sua lista de contatos.
7. Conclusão
É possível concluir que, apesar da negligência e pouca relevância atribuída ao assunto, a vulnerabilidade XSSi ainda representa uma fonte de ameaça para as aplicações web, a depender de erros no desenvolvimento da aplicação e de uma engenharia social bem sucedida.
Além dos cenários tradicionais envolvendo a inclusão de scripts e de código dinamicamente gerado, mídias estáticas também representam recursos passíveis de exploração, sendo necessário cuidado para a proteção dos mesmos.
Hoje as opções de mitigação são mais amplas, dando ao desenvolvedor as ferramentas necessárias para combater o problema, sem afetar as funcionalidades e a usabilidade prevista para a aplicação.
Referências
Gertjan Franken, Tom Van Goethem, Wouter Joosen. Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie
Policies. Disponível em: <https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-franken.pdf>
Veit Hailperin, Marc Ruef. Cross-Site Script Inclusion A Fameless but Widespread Web Vulnerability Class. Disponível em: <https://zenodo.org/records/3521661>
Christoph Kern, Anita Kesavan, Neil Daswani. Foundations of Security: What Every Programmer Needs to Know.
Takeshi Terada. Identifier based XSSI attacks. Disponível em: <https://www.mbsd.jp/Whitepaper/xssi.pdf>
Sebastian Lekies, Ben Stock, Martin Wentzel, Martin Johns. The Unexpected Dangers of Dynamic JavaScript. Disponível em: <https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-lekies.pdf>
Jeremiah Grossman. Advanced Web Attack Techniques using GMail. Disponível em: <https://blog.jeremiahgrossman.com/2006/01/advanced-web-attack-techniques-using.html>
