Com minha exposição limitada à segurança cibernética e a ampla gama de tópicos que abrangem esse campo, minha curiosidade só aumentou com o passar dos anos. Ao filtrar artigos e diferentes fontes de pesquisa, quis compartilhar e documentar um pouco mais minha jornada para entender os ataques cibernéticos. Hoje, vamos dar uma rápida olhada juntos em um dos ataques cibernéticos mais comuns: cross-site scripting (XSS).

O que é Cross-Site Scripting (XSS)?

Cross site scripting , também popularmente conhecido por sua sigla, XSS, é um ataque no qual um invasor “injeta” scripts executáveis ​​maliciosos no código de um aplicativo ou site confiável.

De acordo com os relatórios estatísticos do Edge Scan, os aplicativos da web são os de maior risco para esses tipos de ataques.

Como esses ataques são permitidos?

Algo que sempre me perguntei foi: “Bem, como diabos esses ataques são permitidos em primeiro lugar?”. Esses ataques podem ocorrer por meio da manipulação de solicitações e respostas HTTP ou do DOM. Se não houver protocolos de segurança para validar ou verificar os dados que são passados ​​por solicitações/respostas HTTP ou mesmo para o DOM, você corre o risco desses ataques XSS.

Como o XSS funciona: uma visualização

• Os hackers estão atentos às vulnerabilidades do site, nas quais podem se intrometer no seu código. Se o seu site não tomar medidas preventivas para se proteger, os hackers podem aproveitar esses espaços desprotegidos para injetar seus scripts maliciosos.
• Se os scripts forem colocados com sucesso, os scripts do invasor serão acionados.

• As informações pessoais são enviadas ao hacker.
• As teclas digitadas pelo usuário são capturadas.
• Um usuário é redirecionado para um site malicioso.
• As informações do cookie são obtidas de um usuário, que está conectado a um site (comprometendo assim a conta da vítima).

• Ataque XSS refletido
• Ataque XSS armazenado
• Ataque baseado em DOM

Os ataques refletidos envolvem a entrada de uma solicitação HTTP sendo imediatamente refletida como uma resposta. Um exemplo simples pode ser demonstrado se alguém injetar esses ataques de script dentro do campo de pesquisa de um formulário. Depois que um usuário “clica” em enviar, o navegador reconhece essa entrada como HTML, não vê nada malicioso nela e continua a executar esse script malicioso de qualquer maneira. O código injetado viaja para o site que o usuário está acessando. O ataque, então, aparece no navegador do usuário (OWASP).

Abaixo está um exemplo disso. Um invasor insere um script malicioso no campo de pesquisa do site e, como resultado, uma caixa de diálogo de alerta aparece com a inscrição “xss”. Obviamente , existem mais intenções maliciosas do que um invasor querendo que uma caixa de alerta apareça em sua página, mas este exemplo demonstra como é fácil executar esses scripts injetados.

Observação: os ataques refletidos NÃO são salvos permanentemente e NÃO são persistentes. Eles não vivem em um aplicativo. Os ataques refletidos geralmente ocorrem quando um usuário abre um link suspeito ou abre uma determinada página da web.

Sinais de um link XSS:

• Um invasor chama emocionalmente a atenção do leitor, inventando os piores cenários que deixam a pessoa muito curiosa para clicar, o que pode ser ilustrado na figura acima.
• Há uma URL abreviada que imita as URLs de uma empresa confiável. Isso faz com que um usuário inexperiente se sinta autêntico, esperando que o link redirecione para a página dessa empresa.
• No entanto, esse link não redireciona para o vídeo do TikTok e, em vez disso, as informações do cookie do usuário foram roubadas, dando a um invasor acesso ao login do usuário.

