Cross-Site Scripting (XSS) é um ataque cibernético no qual um hacker insere código malicioso em um formulário da web ou url de um aplicativo da web. Esse código malicioso, escrito em uma linguagem de script como JavaScript ou PHP, pode fazer qualquer coisa, desde destruir a página que você está tentando carregar até roubar suas senhas ou outras credenciais de login.

O XSS faz uso de um aspecto importante da internet moderna, que é o fato de que a maioria das páginas da web são criadas enquanto as páginas estão sendo carregadas, às vezes executando código no próprio navegador. Isso pode dificultar a prevenção de tais ataques.

Confira também:

Como funciona um ataque XSS?

Qualquer pessoa pode criar um site que contenha código malicioso. No caso de um ataque de script entre sites, o invasor organiza tudo para que seu código chegue ao computador da vítima quando ela visitar o site de outra pessoa. É daí que vem a “cruz” no nome. Os ataques XSS conseguem isso sem exigir acesso privilegiado a um servidor da Web para colocar código clandestinamente. Em vez disso, os invasores aproveitam a maneira como os sites modernos funcionam.

Se alguém lhe pedisse uma explicação simples e básica de como a web funciona, você provavelmente poderia dizer algo assim: a pessoa que deseja criar uma página da web escreve um documento HTML e o coloca em um servidor web; Quando o usuário deseja acessar esta página, ele direciona seu navegador para o endereço do servidor, o navegador baixa e interpreta o código HTML e constrói uma cópia da página web do usuário.

Esta descrição não está errada, mas alguns aspectos estão desatualizados (e existem há mais de dez anos). Primeiro, muitas, se não todas, as páginas da web são dinâmicas hoje – ou seja, elas não exibem o mesmo HTML estático para todos os visitantes, mas são geradas instantaneamente a partir de informações no banco de dados do servidor quando o navegador solicita acesso. A página que o navegador recebe do servidor geralmente depende das informações enviadas com a solicitação – informações que às vezes assumem a forma de parâmetros na URL usada para acessar o site. Os sites não consistem apenas em HTML e Cascading Style Sheets (CSS) que descrevem como exibir texto e gráficos, mas também contêm código executável escrito em linguagens de script, geralmente JavaScript.

Em um ataque XSS, o hacker usa essa interação entre o usuário e o site para executar código malicioso no computador do usuário. mas como? Considere o seguinte URL:

https://www.google.com/search?q=CSO+online

Digite isso na barra de endereços do seu navegador e você verá os resultados de pesquisa do Google para “CSO Online”. Na verdade, a página que você verá é exatamente a mesma que teria digitado “CSO Online” na barra de pesquisa do seu navegador ou na página inicial do Google. Você notará, entre outras coisas, que essa frase aparece em vários lugares da página, inclusive na barra de busca nas montanhas:

E se, em vez da frase inocente e bem-sucedida “CSO online”, esse URL contivesse um código JavaScript malicioso como este?

https://www.google.com/search?<script>doEvil()</script>

doEvil() faz um trabalho muito ruim aqui. Você pode estar preocupado que o Google, em vez de exibir “CSO Online” na página que você está retornando deste URL, integre dinamicamente o javascript incorreto na página que você está renderizando e que esse script esteja sendo executado em seu navegador , causando confusão. Suas preocupações serão infundadas, porque o Google tem um número muito grande de profissionais de segurança de TI talentosos entre seus funcionários e implementou medidas corretivas sobre as quais falaremos um pouco mais tarde. No entanto, nem todo site é muito cuidadoso e isso dá uma ideia de como esses ataques funcionam.

Ataki XSS

Os ataques XSS se enquadram em várias categorias: ataques refletidos, ataques baseados em DOM e ataques armazenados. Veja como eles diferem:

