Neste post vamos falar sobre Cross Site Scripting, também conhecido como XSS, uma das vulnerabilidades mais comuns desde 2014. Na verdade, segundo o OWASP, essa vulnerabilidade, que a partir deste ano será incluída na categoria de injeções, faz parte das top 10 vulnerabilidades mais frequentes em aplicativos da web de 2021.

É um tipo de ataque que explora falhas de segurança em sites e permite que invasores implantem scripts maliciosos em um site legítimo (também vítima do invasor) para executar um script no navegador de um usuário desprevinido que visita esse site e o afeta, seja roubando credenciais, redirecionando o usuário para outro site malicioso ou realizando um defacement nele.

Há alguns anos, explicamos em outro artigo de maneira simples do que se trata essa vulnerabilidade, mas naquela época estávamos falando sobre como ela poderia ser explorada de duas maneiras. Atualmente o OWASP explica que existem três formas mais comuns de ataques XSS que têm como alvo os navegadores dos usuários. Por isso, neste artigo atualizado repassamos quais são os vetores de ataque utilizados pelos atacantes para explorar esta vulnerabilidade, que pode realizar um atacante mediante Cross Site Scripting, e compartilhamos também um recursos que provavelmente não conhecia para identificar a vulnerabilidade ou exploração da mesma. Para se ter uma ideia do impacto e do interesse que os invasores têm por esta vulnerabilidade, no último ano houveram mais de 100.000 relatórios de ataques de Cross Site Scripting de acordo com Vulners.

O que é Cross-Site Scripting

Como antecipamos acima, o XSS é um tipo de ataque em que agentes maliciosos conseguem injetar um script malicioso em um site e, em seguida, ser processado e executado. Comumente, esse processo que se baseia na confiança que o site possui quanto à entrada de dados, consiste em enviar a URL com o payload pré-carregada ao usuário vítima com um objetivo específico: roubar os dados pessoais do usuário, cookies de sessão, implementar técnicas sociais engenharia, entre outros.

Existem três tipos de XSS que permitem que esse ataque ocorra. Em seguida, revisamos o que são e as medidas que devemos tomar para nos proteger:

Reflected Cross-Site Scripting

Em um ataque XSS espelhado o payload geralmente é injetado em um parâmetro da solicitação HTTP, para então ser processada pelo aplicativo da web e finalmente implantada em um determinado ponto, sem qualquer tipo de validação ou codificação de caracteres. Se trata da variedade mais simples de XSS e o script malicioso que visa afetar o navegador da vítima é facilmente modificável, provavelmente sem que o usuário perceba o ataque.

Como pode ser visto no exemplo a seguir, um link de aparência normal é criado sem um parâmetro sinalizado e um vetor de ataque é observado delimitado pelo controle de número de página do site.

https://insecure-site.example/blog/page/1/latest

A vulnerabilidade, neste caso, é um parâmetro que não é visível a olho nu, mas algum aplicativo pode estar usando o valor do URL para poder usá-lo no site e, portanto, dar origem à vulnerabilidade de Reflected Cross-Site Scripting.

Imagem 1. Exemplo de um aplicativo web vulnerável ao XSS refletido.

Stored Cross-Site Scripting

Essa variante tem como característica que o aplicativo da web salva o valor de entrada em um meio de armazenamento e o script inofensivo persiste, até que o valor seja recuperado pelo aplicativo e usado conforme parte do documento HTML.

Os pontos de entrada mais conhecidos em que essa vulnerabilidade geralmente é observada são nos comentários de sites, entradas de blog, nomes de usuário, chats, formulários de contato, detalhes de um pedido, etc. E, assim como existem vários valores de entrada, um XSS persistente pode vir de vários meios. A resposta do protocolo HTTP é a mais comum, assim como mensagens via SMTP, serviços de mensagens instantâneas, notificações via socket, citando alguns.

Imagem 2. Exemplo do XSS armazenado.

DOM-based Cross-Site Scripting

O Document Object Model (DOM) é uma interface de programação para representar a estrutura de um documento da web e conectá-lo a uma linguagem de scripting. Nesse sentido, o DOM facilita a estruturação de documentos como HTML ou XML e permite que os programas modifiquem a estrutura, o estilo e o conteúdo do documento. No caso de um ataque XSS baseado em DOM, o playload malicioso é executado como resultado da modificação do ambiente DOM no navegador da vítima. Isso leva o usuário a executar o código do lado do cliente sem saber o que está fazendo.

