E ai pessoal!
Como eu comentei no post Introdução à Segurança da Informação - Parte 10, vou fazer uma subsérie de posts com algumas práticas para mostrar como funcionam as principais vulnerabilidades na visão da OWASP.
Antes de começar tenho que avisar que este é a lista de 2010 não esta nova de 2013, acho que as aplicações vulneráveis de teste ainda não atualizaram as mudanças, mas como é pouca a diferença podemos nos basear muito bem por aqui. Estou usando a aplicação de testes também da OWASP a Multillidae que tem uma boa base para quem está começando, com dicas nas páginas vulneráveis, e também para os mais experientes, pois essas ajudas e a complexidade da falha podem ser alteradas.
Como comentado no post anterior dessa série, quando se fala em injection vem logo a cabeça o SQL Injection. Como estamos falando de Introdução à Segurança da Informação, podemos começar por ele mesmo, vou mostrar aqui alguns modos de atacar um site por SQL Injection.
Eu já postei aqui um paper em várias partes chamado "Pentest em sites com Metasploit", que o objetivo era mostrar como era possível fazer um pentest completo em uma aplicação web apenas com o Metasploit, mas o motivo de estar citando aqui essa série é porque em algumas partes eu citei o sqlmap e até foi mostrado como usa-lo para atacar falhas de SQL Injection. Se você já tem um conhecimento prévio recomendo dar uma olhada lá, caso esteja realmente iniciando agora recomendo que guarde esse link para depois e continue sua leitura aqui neste post.
Vamos ver algo bem básico neste post sobre SQL Injection.
Basicamente, as vulnerabilidades de Injection acontecem quando você pode passar todas as proteções e mandar códigos para serem executados no servidor ou banco de dados. No nosso caso aqui, vamos mandar alguns códigos para o servidor na hora da verificação de autenticação que vai nos liberar acesso a uma área restrita do site, logar sem ter um usuário e senha.
Para facilitar a explicação, deixei na dificuldade mínima e dicas habilitadas.
Neste caso temos o formulário de login, um teste básico que podemos fazer é colocar um apóstrofo no campo e enviar e ver o que acontece. Em muitos casos onde ha a vulnerabilidade as saídas de erro não são tratadas corretamente e acabam aparecendo na página.
No caso de um site real vulnerável você receberia uma página em branco ou a mesma página com a mensagem "/owaspbwa/owaspbwa-svn/var/www/mutillidae/classes/MySQLHandler.php on line 108: Error executing query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '''' AND password=''' at line 1 () (0) [Exception] " aparecendo em algum lugar. As outras informações são as dicas do Mutillidae.
Com isso temos, pegue tudo da tabela accounts onde o usuário é vazio ou 1 é igual a 1 e a senha é vazio ou 1 é igual a 1 e ignore todo o resto (os dois traços). Lembram-se acima quando eu falei que o banco checaria e por não ter a combinação de usuário/senha ele retornaria "false"? E agora, o que você acha que ele vai retornar? "True"! Isso mesmo, por mais que ele não encontre as credenciais que eu passei ele sempre vai cair na verificação de que 1 é sempre igual a 1, por isso retorna "true" e nos autentica:
E ai está! Conseguimos os detalhes das contas cadastradas no site.
Mas não paramos por aqui, ainda temos algumas coisas a ressaltar. Não será em todos os casos que isso vai funcionar, os comandos variam com a linguagem que o banco de dados usa, veja abaixo algumas outras possibilidades:
Mas não pare por ai! Se nada der certo, procure forçar um erro para ter uma pista de qual banco de dados está sendo usado, com essa informação procure como que aquele banco em específico trata os comandos e entradas e use sua imaginação para bolar uma injeção de código. Nem sempre pegar o que já está pronto pode te ajudar.
Agora uma coisa muito interessante que poucos se preocupam em falar, como podemos proteger os sites de Injection? Mais simples do que você imagina, ou não depende da complexidade da sua aplicação. A regra mais importante aqui é "trate todo a entrada como maliciosa", com isso em mente você poderá prever todas ou boa parte das possibilidades. Avalie, filtre e trate antes de chegar ao banco de dados. Existem algumas funções já prontas, como o Magic Quotes por exemplo, que prometem filtrar esses parâmetros, não sou a melhor pessoa para falar sobre isso porque não sou programador, mas recomendo que procure mais sobre isso.
Não preciso comentar em manter sempre tudo atualizado e regularizado, isso pode não resolver, mas pode diminuir o estrago ou até mesmo diminuir a quantidade de informação vazada.
E para finalizar, um ultimo ponto que considero interessante é a utilização de um WAF (Web Application Firewall), que vai detectar essas ameaças e cortar a conexão antes que um dano maior ocorra, e um concelho, não mostre mais do que o necessário, trate todos os erros que sua aplicação pode gerar.
Eu fico por aqui depois desse longo post, espero que tenham entendido e gostado, porque querendo ou não tem pelo menos mais 9 desses vindo por ai :)
Também indico que baixem e testem o Multillidae, que tem várias situações para você tentar resolver que sem dúvida vão refinar seu conhecimento.
Bons estudos e até a próxima!
Como eu comentei no post Introdução à Segurança da Informação - Parte 10, vou fazer uma subsérie de posts com algumas práticas para mostrar como funcionam as principais vulnerabilidades na visão da OWASP.
Antes de começar tenho que avisar que este é a lista de 2010 não esta nova de 2013, acho que as aplicações vulneráveis de teste ainda não atualizaram as mudanças, mas como é pouca a diferença podemos nos basear muito bem por aqui. Estou usando a aplicação de testes também da OWASP a Multillidae que tem uma boa base para quem está começando, com dicas nas páginas vulneráveis, e também para os mais experientes, pois essas ajudas e a complexidade da falha podem ser alteradas.
Como comentado no post anterior dessa série, quando se fala em injection vem logo a cabeça o SQL Injection. Como estamos falando de Introdução à Segurança da Informação, podemos começar por ele mesmo, vou mostrar aqui alguns modos de atacar um site por SQL Injection.
Eu já postei aqui um paper em várias partes chamado "Pentest em sites com Metasploit", que o objetivo era mostrar como era possível fazer um pentest completo em uma aplicação web apenas com o Metasploit, mas o motivo de estar citando aqui essa série é porque em algumas partes eu citei o sqlmap e até foi mostrado como usa-lo para atacar falhas de SQL Injection. Se você já tem um conhecimento prévio recomendo dar uma olhada lá, caso esteja realmente iniciando agora recomendo que guarde esse link para depois e continue sua leitura aqui neste post.
Vamos ver algo bem básico neste post sobre SQL Injection.
Basicamente, as vulnerabilidades de Injection acontecem quando você pode passar todas as proteções e mandar códigos para serem executados no servidor ou banco de dados. No nosso caso aqui, vamos mandar alguns códigos para o servidor na hora da verificação de autenticação que vai nos liberar acesso a uma área restrita do site, logar sem ter um usuário e senha.
Para facilitar a explicação, deixei na dificuldade mínima e dicas habilitadas.
Neste caso temos o formulário de login, um teste básico que podemos fazer é colocar um apóstrofo no campo e enviar e ver o que acontece. Em muitos casos onde ha a vulnerabilidade as saídas de erro não são tratadas corretamente e acabam aparecendo na página.
No caso de um site real vulnerável você receberia uma página em branco ou a mesma página com a mensagem "/owaspbwa/owaspbwa-svn/var/www/mutillidae/classes/MySQLHandler.php on line 108: Error executing query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '''' AND password=''' at line 1 () (0) [Exception] " aparecendo em algum lugar. As outras informações são as dicas do Mutillidae.
Para entendermos melhor como isso funciona, vamos observar a linha Diagnostic Information que contém o comando executado no banco de dados quando preenchemos os campos de login e senha.
Com um pouco de conhecimento em banco de dados SQL podemos ver que ele pega tudo da tabela accounts onde o usuário é ' (o apóstrofo que eu coloquei) e a senha é vazio. Se eu colocar qualquer coisa ali ele vai testar, ver que não encontrou nada igual no banco e retornar "false" que quer dizer que eu digitei o usuário ou senha errado. Neste caso eu obtive o erro porque a aplicação não soube lidar com o caractere que eu usei. Se você parar para notar, os conteúdos dos campos são delimitados pelos mesmos apóstrofos, com isso criei um conflito que misturou todo o comando e me retornou o erro. Isso quer dizer que, como ele aceitou numa boa um apóstrofo eu posso utilizá-lo para fechar o conteúdo do campo e continuar escrevendo o comando diretamente do formulário de login.
Vamos ao exemplo mais prático, o famoso ' or 1=1 --. Para os mais leigos, isso quer dizer que o comando que será executado no banco vai ser um pouco diferente, vejamos:
SELECT * FROM accounts WHERE username='' or 1=1 --' AND password='' or 1=1 --'
Com isso temos, pegue tudo da tabela accounts onde o usuário é vazio ou 1 é igual a 1 e a senha é vazio ou 1 é igual a 1 e ignore todo o resto (os dois traços). Lembram-se acima quando eu falei que o banco checaria e por não ter a combinação de usuário/senha ele retornaria "false"? E agora, o que você acha que ele vai retornar? "True"! Isso mesmo, por mais que ele não encontre as credenciais que eu passei ele sempre vai cair na verificação de que 1 é sempre igual a 1, por isso retorna "true" e nos autentica:
E ai está! Conseguimos os detalhes das contas cadastradas no site.
Mas não paramos por aqui, ainda temos algumas coisas a ressaltar. Não será em todos os casos que isso vai funcionar, os comandos variam com a linguagem que o banco de dados usa, veja abaixo algumas outras possibilidades:
b’ or ‘ 1=’
‘ or ’1
‘ or ‘|
‘ or ‘a’='a
‘ or ”=’
‘ or 1=1–
‘) or (‘a’='a
‘ or ’1′=’1
admin ‘ – -
‘ ou 0=0 –
“ou 0=0 –
ou 0=0 –
‘ ou 0=0 #
“ou 0=0 #
ou 0=0 #
‘ ou ‘ x’='x
“ou” x”=”x
‘) ou (‘ x’='x
‘ ou 1=1 –
“ou 1=1 –
ou 1=1 –
‘ ou a=a –
“ou” a”=”a
‘) ou (‘ a’='a
“) ou (“a”=”a
hi “ou” a”=”a
hi “ou 1=1 –
hi ‘ ou 1=1 –
hi ‘ ou ‘ a’='a
hi ‘) ou (‘ a’='a
hi”) ou (“a”=”a
‘ or ‘x’='x
Mas não pare por ai! Se nada der certo, procure forçar um erro para ter uma pista de qual banco de dados está sendo usado, com essa informação procure como que aquele banco em específico trata os comandos e entradas e use sua imaginação para bolar uma injeção de código. Nem sempre pegar o que já está pronto pode te ajudar.
Agora uma coisa muito interessante que poucos se preocupam em falar, como podemos proteger os sites de Injection? Mais simples do que você imagina, ou não depende da complexidade da sua aplicação. A regra mais importante aqui é "trate todo a entrada como maliciosa", com isso em mente você poderá prever todas ou boa parte das possibilidades. Avalie, filtre e trate antes de chegar ao banco de dados. Existem algumas funções já prontas, como o Magic Quotes por exemplo, que prometem filtrar esses parâmetros, não sou a melhor pessoa para falar sobre isso porque não sou programador, mas recomendo que procure mais sobre isso.
Não preciso comentar em manter sempre tudo atualizado e regularizado, isso pode não resolver, mas pode diminuir o estrago ou até mesmo diminuir a quantidade de informação vazada.
E para finalizar, um ultimo ponto que considero interessante é a utilização de um WAF (Web Application Firewall), que vai detectar essas ameaças e cortar a conexão antes que um dano maior ocorra, e um concelho, não mostre mais do que o necessário, trate todos os erros que sua aplicação pode gerar.
Eu fico por aqui depois desse longo post, espero que tenham entendido e gostado, porque querendo ou não tem pelo menos mais 9 desses vindo por ai :)
Também indico que baixem e testem o Multillidae, que tem várias situações para você tentar resolver que sem dúvida vão refinar seu conhecimento.
Bons estudos e até a próxima!
Parabéns pelo site. Noticias atualizadas. Com certeza já foi pros favoritos e pro feed
ResponderExcluir