Cross-Site Scripting (XSS)

Crosssite scripting-referido como XSS-é uma vulnerabilidade de aplicação que tem o potencial de causar estragos em aplicações e websites. O XSS é tão desenfreado e potencialmente prejudicial que continua a ser incluído na lista das 10 principais vulnerabilidades do Open Web Application Security Project (OWASP).

Na verdade o Cross-Site Scripting é a vulnerabilidade mais comum descoberta desde 2014 e em 2019 continua a aparecer no Top 3 das vulnerabilidades relatadas.

Em alguns casos, o script do lado do navegador também pode introduzir esta vulnerabilidade permitindo que um atacante a explore sem que o usuário alvo faça um pedido à aplicação web.

Atackers exploram o XSS elaborando código malicioso que pode ser roteado para outro usuário, sendo então executado pelo navegador insuspeito. Como o script é mais frequentemente incluído no conteúdo da resposta da aplicação web, ele é executado e tem o mesmo acesso como se o script fosse legítimo. Pode ser permitido o acesso a fichas de sessão, cookies e até informações confidenciais ou sensíveis a que o navegador tem acesso nesse site, mesmo reescrevendo o conteúdo da página HTML.

Ataques XSS refletidos

Em ataques XSS refletidos, o script malicioso é injetado em uma requisição HTTP (geralmente por um link especificamente criado fornecido ao usuário). Como a variedade mais simples, ele usa parâmetros de entrada na requisição HTTP que podem ser facilmente manipulados para incluir o conteúdo prejudicial do script. O script malicioso é então refletido do servidor em uma resposta HTTP e é executado no navegador da vítima.

Neste caso, ele age como um XSS armazenado sem realmente armazenar dados maliciosos no servidor.

Aqui está um exemplo de Ataque XSS Refletido:

Dizemos exemplo.com/profile que contém um parâmetro de nome. A URL para o pedido ficaria parecida com esta: https://example.com/profile?user=Tammy. Baseado nesta entrada, a aplicação web responderia assim com “Olá Tammy” no topo da página. Se os parâmetros não forem validados para garantir que contém apenas os dados esperados, um atacante poderia fazer um usuário visitar uma versão maliciosa da URL como esta: https://example.com/profile?user<script>some_malicious_code</script>.

Quando a resposta é enviada para o navegador, ela inclui aquele script malicioso, que é então executado no navegador, provavelmente sem o usuário sequer saber. Este é um exemplo de ataque XSS refletido, pois o código malicioso é imediatamente “refletido” de volta para o usuário que faz a requisição.

Ataques XSS armazenados

No que é conhecido como ataque XSS armazenado ou persistente, o conteúdo malicioso é entregue diretamente, junto com a resposta do servidor quando o usuário carrega uma página web. Assim o conteúdo já é armazenado no banco de dados do site (daí o nome para tais ataques). Os usuários então simplesmente entram na página web hackeada e são vítimas de tais ataques.

Cada usuário que abre um site tão comprometido corre o risco de ter seus dados pessoais roubados, e por isso este poderia ser considerado o tipo mais perigoso de ataque XSS.

Mas como o conteúdo malicioso entra no banco de dados para começar? Na maioria dos casos, ele é introduzido através de formulários de páginas web desprotegidas, nas quais a entrada do usuário não é devidamente validada e higienizada. Se os dados inseridos por um hacker não forem validados tanto no lado do cliente como do servidor, eles serão salvos na base de dados. Por exemplo, essa entrada pode incluir uma área de texto de comentário, editor de texto post, editor de dados pessoais ou outros formulários.

Após um atacante conseguir enviar conteúdo malicioso para o servidor e esse conteúdo parecer não filtrado em uma página web, todos os usuários se tornam vítimas potenciais. A higienização envolve uma combinação de validação de dados e fuga de caracteres especiais ou filtragem completa dos mesmos e é uma melhor prática comum para segurança web e JavaScript.

Ataques XSS baseados em DOM

Document Object Model (DOM) é uma interface que permite às aplicações ler e manipular a estrutura de uma página web, seu conteúdo e estilo. Em um ataque XSS baseado em DOM, a vulnerabilidade está no código do script do lado do navegador e pode ser explorada sem nenhuma interação do servidor, modificando o ambiente no navegador da vítima insuspeita.

Por vezes, ataques XSS baseados em DOM são similares a ataques refletidos. O exemplo acima de um ataque XSS refletido pode ser aplicado neste caso com uma única suposição: A aplicação web lê dados diretamente de uma query string.

Vamos dizer que a aplicação usa o parâmetro de query “name” a fim de exibir instantaneamente o nome do usuário na tela enquanto espera o resto de uma página para carregar. Sem uma validação adequada, isto pode produzir o mesmo resultado que um ataque refletido, se o hacker for bem sucedido em fazer a vítima abrir um link suspeito.