A partir da evolução de muitas bibliotecas JavaScript, é cada vez mais comum que o processamento de dados seja implementado a partir de fontes não confiáveis ​​(inseguras ou sem a codificação adequada dos dados) do lado do cliente, geralmente gravando esses dados no DOM do site.

Algumas funções em JavaScript que podem ser um indicador de uma possível vulnerabilidade são:

  • domain
  • write()
  • writeln()
  • innerHTML
  • insertAdjacentHTML
  • onevent
  • Element.outerHTML

Sem esquecer de bibliotecas como o JQuery, onde se utiliza métodos específicos para facilitar algumas funções tradicionais do próprio JavaScript, ou outras bibliotecas sem a codificação adequada dos dados:

  • $.parseHTML()
  • add()
  • after()
  • animate()
  • append()
  • before()
  • constructor()
  • has()
  • html()
  • index()
  • init()
  • insertAfter()
  • insertBefore()
  • parseHTML()
  • prepend()
  • replaceAll()
  • replaceWith()
  • wrap()
  • wrapAll()
  • wrapInner()

Imagem 3. Exemplo DOM XSS.

Evolução do XSS

Desde o aparecimento da vulnerabilidade, muitas pesquisas foram realizadas a esse respeito e conforme as linguagens de programação evoluem, novas formas de explorar um Cross-Site Scripting são criadas, uma vez que existem diferentes linguagens de programação e novos estilos de desenvolvimento web. Um caso muito interessante foi conhecido com o uso do JSFuck, um estilo de programação com apenas seis caracteres, já que com o mínimo de caracteres tomado como base na própria linguagem JavaScript é possível criar e executar código JavaScript. É importante considerar esse estilo de programar na hora de tomar medidas para mitigar qualquer tipo de Cross-Site Scripting.

O que os invasores podem fazer se explorarem essa vulnerabilidade?

Se você já se perguntou se um invasor poderia apenas realizar um defacement do site que você está navegando, roubar alguns dados que estão usando no aplicativo da web vulnerável ou roubar cookies de sessão - como aconteceu no recente ataque que levou ao roubo do código fonte do FIFA 21 no qual utilizaram como vetor inicial cookies de sessão de um canal do Slack - a realidade indica que não. Existem vários ataques por meio do uso de JavaScript. Por exemplo, é possível ler a memória de alguns processos do usuário, como no ataque Rowhammer que tem como vítima a tecnologia DDR4, realizar ataques de ransomware, exfiltrar dados confidenciais em um documento PDF ou realizar digitalização em rede. Dependendo do vetor vulnerável, uma vulnerabilidade de XSS pode levar a qualquer um dos ataques mencionados.

Ferramentas para identificar ataques e exploração de Cross Site Scripting

Felizmente, existem muitas ferramentas para identificar um ataque de Cross-Site Scripting e até mesmo exploração usando scripts elaborados para vários usos. É aqui que a framework Beef entra em ação com a ampla gama de scripts disponíveis. Os mais comuns estão listados abaixo.

Medidas preventivas

O OWASP nos oferece um modelo preventivo sob algumas regras que devemos levar em consideração para evitar a execução de comandos no navegador (XSS). Eles são descritos de uma forma geral abaixo:

  • Implementar uma política de segurança sob o título CSP (Content Secure Policy), considerando pelo menos os seguintes pontos:
    • Evitar a execução de scripts inseridos em HTML
    • Prevenir o carregamento de scripts de uma fonte desconhecida
    • Evitar o uso de funções inseguras como Eval
    • Restringir o uso da tag HTML object
  • Estabelecer o atributo de segurança HttpOnly para reduzir o impacto do ataque XSS
  • Validar qualquer dado de entrada em uma lista branca de caracteres permitidos
  • Codificar a saída de dados, pelo menos para os caracteres especiais (&, <,>, ",‘), em seus respectivos códigos HTML de acordo com o contexto, seja JavaScript, CSS, HTML
  • Usar as bibliotecas para higienizar os dados como HtmlSanitizer

Teste suas habilidades para explorar um Cross-Site Scripting

Se você se sente muito motivado para poder conhecer e descubrir novas formas para poder explorar uma vulnerabilidade de XSS e assim poder aplicar as medidas corretivas adequadas, compartilhamos exercícios e desafios muito bons, alguns que explicam o passo a passo, assim como outros muito divertidos para pensar um pouco mais.