Cross-Site Scripting - Como os hackers sequestram o seu site

Tobias Schüring Última atualização 15.01.2020
6 min.
Cross-Site Scripting_XSS

XSS, SQL injection, XMLrpc - quando uma atualização de segurança WordPress é lançada, os relatórios de atualização contêm na sua maioria acrônimos crípticos. Mesmo que seja claro que essas atualizações são necessárias e que a vantagem na segurança é muito agradável, é importante entender o que está por trás dessas vulnerabilidades de segurança. Porque só se você entender que lacunas as atualizações se fecham, você também pode tomar uma decisão informada. É por isso que hoje vamos olhar para o cross-site scripting, ou XSS, que é de longe o ataque complexo mais comum nas páginas WordPress .

Ataques de hackers podem ser comparados a assaltantes. Brute Force Os ataques são mais parecidos com o método do pé-de-cabra. O criminoso resiste à ferramenta até que a porta ou janela se abra. Os ataques às vulnerabilidades XSS, por outro lado, são sofisticados: O ladrão sabe exactamente por onde começar e ganha acesso direccionado a uma página.

No decorrer do cross-site scripting, as falhas de segurança nos sites são deliberadamente exploradas. Hackers injetam scripts maliciosos em um contexto confiável (suas páginas!). Similar a um clandestino em um navio, este código malicioso usa o seu site como um veículo para perseguir seus próprios objetivos.

No pior dos casos, os agressores obtêm assim informações confidenciais ou acesso ao computador do usuário vitimado. Tais ataques não são exactamente raros: Uma boa metade das vulnerabilidades encontradas pelo provedor de segurança Wordfence em 2015 e 2016 foram vulnerabilidades de scripting em Plugins .. Muitas vezes, um ataque XSS forma então a "base" para outros ataques, tais como spam, phishing ou ataques DDoS. É por isso que hoje vou mostrar-vos como funciona exactamente o guião cruzado, que tipos de ataques existem e quão perigosos são os ataques.

O cross-site scripting funciona sempre de forma semelhante: o código malicioso chega ao seu site através de uma lacuna.

O scripting cruzado é um perigo sempre que uma aplicação web encaminha os dados do utilizador para o browser sem verificar qualquer código de script. Um bom exemplo de uma aplicação web deste tipo é um chat de suporte.

Através da própria aplicação web os scripts maliciosos podem chegar ao servidor. A partir daí, mais cedo ou mais tarde, o código malicioso acaba nos clientes afectados. Um bom exemplo dessa vulnerabilidade XSS é o bug descoberto em julho de 2016 na meta-infos da imagem em WooCommerce 2.6.2. Um bug tornou possível que os atacantes injetassem código HTML nas meta-descrições das imagens de fora. Cada cliente que tivesse olhado mais de perto a imagem em questão (por exemplo, clicando na imagem) correria o risco de ser atacado. Por exemplo, um hacker pode ter infectado os computadores dos seus clientes com um vírus.

Truque popular para o guião cruzado: formas manipuladas

O XSS também pode permitir que hackers substituam formas inofensivas por formas manipuladas. Estes formulários recolhem então os dados das vítimas (os dos visitantes do seu site!). DA propósito, mesmo a encriptação SSL não pode protegê-lo contra isso. HTTPS "apenas" significa que a conexão entre o servidor e o cliente é criptografada. No entanto, se a própria forma foi manipulada, mesmo uma conexão criptografada é inútil.

Como com outros tipos de ataques, o objetivo dos hackers é, na maioria das vezes, monetizar suas maquinações. Em termos concretos, isto significa que os atacantes ou roubam dados que mais tarde vendem ou querem infectar locais, a fim de integrá-los em uma chamada botnet que é depois alugada.

3 tipos de ESTX: reflectido, persistente e local

Os ataques de scripting cruzado podem ser divididos em três tipos:

Grosseiramente falando, os ataques XSS funcionam da seguinte forma: O código malicioso é injetado onde se espera a entrada do usuário (por exemplo, em uma busca interna à página). Como parte da resposta do servidor, o código malicioso é então executado no cliente, ou seja, no navegador do usuário. E é exactamente aqui que o dano é feito, por exemplo, os dados do utilizador são roubados.

Roteiro reflexivo cruzado do local

Algumas entradas, tais como consultas de pesquisa, são refletidas pelo servidor. Isto significa que, por exemplo, depois de introduzir "teste" na caixa de pesquisa, a página irá retornar "você pesquisou por teste". Então o que o usuário entra torna-se parte da resposta do servidor.

Isto é exactamente o que os atacantes exploram de forma inteligente: Se um script malicioso for enviado para o servidor web em vez de um termo de pesquisa, a página pode ser manipulada para finalmente ser executada. Este tipo de ataque também é conhecido como não-persistente referido como não-persistente. O código malicioso é, portanto, apenas injetado temporariamente na respectiva página, mas não é armazenado.

Em julho, tal vulnerabilidade foi encontrada em Plugin WP Statistics (e corrigida no mesmo dia!). Um valor de entrada na página 'wps_visitors_page' foi encaminhado sem verificação, o que levou a uma vulnerabilidade através do XSS refletido. Desta forma, uma página poderia ser hackeada se um administrador tivesse previamente clicado em um link manipulado apropriadamente.

Por exemplo, um ataque de script refletido em vários locais pode se parecer com isto.
Por exemplo, um ataque de script refletido em vários locais pode se parecer com isto.