Como com o XSS armazenado, para evitar ataques baseados em reflexos e DOM, os desenvolvedores devem implementar a validação dos dados e evitar a exibição de entrada de dados brutos do usuário, apesar da presença ou ausência de comunicação com o servidor.

Quais são os vetores de ataque Cross-site Scripting?

Existem vários vetores comumente utilizados em ataques XSS:

• <script> tag: Uma tag de script pode ser usada para referenciar código JavaScript externo, tornando este o ponto XSS mais simples. Os atacantes também podem incorporar o código malicioso na tag do script.
• eventos JavaScript: Outro vetor XSS popular usado por atacantes, atributos de eventos, pode ser aplicado em uma variedade de tags. Tais atributos como “onerror” e “onload” são exemplos.
• <body> tag: Atributos de evento também podem ser a fonte do script quando fornecidos através da tag “body”.
• <img> tag: Dependendo do browser em uso, este atributo pode ser útil por atacantes para executar o código JavaScript.
• <iframe> tag: Especialmente eficaz para ataques de phishing, este vector permite que o ataque XSS incorpore outra página HTML na página actual.
• <input> tag: Alguns browsers permitem a manipulação através deste vector, que pode ser usado para incorporar um script.
• <link> tag: Esta tag pode conter um script, ao invés do uso normal de links para folhas de estilo externas.
• <table> tag: Onde o atributo background normalmente se refere a uma imagem, isto pode ser comprometido para se referir ao script ofensivo.
• <div> tag: Esta tag também contém uma referência de fundo e pode ser usada da mesma forma que <table> para se referir a um script.
• <object> tag: Scripts de um site externo podem ser incluídos usando esta tag.

Embora existam outros vetores que os atacantes XSS usam em seus esforços para roubar informações e comprometer sites, estes são alguns dos métodos mais comumente usados. Os desenvolvedores devem aderir a práticas adequadas de fuga e higienização para se protegerem contra tais ataques.

Dependente do atacante e sua intenção maliciosa, os ataques XSS podem resultar em diferentes impactos, inclusive:

• hijacking da sessão de um usuário, utilizando credenciais para acessar outros sites ou redirecionar o usuário para sites não intencionais,
• alterar páginas de sites ou inserir seções em uma página da web,
• executar scripts para extrair informações sensíveis de cookies ou bancos de dados,
• se a vítima tiver direitos administrativos, o ataque pode se estender para o lado do servidor, causando mais danos ou recuperando informações sensíveis adicionais.

Passos-chave nos testes de vulnerabilidades XSS para aplicações web críticas incluem:

• utilizar uma ferramenta de varredura de código para detectar vulnerabilidades que permitem correções de código durante o processo de desenvolvimento,
• implementar a funcionalidade de testes automatizados que revelarão vulnerabilidades em potencial de forma completa e rápida.

Vamos dizer que exmple.com/profile contém um parâmetro de nome. O URL para o pedido seria parecido com https://example.com/profile?user=Tammy. A aplicação web responde com “Hi Tammy” no topo da página com base neste input.

Se o parâmetro do utilizador não for validado para garantir que contém apenas os dados esperados, um atacante pode ter um utilizador a visitar uma versão maliciosa da URL que se parece com isto:
https://example.com/profile?user<script>some_malicious_code</script>.
Quando a resposta é enviada para o browser, inclui aquele script malicioso que é executado no browser, provavelmente sem o utilizador sequer saber. Este é um exemplo de um ataque XSS refletido. O código malicioso é imediatamente “refletido” de volta para o usuário que faz a solicitação.

• Educação e conscientização: Certifique-se de que todos os desenvolvedores, designers de sites e equipes de QA estão cientes dos métodos que os hackers usam para explorar as vulnerabilidades e fornecer diretrizes e melhores práticas para a codificação. Isto inclui técnicas apropriadas de fuga/codificação para o ambiente de aplicação (JavaScript, HTML, etc.).
• Sanitize input: Seja para páginas web internas ou sites públicos, nunca confie na validade dos dados de entrada do usuário. Tela e valide quaisquer campos de dados, especialmente se eles serão incluídos como saída HTML.
• Scan code: Implementar software que varre o código em busca de vulnerabilidades, incluindo scripts entre sites, para garantir que as melhores práticas estão sendo seguidas e minimiza a exposição do XSS e outras vulnerabilidades listadas no OWASP.
• Política de Segurança de Conteúdo: Use a Política de Segurança de Conteúdo (CSP) para definir o que um website pode fazer, e com isso reduzir o risco de um ataque XSS. Usando CSP, XSS pode ser totalmente bloqueado (bloqueando todos os scripts em linha) ou ser reduzido para um risco muito menor.

OWASP fornece orientação adicional sobre como prevenir vulnerabilidade de XSS com uma folha de fraude abrangente.