• Ataques reflexos: também conhecidos como ataques fracos, o código JavaScript malicioso é enviado do navegador da vítima para o Google, depois refletido de volta em um formato executável, nunca armazenado nos servidores do Google. Esses ataques geralmente fazem parte de um esquema de phishing, em que o link malicioso é disfarçado como algo mais divertido e enviado à vítima por e-mail ou SMS.
• Ataques baseados em DOM: Este é um tipo de ataque reflexo chamado Document Object Model, que é uma API padrão que define como os navegadores constroem uma página da Web a partir de código HTML ou JavaScript básico. A maioria dos ataques DOM é semelhante ao ataque reflexo descrito anteriormente, com a diferença de que o código malicioso nunca é enviado ao servidor: em vez disso, é passado como parâmetro para alguma função JavaScript que é executada no próprio navegador, o que significa que os mecanismos de proteção no lado do servidor são incapazes de proteger o usuário. Se você estiver interessado nos detalhes, o PortSwigger tem uma descrição mais detalhada de como os ataques DOM funcionam.
• Ataques armazenados: de outra forma persistentes; O invasor usa os recursos interativos do site para salvar códigos maliciosos no servidor da web. Em um exemplo típico, o invasor deixa um comentário em uma postagem de blog que contém JavaScript malicioso. Na próxima vez que alguém carregar esta página, o código será executado.
• Vulnerabilidade ao ataque XSS

O que torna um site vulnerável a um ataque XSS? Esperamos que nossa discussão até agora tenha fornecido alguma orientação. Se o seu aplicativo da Web ingenuamente receber a entrada do usuário, não verificar se há código executável mal-intencionado e usar esses dados para renderizar uma página ou executar outras operações, ele estará vulnerável a esse tipo de ataque.

E os riscos são grandes. O principal aspecto da segurança do navegador é a chamada política de mesma origem, que afirma que um script executado em uma página pode acessar dados na outra página somente se ambos os lados tiverem a mesma origem (definida como uma combinação de URI, nome do host, e porta numérica). No entanto, se o JavaScript malicioso puder ser executado no navegador enquanto a vítima estiver acessando o site, o navegador permitirá que o JavaScript acesse dados de outros sites que compartilham um recurso com o site vulnerável. O JavaScript pode acessar cookies e outras informações de sessão proprietárias, o que é uma boa receita para hackear as contas de internet das vítimas.

Payloads XSS

Na linguagem do malware, uma carga útil é um código executável que executa as ações exigidas pelo invasor. No caso de um ataque XSS, a carga útil é um código de script que o invasor executa para enganar o navegador da vítima e fazê-lo ser executado.

Há uma lista enorme de modelos de carga útil XSS no repositório Payloadbox no GitHub. Se você estiver familiarizado com JavaScript, revisá-lo pode lhe dar uma ideia de como os invasores XSS fazem seu trabalho sujo. No entanto, um ataque XSS vai além de recortar e colar a carga útil na URL: o invasor precisa entender as funções e vulnerabilidades específicas do aplicativo da Web que deseja explorar para planejar o ataque. Se você quiser se aprofundar e ver alguns exemplos de ataques XSS, confira o site OWASP XSS para uma visão detalhada do código do script que demonstra um ataque XSS.

Proteção e Prevenção XSS

Se você estiver criando ou mantendo um aplicativo da Web ou um site interativo, há três técnicas principais que você deve considerar em seu design para evitar possíveis ataques de script entre sites.

