Cross Site Scripting (XSS): Como evitar?

O que é um Cross Site Scripting (XSS)?

Cross Site Scripting (XSS) é um ataque de injeção de código no qual um adversário insere um código malicioso em um site legítimo. Em seguida, o código é iniciado como um script infectado no navegador da Web do usuário, permitindo que o invasor roube informações confidenciais ou se faça passar pelo usuário.

Fóruns da Web, quadros de mensagens, blogs e outros sites que permitem que os usuários publiquem seu conteúdo são os mais suscetíveis a ataques de XSS. A menos que a entrada seja analisada, verificada e codificada pelo aplicativo da Web, qualquer script mal-intencionado incluído no código será executado automaticamente pelos navegadores de outros usuários. Esse script pode, então, acessar os cookies do usuário, os tokens de sessão ou informações confidenciais alternativas retidas pelo navegador e usadas nesse site. É possível até mesmo que esses scripts reescrevam o conteúdo da página da Web infectada em ataques mais avançados.

Ataques sem arquivo e baseados em script, como XSS, estão em ascensão nos últimos anos devido à sua capacidade de evasão. Esses ataques podem contornar facilmente as soluções antivírus (AV) e os firewalls tradicionais, o que os torna relativamente simples de serem executados. As organizações precisam incluir a detecção e a prevenção de XSS como parte de sua estratégia geral de segurança cibernética para proteger os visitantes de seus sites e reduzir o risco de danos à reputação da organização.

Tipos e exemplos de ataques XSS

Há três tipos principais de ataques de Cross Site Scripting:

  • XSS refletido ou não persistente: o script mal-intencionado é executado como parte de uma solicitação HTTP ativa e é “refletido” do servidor da Web para o usuário.
  • XSS armazenado ou persistente: o script malicioso é salvo permanentemente no banco de dados do aplicativo da Web, como o registro de visitantes, o fórum da Web ou o campo de comentários.
  • XSS baseado em DOM: a vulnerabilidade de segurança existe no código do lado do cliente, que é o código executado no navegador em vez do código do lado do servidor.

XSS refletido ou não persistente

A variedade mais simples de Cross Site Scripting, os ataques de XSS refletido ocorrem quando um aplicativo da Web recebe dados de uma solicitação HTTP e, em seguida, responde imediatamente sem validar ou codificar os dados. Como o aplicativo não processa os dados de forma alguma, o invasor pode facilmente lançar um ataque baseado em script contra outros usuários.

Em um ataque refletido, o script injetado se apresenta como uma mensagem de erro, resultado de pesquisa ou ação semelhante por meio de um link malicioso. Quando clicado, esse link executará o script, o que permite que o código injetado viaje para o site vulnerável e “reflita” de volta para o navegador do usuário. O navegador executa o código porque considera o site uma fonte confiável. O script pode então executar qualquer ação disponível para o usuário naquela sessão, bem como capturar quaisquer dados transmitidos pelo usuário durante a sessão.

XSS armazenado ou persistente

Os ataques XSS armazenados, também conhecidos como ataques XSS persistentes, ocorrem quando um aplicativo da Web compartilha dados de uma fonte não confiável ou não verificada em respostas HTTP subsequentes. Em um ataque do tipo Stored Cross Site Script, o script injetado é salvo permanentemente nos servidores de destino, como em um banco de dados, publicação em um quadro de mensagens, comentário ou outro local. Se o site não processar os dados enviados, um invasor poderá facilmente inserir conteúdo que inclua um script mal-intencionado que infectará outros usuários. A vítima recupera o script malicioso do servidor quando solicita as informações armazenadas.

Modelo de objeto de documento ou XSS baseado em DOM

O DOM XSS é um tipo de ataque de script entre sites relativamente incomum. Diferentemente dos outros dois tipos de ataque (Reflected XSS e Persistent XSS), que têm como alvo o código do lado do servidor, um ataque DOM XSS explora vulnerabilidades de segurança no código do lado do cliente ou no código executado no navegador. Um ataque dessa natureza ocorre quando um aplicativo da Web processa dados JavaScript de uma fonte não confiável de forma insegura. Os ataques DOM XSS sempre ocorrem em JavaScript porque Java é a única linguagem que todos os navegadores entendem.

Métodos adicionais de classificação de XSS

É importante observar que, embora cada um desses três tipos de ataque seja distinto, eles não são exclusivos. Há alguma sobreposição entre cada categoria, em que os adversários podem empregar elementos de dois tipos de ataque em uma única ofensa.

Por esse motivo, a comunidade de segurança cibernética se refere aos ataques XSS com base no local em que o código é explorado: o servidor ou o cliente. Eles podem se referir a ataques como XSS de servidor ou XSS de cliente.

Como funciona o Cross Site Scripting?