Os ataques armazenados “armazenam” scripts injetados em locais, como um banco de dados ou um servidor, e usam esses dados posteriormente em uma resposta HTTP. Esses scripts injetam diretamente em um aplicativo da web. Um exemplo é quando um site permite que você escreva um comentário. Depois de enviar seu comentário, o site armazena seus comentários em seu servidor/banco de dados. Assim, um invasor pode armazenar seus scripts no banco de dados de um site comentando. Portanto, quaisquer outros usuários que navegam nessas páginas que exibem esses comentários estão executando inadvertidamente esses scripts que são salvos e armazenados no banco de dados.

Observação: os ataques armazenados são salvos permanentemente e são persistentes . Eles também são conhecidos como “XSS persistente” e são conhecidos por serem mais prejudiciais do que os ataques refletidos (Imperva.com). Eles vivem em um aplicativo e podem ter efeitos duradouros.

Ataque XSS baseado em DOM

O DOM é uma API da web. Em essência, é apenas uma forma de estruturar e uma representação de como uma página da web aparece. Linguagens de script, como Javascript, usam o DOM para manipular elementos DOM que alteram sua estrutura, estilo e aparência de uma página da web. Isso é vital para editar páginas da web.

Devido à sua natureza facilmente acessível, ele vem com implicações que permitem outra forma de XSS: ataques baseados em DOM. É importante observar que os ataques XSS baseados em DOM são diferentes dos ataques XSS refletidos e armazenados, pois eles “não tocam o servidor web”, enquanto os ataques XSS refletidos e armazenados o fazem.

No entanto, os ataques baseados em DOM podem ser vistos como uma subclasse de ataques refletidos, pois refletem uma resposta imediatamente, mas no código do lado do cliente. (Wikipédia).

Taint Flow e XSS baseado em DOM

Taint-flow é uma maneira de visualizar o XSS baseado em DOM. Taint-flow é o processo de fluxo de dados corrompidos para o seu corpo de código, por meio de dois termos-chave: fontes e coletores .

As fontes permitem a entrada de dados contaminados. Gosto de usar analogias, então gosto de imaginar as fontes como um portal ou uma entrada. Alguns exemplos bem conhecidos incluem: document.cookie, document.URL, localStorage, sessionStorage.
“ Em última análise, qualquer propriedade que possa ser controlada pelo invasor é uma fonte potencial” (Portswigger.net).

Os coletores executam dados fornecidos pela fonte. Alguns exemplos bem conhecidos incluem: document.write , document.body.innerHTML, setTimeOut. Um coletor comum para injeção de JavaScript é: eval . Os dados que foram inseridos da fonte são usados ​​como entrada para um coletor e o coletor executa a si mesmo .

Conclusão

Ao todo, XSS é o processo de injeção de scripts com intenção maliciosa. As solicitações e respostas HTTP são importantes para entender como ocorrem os ataques refletidos e armazenados, enquanto a manipulação de DOM e o fluxo de contaminação são processos-chave para entender como o XSS baseado em DOM ocorre.

As principais diferenças entre cada ataque é que os ataques XSS refletidos envolvem a entrada de uma solicitação HTTP sendo imediatamente refletida como uma resposta em seu navegador, enquanto os ataques XSS armazenados “armazenam” essa entrada em algo como um banco de dados externo e, em seguida, usam esses dados posteriormente em um Resposta HTTP. Os ataques baseados em DOM envolvem scripts maliciosos sendo injetados no DOM e são uma subclasse de ataques refletidos.

Ataques refletidos são mais comuns, mas ataques armazenados são mais prejudiciais.

É importante considerar proteger seus aplicativos para evitar esses tipos de ataques que podem economizar ginástica mental e aliviar sua mente.

Fontes

https://portswigger.net/web-security/dom-based#:~:text=The%20Document%20Object%20Model%20(DOM,of%20how%20modern%20websites%20work

https://www.imperva.com/learn/application-security/cross-site-scripting-xss-attacks/#:~:text=Stored%20XSS%2C%20also%20known%20as,application%2C%20onto%20a%20user's%20browser.