• Esterilização dos dados de entrada. A resposta óbvia para evitar que código malicioso seja passado como entrada e devolvido ao usuário é simplesmente não aceitar código de script como entrada. Você definitivamente deve filtrar sua entrada com isso em mente, mas é mais fácil falar do que fazer; Pequenos pedaços de código executável podem passar por filtros. Uma maneira de lidar com esse problema é usar uma lista branca em vez de uma abordagem de lista negra – por exemplo, em vez de tentar escrever um filtro que bloqueie todos os códigos maliciosos que estão sendo alimentados em um formulário da Web, você precisa escrever seu aplicativo para aceitar o dados em determinados momentos Formatos (números de telefone, endereços de e-mail, etc.) somente quando é isso que você deseja.
• Fuja da saída. Esta é a solução para o problema, por outro lado. Se um aplicativo da Web enviar a entrada do usuário de volta para uma página da Web, esses dados deverão ser filtrados para garantir que não se tornem executáveis ​​nessa página. Se o usuário inserir tags HTML como entrada, o aplicativo deverá usar caracteres substituídos para que essas tags apareçam como texto na página de resultados em vez de se integrarem ao HTML da própria página.
• Política de segurança de conteúdo padrão (CSP). O CSP adota a abordagem de “lista branca” fora da entrada de texto no domínio do script: um aplicativo da Web deve executar apenas o código que o usuário especificou para ser seguro. O Google tem ótimos recursos para implementar o CSP.

teste XSS

O teste de vulnerabilidade para ataques XSS é um aspecto importante para garantir a segurança de um aplicativo da web. OWASP possui recursos que detalham como os aplicativos podem ser testados para evitar ataques DOM ou scripts entre sites reversos. Se você estiver procurando por uma planilha XSS, o OWASP também tem um documento com código de ataque XSS para você que pode ser usado para contornar alguns filtros de defesa XSS; Será inestimável nos testes de penetração que você pode realizar em seus próprios sistemas.

XSS e CSRF

Você pode ouvir que o CSRF é usado no mesmo contexto que o XSS. É a abreviação de Cross-Site Request Forgery, um ataque – como o XSS – que tem como alvo o navegador de um usuário. A principal diferença é que o CSRF usa uma sessão autenticada para o usuário (talvez ele esteja logado em sua conta bancária), enquanto o XSS não precisa de uma sessão autenticada para ser eficaz.

Digamos que um usuário esteja conectado ao Twitter e a um banco de internet ao mesmo tempo e clique em um link do Twitter parecido com este:

http://www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000

Dependendo da maneira como seu banco gerencia os tokens de sessão e o navegador que você está usando, eles podem ficar muito mais pobres de repente. XSS é um vetor de ataque mais perigoso, mas é importante se defender contra XSS e CSRF. O OWASP preparou uma ficha informativa sobre medidas de proteção contra CSRF.

Ataques XSS recentes e infames

Um dos mais antigos e famosos ataques de cross-site scripting ocorreu em 2005, quando o usuário empreendedor do MySpace Sammy Kamkar percebeu que poderia inserir código JavaScript em seu perfil que autenticaria automaticamente qualquer pessoa que visitasse o site – e também copiar esse código para os perfis de seu novos amigos, Graças a isso, todos que visitarem estas páginas também serão seus amigos. (O roteiro garantiu que cada um dos novos amigos de Kamkar chegasse ao “top oito” – temos medo de entender isso, você teria que estar lá, mas acredite, isso importava.) Em 24 horas, ele fez mais de um milhão de amigos e forçou o MySpace a fechar o site inteiro por um curto período de tempo.

Acontece que o chamado worm Sami é praticamente inofensivo. No entanto, outros foram mais irritantes:

• O Ebay teve vulnerabilidades XSS por anos que permitiram que hackers roubassem credenciais de login do usuário

• Os atacantes XSS conseguiram roubar V-Bucks dos jogadores do Fortnite em 2019.

• O grupo de hackers Magecart atacou a British Airways em 2018 com um ataque XSS, roubando centenas de milhares de identidades de usuários

E o script entre sites continua sendo uma séria ameaça hoje. A partir de 2021, vulnerabilidades XSS foram encontradas na plataforma de e-mail Zimbra, Wordpress e na plataforma de gerenciamento de TI de código aberto Nagios. Lembre-se de que os hackers geralmente não usam técnicas de ataque isoladamente: o script entre sites é um componente de uma forma complexa recentemente descoberta do ataque curinga TLS conhecido como ALPACA. Para evitar ameaças perigosas, certifique-se de fechar as vulnerabilidades XSS.

Fonte: CSO