Conforme observado na seção acima, a mecânica de um ataque XSS varia de acordo com o tipo de ataque que está sendo implantado. Dito isso, a maioria dos ataques segue o mesmo processo:

  1. O invasor identifica um local e um método para injetar código mal-intencionado em uma página da Web. Para que isso seja possível, o site deve permitir que os usuários adicionem conteúdo à página por meio de comentários, postagens ou campos de contato. Se o invasor tiver um alvo definido, ele empregará táticas de engenharia social, incluindo técnicas de phishing e spoofing para incentivar o usuário a visitar o site em questão. Caso contrário, o código é deixado para ser descoberto por qualquer usuário.
  2. A vítima visita o site com o código injetado. O dispositivo aceitará e executará o script infectado porque o considera parte do código-fonte de um site confiável. Como o código não é visível e a maioria dos usuários da Internet não entende linguagens de programação comuns, como JavaScript, é difícil para o usuário comum detectar ataques de XSS.

Diferentes abordagens de script entre sites

Um ataque de XSS pode ocorrer em qualquer lugar em que a entrada de uma solicitação HTTP possa ser inserida na saída HTML. Abaixo está uma lista de táticas comuns que os invasores podem utilizar em um ataque XSS:

Utilizar uma tag <script> para fazer referência, inserir ou incorporar código JavaScript mal-intencionado.

  • Exploit JavaScript event attributes, such as onload and onerror, within different tags.
  • Deliver an XSS payload within the <body> tag through JavaScript event attributes.
  • Exploit unsecured <img>, <link>, <div>, <table>, <td> or <object> tags to reference malicious script.
  • Leverage the <iframe> tag to embed a webpage within the existing page.

Quais são as ameaças do XXS?

Os ataques de XSS podem resultar em problemas significativos para as vítimas. Em casos extremos, os invasores de XSS podem aproveitar os cookies do usuário para se disfarçar como essa pessoa. O código também pode roubar arquivos e dados ou instalar malware no dispositivo.

No lado do servidor, os ataques XSS podem resultar em danos à reputação da organização anfitriã. Por exemplo, ao alterar o conteúdo de um site corporativo, os invasores podem espalhar informações incorretas sobre as práticas ou atividades comerciais da empresa. O adversário também pode manipular o conteúdo do site para fornecer instruções ou orientações incorretas aos visitantes. Ficar comprometido dessa forma é especialmente perigoso se os hackers puderem invadir sites ou recursos do governo durante eventos de emergência, acabando por orientar erroneamente as pessoas sobre como e onde proceder em tempos de crise.

Infelizmente, pode ser difícil identificar as falhas de XSS, principalmente se o usuário não tiver conhecimento de programação de computadores. Mesmo desenvolvedores habilidosos raramente verificam o código de sites confiáveis. Uma vez injetado, geralmente é muito difícil remover o código malicioso do aplicativo para ataques de XSS armazenado.

Como você pode evitar o cross site scripting?

É fundamental garantir que sua organização não esteja vulnerável a ataques XSS. Os ataques baseados em script e outros ataques sem arquivo aumentaram nos últimos anos porque podem evitar a detecção por ferramentas de segurança novas e antigas, inclusive software antivírus e firewalls.

Para manter um site seguro, as equipes da Web das organizações devem trabalhar de forma multifuncional com a equipe de segurança cibernética ou com um parceiro confiável de segurança cibernética para ajudá-las a avaliar o risco de ataques de XSS em seu site corporativo.

O gerenciamento de um site seguro no lado do cliente e do servidor normalmente requer uma solução de gerenciamento de vulnerabilidades para monitorar continuamente o site em busca de vulnerabilidades. Uma excelente maneira de fazer isso é adquirir um campeão de SecOps, alguém da equipe de segurança cibernética que trabalhará com desenvolvedores da Web e outros membros da equipe da Web para oferecer práticas recomendadas de segurança ao desenvolver e manter um site. 

Ao trabalhar com sua equipe de segurança cibernética, você deve considerar essas práticas para criar um ambiente da Web seguro e protegido:

  • Realize testes de penetração manual em áreas selecionadas que tenham grande chance de exploração.
  • Limite a capacidade dos usuários de enviar conteúdo para o site da empresa e outros recursos, como fóruns, blogs ou grupos de membros.
  • Se permitir entradas de usuários, filtre todo o conteúdo na chegada usando parâmetros rigorosos; codifique os dados no estágio de saída.
  • Evite que códigos maliciosos sejam injetados em respostas que não deveriam conter código HTML ou JavaScript.
  • Ofereça treinamento contínuo em segurança cibernética e oportunidades de desenvolvimento para a sua equipe de TI, bem como para desenvolvedores, programadores e engenheiros de computação, para garantir que eles estejam cientes dos riscos de XSS e possam abordá-los adequadamente por meio do design.
    Saiba mais.

FONTE:

Douglas Bernardini

Cybersecurity Specialist & Cloud Computing Expert with +10 years experience in IT infrastructure.

Specialist delivering assets for development teams in Google Cloud Platform (GCP) and Amazon web services (AWS)

Hands-on cloud security enterprise architect, with experience in SIEM/SOC, IAM, cryptography, pentest, network topologies, operating systems, databases, and applications.

Experience in DevSecOps analysis to discover vulnerabilities in software, identifying CI/CD risks gaps and recommending secure-coding process (S-SDLC).

PDF's