Funciona assimO atacante distribui ligações com parâmetros manipulados às suas potenciais vítimas. Sem saber, o usuário envia um pedido "manipulado" ao servidor clicando no link, e o código malicioso é executado junto com a resposta do servidor. Como o código - ao contrário do XSS persistente - não é armazenado em nenhum lugar, o hacker deve distribuí-lo em massa para as potenciais vítimas. Isto pode acontecer através de e-mails ou redes sociais, por exemplo.

guião cruzado persistente

Com XSS persistente, os scripts maliciosos são armazenados no servidor web e entregues cada vez que são chamados por um cliente. Predestinados para isto são aplicações web que armazenam os dados do utilizador no servidor e depois os emitem sem verificação ou codificação (por exemplo, fóruns). Este tipo de scripting pode ser particularmente perigoso para blogs e fóruns altamente frequentados, pois o malware pode se espalhar rapidamente aqui devido ao grande número de usuários.

Este gráfico mostra uma possível sequência de um ataque persistente de cross-site scripting.
Fluxo de um persistente ataque de guiões cruzados no local. Fonte: Blog SAP

Exemplo: Im um fórum, as contribuições postadas são armazenadas em um banco de dados. Não é incomum que estes sejam armazenados sem controle e descriptografados. Os atacantes aproveitam esta oportunidade e adicionam um script malicioso (por exemplo, com a ajuda de um comentário) a um post normal do fórum. uma mensagem normal no fórum com um script malicioso (por exemplo, com a ajuda de um comentário). Os usuários recebem o link relevante para o post por e-mail ou chegam à entrada correspondente por acaso e executam o script quando chamam o post. A vantagem para o hacker é que ele pode agora "espiar" os clientes afetados ou adicioná-los à sua rede de bots para novos ataques.

Scripting local ou baseado em DOM

Ao contrário do XSS persistente e refletido, o DOM (Document Object Model) baseado em scripts cross-site funciona através da execução de scripts do lado do cliente. Isto significa que o servidor não está ciente de tal ataque e as medidas de segurança do lado do servidor também não ajudam.

Um exemplo bem conhecido de tal vulnerabilidade é o caso do pacote genéricoon. O pacote genericon é um conjunto de ícones que é usado por muitos Plugins, incluindo o Jetpack. Foi possível injectar código malicioso através de um ficheiro HTML neste conjunto de ícones.

Depois de introduzir esta URL, surgiu um alerta javascript. Esta é a prova de que o código javascript inserido poderia ser usado para manipular a página em questão.
Depois de entrar nesta URL, um alerta de JavaScript apareceu. Isto é uma prova de que o código JavaScript inserido poderia ser usado para manipular a página em questão. Fonte: securityaffairs.com

Entretanto, um pré-requisito para um ataque XSS baseado em DOM é que o usuário clique em um URL manipulado. Ao chamar este URL, o código malicioso pode ser executado através de uma lacuna em um script do lado do cliente. Entre outras coisas, o fato de que um link deve ser clicado primeiro torna o XSS baseado em DOM um tipo de ataque um pouco mais difícil e, portanto, menos provável.

O gráfico mostra uma possível sequência de um ataque de cross-site de scripting local.
Exemplo de um ataque de cross-site de scripting local. Fonte: heise.de

Exemplo: O usuário clica no URL manipulado e envia um pedido para a aplicação web. A aplicação web responde passando o código do script (que é incorreto mas não manipulado) para o navegador para iniciar a execução do script. Os parâmetros manipulados da URL são agora interpretados e executados no navegador do usuário como parte do script. A página web apresentada no browser é assim alterada e o utilizador vê agora - sem dar por isso - a página manipulada.

Conclusão: Bastante frequente e não isenta de perigo, por isso é importante uma protecção adequada.

As vulnerabilidades do XSS estão entre os gateways mais comuns para código malicioso. E muitas vezes um ataque correspondente forma a base para outros ataques, tais como spam, phishing ou ataques DDoS. Atacantes seqüestram seu site e abusam dele para atingir seus próprios objetivos.

XSS reflectidos e persistentes são particularmente comuns, uma vez que o cross-site local é mais elaborado e difícil de implementar. Páginas que encaminhar dados do usuário para o navegador da web sem verificar possíveis códigos maliciosos estão particularmente em risco. Encontrar tais lacunas, no entanto, não é assim tão fácil. Em princípio, esta é precisamente a tarefa de fornecedores de segurança como a sucuri and Co, que estão constantemente a desenvolver as suas medidas de segurança.

Mas é claro que também existe uma forma de os utilizadores normais do site WordPress se protegerem destes ataques. As actualizações de todos os componentes WordPress , por exemplo, são uma medida simples mas muito eficaz. Como você, como operador do site, mas também como usuário da Internet, pode evitar o uso de scripts entre sites, explicamos no nosso próximo artigo sobre o assunto.

Você ainda tem comentários ou perguntas? Então deixe um comentário!

Como administrador do sistema, Tobias zela pela nossa infraestrutura e faz os ajustes necessários para otimizar o desempenho dos nossos servidores. Devido ao seu esforço incansável, ele pode ser frequentemente encontrado na Slack, a nossa "sala de chat da empresa".

Artigos relacionados

Comentários sobre este artigo

Escreve um comentário

O teu endereço de e-mail não será publicado. Os campos obrigatórios estão marcados com *.