Vulnerabilidades em Aplicações Web
Como já foi dito, as vulnerabilidades acontecem devido a falta de uma boa programação. Os desenvolvedores de software simplesmente ignoram o fator segurança, fazendo seus programas com bugs os quais criam brechas que possibilitam invasões de pessoas más intencionadas.
Uma das últimas estatísticas feita pelo site The Web Application Security Consortium indicam que a probabilidade de se encontrar sites vulneráveis na Internet, é muito comum. De acordo com o gráfico abaixo podemos ver o percentual de vulnerabilidades encontrado nas Aplicações Web.
E para complicar ainda mais a situação, de acordo com o mesmo site, outro fator que dá origem as vulnerabilidades se deve a insuficiência na administração que é 20% maior do que nos códigos das aplicações, como pode ser visto pelo gráfico abaixo.
Das vulnerabilidades citadas acima, no primeiro gráfico, neste trabalho irei descrever o funcionamento de duas delas que são bastante exploradas pelos invasores, são elas: SQL Injection, XSS ou Cross-Site-Scripting. Não estarei explicando toda programação que está por trás delas, presumo que o leitor já tenha certo conhecimento básico que envolve sua teoria.
3.1.SQL Injection
Um ataque de SQL Injection consiste na injeção, ou inserção de comandos SQL numa consulta de entrada de dados cuja finalidade é manipular uma aplicação para tirar proveito de seu conteúdo para fins maliciosos. De acordo com The Open Web Application Security Project (OWASP), a definição completa de SQL Injection seria a seguinte:
Um ataque de injeção SQL consiste na inserção ou “injeção” de uma consulta SQL através de dados de entrada do cliente para o aplicativo. Uma exploração da injeção de SQL bem sucedida pode ler dados sigilosos do banco de dados, alterar dados do banco de dados (Insert / Update / Delete), executar operações de administração do banco de dados (como o desligamento do DBMS), recuperar o conteúdo de um determinado arquivo presente no sistema de arquivos do DBMS e, em alguns casos, executar comandos do sistema operacional. Ataques de injeção SQL é um tipo de ataque de injeção, em que os comandos SQL são injetados através do data-plane a fim de efetuar a execução de comandos SQL predefinidas.
(OWASP, 2010)
Sobre data-plane citado acima, um exemplo bem simples, seria a tela de login administrativo de um dado site.
3.1.1.Reconhecendo SQL Injection
A ideia do SQL Injection é provocar um erro na aplicação fazendo com que a mesma retorne algum dado que seja útil para o atacante. Vejamos como se da o seu funcionamento. Analisando a consulta abaixo:
SELECT login, senha FROM administrador;
Esse tipo de consulta pede para retornar o login e senha da tabela administrador. Tal consulta poderia ser mais refinada utilizando a cláusula WHERE, desta forma:
SELECT login, senha FROM autores WHERE nome = ' ';
Aonde no nome poderíamos inserir a palavra ‘admin’, um tipo string, ficando assim:
SELECT login, senha FROM autores WHERE nome = ' admin';
Note que esse tipo de consulta ocorre no navegador, na hora que se está digitando na tela de login da administração, algo como a Figura abaixo:
Figura : Exemplo de tela de login de um site.
Vamos provocar um erro na aplicação, inserindo o seguinte, ‘ad’min’:
SELECT login, senha FROM autores WHERE nome = 'ad'min';
Agora esse tipo de consulta irá retornar um erro, pois o SQL vai interpretar somente ‘ad’, que está dentro dos apóstrofos, e o min’ ele não reconhece, ou seja, não é um identificador válido, sendo que não será executado, retornado um erro de sintaxe visto no navegador.
Figura : Erro de sintaxe: vulnerável a SQL Injection
Com base nisso, o atacante poderá manipular a aplicação, entrando com dados que tiram proveito de algum comportamento não esperando pelo banco de dados.
Uma string muito utilizada nesse tipo de ataque é: ‘ or 1=1–
Vejamos como ficaria na consulta:
SELECT login, senha FROM autores WHERE nome = 'admin' AND senha = '' or 1=1--'
Ou
SELECT login, senha FROM autores WHERE nome = '' or 1=1--' AND senha = '' or 1=1--'
Como funciona então essa consulta com a string ‘ or 1=1–. O apóstrofo inicial fecha a variável nome deixando-a em branco, ou seja, o banco de dados não saberá o que fazer com ela; depois a string direciona a uma afirmação em or 1=1, ou seja, ou verdadeiro é sempre verdadeiro, ora se é sempre verdadeiro então o banco de dados deve aceitar; e quanto aos dois traços (–) no final da string, eles indicam um comentário, assim tudo que vir depois dos dois traços é comentário e o banco de dados deve ignorar. O efeito disso é que atacante entre na aplicação e o pior, direto no usuário root, o administrador do sistema.
3.2. Cross-Site-Scripting ou XSS
Assim como o SQL Injection o XSS utiliza do mesmo artifício, injeção de códigos maliciosos via navegador, utilizando, mais comumente, a liguagem de programação JavaScript. Tais códigos maliciosos são inseridos em sites, ficando com um link exposto a espera de algum usuário desatento clicar nele, é como lançar um anzol no mar. A intenção dos atacantes é roubo de cookies, que é um conjunto de dados trocado entre o navegador e o servidor do site acessado e que é guardado no computador do usuário em um arquivo cujo formato é texto. Nos cookies temos informações do usuário como login e senha, o que permite o atacante, utilizando do cookies, entrar no site como se fosse o usuário que clicou no link. Imaginem se o site for um banco! Outra função deste ataque é ganhar privilégios administrativos em áreas do site que não possuem nenhum privilégio, chamado de Escalonamento de Privilégio.
3.2.1.Reconhecendo o XSS
Normalmente o atacante procura páginas que possuam entradas de dados para pesquisar no site, ou então deixar algum comentário, ou seja, os formulários e é através desses pontos de acesso que ele teste se o site está vulnerável a XSS.
Neste exemplo estarei fazendo um teste no site de um colega (Figura abaixo), aonde tal vulnerabilidade já fora constatada por mim e ele me autorizou em usá-lo como demonstração neste artigo. Mesmo assim, estarei ocultando qualquer evidência que possa identificar o site.
Figura acima: Portal de um site.
Vamos usar o campo busca do site e injetar o seguinte código:
<script>alert(“XSS”)</script>
Se o site “responder” com uma caixa de mensagem inscrito XSS, então ele é vulnerável a esse tipo de ataque. Vamos ver então o que acontece:
Figura 5: Constatação de XSS.
Ao clicar no botão “buscar” temos o surgimento da caixa de mensagem, portanto o site está vulnerável a XSS. A partir daí o atacante pode inserir links redirecionando a sites falsos, a malware, pode mudar a interface inicial do site (defacement), pode realizar roubos de cookies de usuários cadastrados enfim, vai depender do objetivo da pessoa.
4.Prevenção
De tudo que foi exposto acima podemos perceber que a melhor maneira de prevenir tais ataques deve ser feito no ato da inserção dos dados pelo usuário. Assim quando este pressionar a tecla Enter, para enviar seus dados através do formulário do site, por exemplo, esses dados devem ser verificados pela aplicação, antes de serem aceitos. Logo abaixo descrevo como isso pode ser feito.
Para prevenir de SQL Injection uma boa pratica de programação é limitar o acesso do usuário no site em certas áreas do mesmo. Por exemplo, se o usuário quiser fazer uma compra, ele deve ter acesso a uma determinada área do site que o permite fazer somente isso.
Validar os dados de entrada feitos pelo usuário, isso é extremamente importante. Um exemplo bem prático: num campo do site aonde permite a entrada de dados somente numéricos a aplicação deve verificar que realmente os dados inseridos pelo usuário são apenas números.
Também habilitar funções como e addslashes(), stripslashes(), mysql_real_escape_string() previnem ataques de SQL Injection.
Quanto a XSS a ideia é basicamente a mesma, mas de outra forma. A melhor maneira a ser tomada é tratando as entradas do usuário com um filtro, não permitindo o uso de tags em HTML, pois a inserção das mesmas podem ter incluso códigos em JavaScript; também códigos em hexadecimal e o JavaScript puro.
5.Conclusão
Aplicações Web são muito eficientes e funcionais, sem elas seria praticamente impossível navegar por toda Internet sem muito esforço, podemos dizer que elas são o trampolim entre o usuário final e seus desenvolvedores.
Vimos, nesse trabalho, que o número de usuários cresce exponencialmente na Internet e que as aplicações Web têm um papel fundamental nesse meio. Desta forma foi descrito seu funcionamento e que são feitas por desenvolvedores/programadores. Tanto os erros de programação como de administração deixam as aplicações Web vulneráveis, nesse artigo vimos somente duas delas: Cross-Site-Scripting (XSS) e SQL Injection. Conhecemos como elas podem ser detectadas por usuários mal intencionados e, por conseguinte, foi exposto, de maneira simples, como um desenvolvedor pode se prevenir de tais ataques, utilizando algumas funções em seus códigos e validando entradas dos usuários assim como restringir o uso de códigos por parte deles.
Apesar dos alertas que se tem feito nos meios de comunicação pela Internet, os ataques ainda são muito comuns. Desenvolvedores e usuários ainda não se conscientizaram que a simples prática de boas condutas de segurança pode livrá-los de uma enorme dor de cabeça.
Esse artigo tem como objetivo principal, enfatizar o uso da boa prática de programação para com seus desenvolvedores, alertar os administradores para que façam uma administração consciente em seus sites e sensibilizar os usuários que, assim como no mundo real, estamos expostos as nossas fraquezas dentro do mundo virtual.