Cross-site scripting (também conhecido como XSS) é uma vulnerabilidade de segurança na web que permite que um invasor comprometa as interações dos usuários com um aplicativo vulnerável. Ele permite que um invasor contorne a mesma política de origem, que é projetada para segregar diferentes sites uns dos outros. Vulnerabilidades de cross-site scripting normalmente permitem que um invasor se disfarce como um usuário vítima, execute quaisquer ações que o usuário seja capaz de realizar e acesse quaisquer dados do usuário. Se o usuário vítima tiver acesso privilegiado ao aplicativo, o invasor poderá obter controle total sobre todas as funcionalidades e dados do aplicativo.
Como o XSS funciona?
O cross-site scripting funciona manipulando um site vulnerável para que ele retorne JavaScript malicioso aos usuários. Quando o código malicioso é executado dentro do navegador da vítima, o invasor pode comprometer completamente a interação dela com o aplicativo.
Laboratórios
Se você já estiver familiarizado com os conceitos básicos por trás das vulnerabilidades XSS e quiser apenas praticar a exploração delas em alguns alvos realistas e deliberadamente vulneráveis, você pode acessar todos os laboratórios neste tópico no link abaixo.
Prova de conceito XSS
Você pode confirmar a maioria dos tipos de vulnerabilidade XSS injetando um payload que faz com que seu navegador execute algum JavaScript arbitrário. Há muito tempo, é prática comum usar a alert()função para esse propósito, pois ela é curta, inofensiva e bastante difícil de ignorar quando chamada com sucesso. Na verdade, você resolve a maioria dos nossos laboratórios de XSS invocando alert()o navegador de uma vítima simulada.
Infelizmente, há um pequeno problema se você usar o Chrome. A partir da versão 92 (20 de julho de 2021), iframes de origem cruzada são impedidos de chamar alert(). Como eles são usados para construir alguns dos ataques XSS mais avançados, às vezes você precisará usar um payload PoC alternativo. Nesse cenário, recomendamos a print()função . Se você tiver interesse em saber mais sobre essa mudança e por que gostamos de print().
Como a vítima simulada em nossos laboratórios usa o Chrome, corrigimos os laboratórios afetados para que também possam ser resolvidos usando [nome do laboratório] print(). Indicamos isso nas instruções sempre que relevante.
Quais são os tipos de ataques XSS?
Existem três tipos principais de ataques XSS. São eles:
- XSS refletido , onde o script malicioso vem da solicitação HTTP atual.
- XSS armazenado , de onde o script malicioso vem do banco de dados do site.
- XSS baseado em DOM , onde a vulnerabilidade existe no código do lado do cliente e não no código do lado do servidor.
Cross-site scripting refletido
XSS refletido é a variante mais simples de cross-site scripting. Ele surge quando um aplicativo recebe dados em uma solicitação HTTP e os inclui na resposta imediata de forma insegura.
Aqui está um exemplo simples de uma vulnerabilidade XSS refletida:https://insecure-website.com/status?message=All+is+well. <p>Status: All is well.</p>
O aplicativo não realiza nenhum outro processamento dos dados, então um invasor pode facilmente construir um ataque como este:https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script> <p>Status: <script>/* Bad stuff here... */</script></p>
Se o usuário visitar a URL construída pelo invasor, o script do invasor será executado no navegador do usuário, no contexto da sessão do usuário com o aplicativo. Nesse momento, o script poderá executar qualquer ação e recuperar quaisquer dados aos quais o usuário tenha acesso.
Script entre sites armazenado
O XSS armazenado (também conhecido como XSS persistente ou de segunda ordem) surge quando um aplicativo recebe dados de uma fonte não confiável e inclui esses dados em suas respostas HTTP posteriores de maneira insegura.
Os dados em questão podem ser enviados ao aplicativo por meio de solicitações HTTP; por exemplo, comentários em uma postagem de blog, apelidos de usuários em uma sala de bate-papo ou detalhes de contato em um pedido de cliente. Em outros casos, os dados podem chegar de outras fontes não confiáveis; por exemplo, um aplicativo de webmail exibindo mensagens recebidas por SMTP, um aplicativo de marketing exibindo postagens em mídias sociais ou um aplicativo de monitoramento de rede exibindo dados de pacotes do tráfego de rede.
Aqui está um exemplo simples de uma vulnerabilidade XSS armazenada. Um aplicativo de quadro de mensagens permite que os usuários enviem mensagens, que são exibidas para outros usuários:<p>Hello, this is my message!</p>
O aplicativo não realiza nenhum outro processamento dos dados, então um invasor pode facilmente enviar uma mensagem que ataque outros usuários:<p><script>/* Bad stuff here... */</script></p>
Cross-site scripting baseado em DOM
O XSS baseado em DOM (também conhecido como DOM XSS) surge quando um aplicativo contém algum JavaScript do lado do cliente que processa dados de uma fonte não confiável de forma insegura, geralmente gravando os dados de volta no DOM.
No exemplo a seguir, um aplicativo usa JavaScript para ler o valor de um campo de entrada e gravar esse valor em um elemento dentro do HTML:var search = document.getElementById('search').value; var results = document.getElementById('results'); results.innerHTML = 'You searched for: ' + search;
Se o invasor puder controlar o valor do campo de entrada, ele poderá facilmente construir um valor malicioso que fará com que seu próprio script seja executado:You searched for: <img src=1 onerror='/* Bad stuff here... */'>
Em um caso típico, o campo de entrada seria preenchido a partir de parte da solicitação HTTP, como um parâmetro de sequência de consulta de URL, permitindo que o invasor realize um ataque usando uma URL maliciosa, da mesma maneira que o XSS refletido.
Para que o XSS pode ser usado?
Um invasor que explora uma vulnerabilidade de script entre sites normalmente consegue:
- Personificar ou se passar pelo usuário vítima.
- Executar qualquer ação que o usuário seja capaz de executar.
- Leia todos os dados que o usuário consegue acessar.
- Capture as credenciais de login do usuário.
- Realizar desfiguração virtual do site.
- Injetar funcionalidade de trojan no site.
Impacto das vulnerabilidades XSS
O impacto real de um ataque XSS geralmente depende da natureza da aplicação, de sua funcionalidade e dados, e do status do usuário comprometido. Por exemplo:
- Em um aplicativo de folhetos, onde todos os usuários são anônimos e todas as informações são públicas, o impacto geralmente será mínimo.
- Em um aplicativo que contém dados confidenciais, como transações bancárias, e-mails ou registros de saúde, o impacto geralmente será sério.
- Se o usuário comprometido tiver privilégios elevados no aplicativo, o impacto geralmente será crítico, permitindo que o invasor assuma o controle total do aplicativo vulnerável e comprometa todos os usuários e seus dados.
Como encontrar e testar vulnerabilidades XSS
A grande maioria das vulnerabilidades XSS pode ser encontrada de forma rápida e confiável usando o scanner de vulnerabilidades da web do Burp Suite.
Testar manualmente o XSS refletido e armazenado normalmente envolve o envio de uma entrada única simples (como uma string alfanumérica curta) para cada ponto de entrada do aplicativo, identificando cada local onde a entrada enviada é retornada em respostas HTTP e testando cada local individualmente para determinar se uma entrada adequadamente elaborada pode ser usada para executar JavaScript arbitrário. Dessa forma, você pode determinar o contexto em que o XSS ocorre e selecionar um payload adequado para explorá-lo.
Testar manualmente XSS baseado em DOM proveniente de parâmetros de URL envolve um processo semelhante: inserir uma entrada única e simples no parâmetro, usar as ferramentas de desenvolvedor do navegador para pesquisar essa entrada no DOM e testar cada local para determinar se é explorável. No entanto, outros tipos de XSS DOM são mais difíceis de detectar. Para encontrar vulnerabilidades baseadas em DOM em entradas não baseadas em URL (como document.cookie) ou coletores não baseados em HTML (como setTimeout), não há substituto para a revisão do código JavaScript, que pode ser extremamente demorada. O scanner de vulnerabilidades da web do Burp Suite combina análise estática e dinâmica de JavaScript para automatizar de forma confiável a detecção de vulnerabilidades baseadas em DOM.
Política de segurança de conteúdo
A política de segurança de conteúdo (CSP) é um mecanismo de navegador que visa mitigar o impacto de scripts entre sites e algumas outras vulnerabilidades. Se um aplicativo que utiliza CSP apresentar comportamento semelhante ao XSS, a CSP poderá dificultar ou impedir a exploração da vulnerabilidade. Muitas vezes, a CSP pode ser contornada para permitir a exploração da vulnerabilidade subjacente.
Injeção de marcação pendente
A injeção de marcação pendente é uma técnica que pode ser usada para capturar dados entre domínios em situações em que uma exploração completa de cross-site scripting não é possível devido a filtros de entrada ou outras defesas. Muitas vezes, ela pode ser explorada para capturar informações confidenciais visíveis a outros usuários, incluindo tokens CSRF que podem ser usados para executar ações não autorizadas em nome do usuário.
Como prevenir ataques XSS
Evitar cross-site scripting é trivial em alguns casos, mas pode ser muito mais difícil dependendo da complexidade do aplicativo e das maneiras como ele manipula dados controláveis pelo usuário.
Em geral, a prevenção eficaz de vulnerabilidades XSS provavelmente envolverá uma combinação das seguintes medidas:
- Filtre a entrada na chegada. No ponto em que a entrada do usuário é recebida, filtre o mais rigorosamente possível com base no que é esperado ou em uma entrada válida.
- Codifique os dados na saída. No ponto em que os dados controláveis pelo usuário são enviados em respostas HTTP, codifique a saída para evitar que seja interpretada como conteúdo ativo. Dependendo do contexto de saída, isso pode exigir a aplicação de combinações de codificação HTML, URL, JavaScript e CSS.
- Use cabeçalhos de resposta apropriados. Para evitar XSS em respostas HTTP que não devem conter HTML ou JavaScript, você pode usar os cabeçalhos
Content-TypeeX-Content-Type-Optionspara garantir que os navegadores interpretem as respostas da maneira que você deseja. - Política de Segurança de Conteúdo. Como última linha de defesa, você pode usar a Política de Segurança de Conteúdo (CSP) para reduzir a gravidade de quaisquer vulnerabilidades XSS que ainda ocorram.
Perguntas comuns sobre cross-site scripting
Quão comuns são as vulnerabilidades XSS? Vulnerabilidades XSS são muito comuns, e XSS é provavelmente a vulnerabilidade de segurança web mais frequente.
Quão comuns são os ataques XSS? É difícil obter dados confiáveis sobre ataques XSS no mundo real, mas provavelmente são menos explorados do que outras vulnerabilidades.
Qual é a diferença entre XSS e CSRF? XSS envolve fazer com que um site retorne JavaScript malicioso, enquanto CSRF envolve induzir um usuário vítima a realizar ações que não pretendia.
Qual é a diferença entre XSS e injeção de SQL? XSS é uma vulnerabilidade do lado do cliente que tem como alvo outros usuários do aplicativo, enquanto a injeção de SQL é uma vulnerabilidade do lado do servidor que tem como alvo o banco de dados do aplicativo.
Como posso evitar XSS em PHP? Filtre suas entradas com uma lista de caracteres permitidos e use dicas de tipo ou conversão de tipo. Use escapes para suas saídas com htmlentitiese ENT_QUOTESpara contextos HTML, ou escapes Unicode em JavaScript para contextos JavaScript.
Como posso evitar XSS em Java? Filtre suas entradas com uma lista de caracteres permitidos e use uma biblioteca como o Google Guava para codificar sua saída em HTML para contextos HTML ou use escapes Unicode em JavaScript para contextos JavaScript.
Deixe um comentário