Que o Google é uma ferramenta poderosa e que ajuda muita gente nós sabemos, porém, o Google, quando bem (Ou mau) utilizado (Dependendo do Objetivo e Alvo) pode trazer sérias consequências na vida de alguém.
O Google é uma ferramenta de pesquisa, você pode pesquisar TUDO lá. Você, inclusive pode pesquisar “Calcanhar de maracujá” no Google Imagens! Fantástico, não?! Brincadeiras de lado, vamos colocar nosso coletinho escrito “Security” e vamos olhar o Google de uma outra forma...
Acho que todo mundo (Senão, grande parte) das pessoas que começaram a estudar Desenvolvimento Web já ouviu falar em SQL Injection, certo? Se você faz parte da minoria que não sabe o que é SQL Injection eu vou dar uma leve explicação:
- Como o próprio nome diz, SQL Injection é o tipo de ataque onde o atacante consegue inserir códigos SQL em um banco de dados, sendo assim, ele pode “só” trocar a senha do usuário [email protected] para “Noob123”, ele pode colocar uma Shell no seu servidor, baixar um exploit, executar e rootar tudo (Hackademic mandou lembranças).
Sentiram a gravidade da situação, né? SQL Injection, pelo menos agora não é o foco do artigo.
Quando eu comecei a estudar Segurança da informação, sempre via aqueles dorks que você jogava no google e tinha acesso a uma porrada de áreas administrativas.
Um exemplo de dork é ir no Google e pesquisar: allinurl: /admin/login.php e verá quantas pessoas não configuraram o robots.txt direito.
Lembro-me que uma vez eu invadi um servidor de ragnarok com usando o seguinte dork:
Site:site.com filetype:txt
Ele listou alguns *.txt’s e em um deles estava o diretório de uma pasta, e dentro dessa pasta tinha um arquivo e nesse arquivo tinha a senha do banco de dados e no banco de dados tinha os dados de todas as contas (Mas acabei nem fazendo nada, alertei o dono do servidor e hoje considero ele um dos meu melhores amigos :])
Seguindo este mesmo Dork, eu pensei em um site grande... Por que não o G1?
Fui no Oráculo e digitei:
site:g1.globo.com filetype:txt
Não encontrei nada de interessante e continuei a minha busca:
site:g1.globo.com filetype:sql, site:g1.globo.com filetype:php, site:g1.globo.com filetype:asp… Até que:
XSS (Cross-Site Scripting), análise de caso do Submarino.com.br
É muito comum encontrarmos sites com Vúlnerabilidades, seja XSS (Cross-Site Scripting), SQL Injection, XSRF, só esperando para que um l33t0 tenha acesso.
Toda vez que desenvolvo um site e/ou sistema, tomo cuidados com o tratamento das variáveis. E, depois de finalizado, realizo alguns testes ou peço para o Rodrigo tentar invadir :P
Sempre gostei da área de segurança da informação, porém, sempre me foquei na parte de Segurança Web, apesar de ter um pequeno (Bem pequeno mesmo) conhecimento em Vúlnerabilidades ‘Desktop’ (Já brinquei com Buffer Overflow e DLL Hijacking).
Hoje vou falar sobre o XSS ou Cross-Site Scripting ou CSS. O Webkit possui um filtro Anti-XSS, porém, é bypasseável.
O XSS permite que o atacante insira Códigos Javascript na página do usuário.
Existem 2 tipos de XSS:
- XSS Reflected
Um exemplo de XSS Reflected é:
Você tem um site que recebe um parâmetro($_GET) X, a url fica +/- assim:
http://www.site.com/pagina.php ?X=foo
Vamos supor que você seja um programador PHP e está desenvolvendo algo assim:
<?php
Echo ‘Seu nome é ‘.$_GET[‘nome’];
?>
Agora, sua URL está assim:
http://www.site.com/pagina.php?nome=Gustavo
A página vai retornar:
Seu nome é Gustavo
Agora, se alguém colocar um código javascript nessa página, o código javascript será interpretado pelo navegador (Atualmente o Chrome, Safari, etc... Possuem um XSS Filter, porém, vou ensinar como bypassear.), ficando assim:
http://www.site.com/pagina.php?nome=<script>alert(‘PEGADINHA DO MALANDRO!’);</script>
Seu navegador irá interpretar o código Javascript, mostrando o alerta “PEGADINHA DO MALANDRO!”.
Esse tipo de ataque é conhecido como XSS Reflected.
O XSS Stored é aquele onde qualquer pessoa que entre no site verá o alert ou, se o atacante preferir, pode até fazer um cookie logger.
Vamos supor que você tenha um sistema de comentarios que executa uma Query no banco, ele ‘pega’ os comentários do banco e exibe-os na tela do usuário. Se você não tratar a variável corretamente, todos os usuários que visitarem o site verão o alert() que o atacante l33t0 colocou no seu site.
Agora que expliquei mais ou menos o que é XSS, vamos ao problema:
Vamos para uma situação hipotetica:
Você, hipoteticamente recebe o link de um amigo hackudo mestre no havij falando sobre uma super promoção do iPhone 4. (Ainda na situação hipotetica, você tenha sido assaltado no começo de Setembro, onde, no assalto, levaram seu iPhone 4 e você esteja louco procurando por um celular para comprar.)
Então, esse amigo te envia um link do http://www.submarino.com.br, um E-commerce grande e com um grande conceito. Um link como esse:
Agora vamos arregaçar as mangas, colocar um coletinho escrito “Security”, ligar a sirenezinha de vigilante (Essa: http://www.youtube.com/watch?v=CcOhdcRQwU0) (Especialmente pro pessoal da Goup Comunicação!), apagar as luzes e começar o trabalho sujo!
Lembram o que eu disse sobre o XSS Reflected? (Se não lembram, está ai em cima! :D)
Vamos lá:
Reparem no parâmetro “callback”. Eu consegui inserir um código HTML inocente lá, vamos começar a inserir códigos javascript.
(Se você usa o Firefox, colocar um <script>alert(1);</script> no callback já vai aparecer um alerta 1 no seu navegador.)
Pronto! Você tem um Frame com a URL Original, você pode colocar até colocar a url daqueles vídeos de susto para enganar os seus amigos, ou usar a criatividade e fazer algo mais legal...
Obs: O Submarino.com.br JÁ FOI ALERTADO SOBRE ESSA VÚLNERABILIDADE, PORÉM, NÃO OBTIVE RESPOSTA.
