Experimentos de SQL Injection com Nmap: Guia Prático

Introdução

SQL injection (injeção SQL) é uma técnica popular utilizada por atacantes para explorar aplicações web, através da criação de entradas maliciosas e da execução de instruções SQL arbitrárias no banco de dados de backend. Neste laboratório, vamos configurar um ambiente de SQL injection usando o sqli-labs com Docker, e realizar experimentos práticos para entender os princípios e os métodos de exploração das vulnerabilidades de SQL injection.

Identificando Pontos de Injeção

Bem-vindo ao nosso curso introdutório sobre testes de segurança web, focando especificamente na identificação de potenciais vulnerabilidades de SQL injection. SQL injection é uma falha de segurança comum e potencialmente devastadora em aplicações web, mas com o conhecimento certo, você pode aprender a identificá-la e preveni-la.

O que é SQL Injection?

SQL Injection é uma técnica onde um atacante insere código SQL malicioso na consulta ao banco de dados de uma aplicação web. Se a aplicação web não sanitizar adequadamente a entrada do usuário, isso pode levar a violações de dados, perda de dados ou outros problemas sérios.

Identificando Pontos Potenciais de SQL Injection

Aplicações web que interagem com um banco de dados frequentemente possuem URLs que incluem parâmetros. Esses parâmetros podem ser potencialmente explorados se não forem devidamente sanitizados. Por exemplo, você pode ver uma URL que se parece com isto:

http://some-website.com/page.php?id=XX

Nesta URL, id é um parâmetro que interage com o banco de dados. Qualquer página web que use tais parâmetros pode ser potencialmente vulnerável a SQL injection se a entrada não for devidamente sanitizada.

Testando SQL Injection: A Técnica da Aspas Simples

Uma maneira simples de testar vulnerabilidades de SQL injection é usar a técnica da aspas simples. Veja como você faz isso:

Anexe uma aspa simples (') ao valor do parâmetro na URL. Por exemplo, você pode alterar a URL para se parecer com isto: http://some-website.com/page.php?id=1'
Se a página web retornar um erro depois que você pressionar Enter, isso pode significar que o site é vulnerável a SQL injection.

A razão pela qual isso funciona é que tanto os tipos de dados numéricos quanto os de string em SQL gerarão um erro de sintaxe quando uma aspa simples desbalanceada for introduzida. Este erro pode revelar a presença de uma vulnerabilidade de SQL injection.

Nota Importante

Se nenhum erro for exibido quando você anexar uma aspa simples, isso não significa necessariamente que não haja vulnerabilidade de SQL injection. É possível que a aplicação esteja filtrando as aspas simples, o que exigiria que você usasse outras técnicas para testar as vulnerabilidades. Não se preocupe, abordaremos essas técnicas mais avançadas em uma lição futura.

Lembre-se, hacking ético é sobre melhorar a segurança. Sempre respeite a privacidade e a legalidade em seus esforços de teste. Bons estudos!

Determinando o Tipo de SQL Injection

Ótimo trabalho em identificar potenciais pontos de SQL injection! Agora, vamos para o próximo passo: determinar o tipo de vulnerabilidade de SQL injection. Existem dois tipos principais nos quais focaremos: SQL injection numérico e baseado em string.

SQL Injection Numérico

Quando o parâmetro de entrada (vamos chamá-lo de x) é tratado como um inteiro pela aplicação web, a consulta SQL pode se parecer com isto:

select * from <table_name> where id = x

Para identificar um SQL injection numérico, usamos duas condições lógicas simples: and 1=1 e and 1=2. Veja como:

Insira http://some-website.com/page.php?id=x and 1=1 no seu navegador. Se a página carregar como esperado, vá para o próximo passo.
Agora, tente http://some-website.com/page.php?id=x and 1=2. Se a página retornar um erro ou se comportar de maneira diferente, isso pode indicar uma vulnerabilidade de SQL injection numérico.

Por que isso funciona?

Quando você insere and 1=1, a consulta SQL resultante é:

select * from <table_name> where id = x and 1=1

A condição 1=1 é sempre verdadeira, então, se a página carregar normalmente, isso sugere que a entrada está sendo inserida diretamente na consulta SQL.

Quando você insere and 1=2, a consulta SQL resultante é:

select * from <table_name> where id = x and 1=2

A condição 1=2 é sempre falsa, então, se a página se comportar de maneira diferente (como retornar um erro), isso sugere que nossa entrada está afetando a consulta SQL, indicando uma potencial vulnerabilidade de SQL injection.

SQL Injection Baseado em String

Em alguns casos, o parâmetro de entrada x é tratado como uma string. A consulta SQL pode se parecer com isto:

select * from <table_name> where id = 'x'

Para identificar uma injeção baseada em string, usamos uma abordagem semelhante à injeção numérica, mas com condições de string: and '1'='1' e and '1'='2'. Veja como:

Insira http://some-website.com/page.php?id=x' and '1'='1 no seu navegador. Se a página carregar como esperado, vá para o próximo passo.
Agora, tente http://some-website.com/page.php?id=x' and '1'='2. Se a página retornar um erro ou se comportar de maneira diferente, isso pode indicar uma vulnerabilidade de SQL injection baseada em string.

Por que isso funciona?

Quando você insere and '1'='1', a consulta SQL resultante é:

select * from <table_name> where id = 'x' and '1'='1'

A condição '1'='1' é sempre verdadeira, então, se a página carregar normalmente, isso sugere que a entrada está sendo inserida diretamente na consulta SQL.

Quando você insere and '1'='2', a consulta SQL resultante é:

select * from <table_name> where id = 'x' and '1'='2'

A condição '1'='2' é sempre falsa, então, se a página se comportar de maneira diferente (como retornar um erro), isso sugere que nossa entrada está afetando a consulta SQL, indicando uma potencial vulnerabilidade de SQL injection.

Em ambos os casos, lembre-se que uma resposta incomum da aplicação web é uma dica de que você pode ter encontrado um ponto de SQL injection. No entanto, sempre certifique-se de ter permissão para realizar esses testes e use suas habilidades de forma responsável. Bons estudos!

Explorando SQL Injection para Burlar a Autenticação

Neste laboratório, vamos nos aprofundar nas vulnerabilidades de SQL injection. Nosso foco será em como explorar essas vulnerabilidades para contornar a autenticação de login, uma técnica frequentemente referida como o ataque de "senha universal".

Preparando o Ambiente do Laboratório

Para começar, precisaremos preparar nosso ambiente de laboratório. Usaremos o Damn Vulnerable Web Application (DVWA) - uma aplicação web PHP/MySQL projetada para ser intencionalmente insegura, tornando-a uma ferramenta de aprendizado ideal para entender a segurança de aplicações web.

Baixe a Imagem Docker sqli-labs: A imagem Docker sqli-labs está disponível para download no Docker Hub. Use o seguinte comando no seu terminal para baixá-la:
```
docker pull acgpiano/sqli-labs
```
Inicie o Container Docker sqli-labs: Após baixar a imagem, execute-a usando o comando abaixo:
```
docker run -it -d --name sqli-labs -p 80:80 -p 13306:3306 acgpiano/sqli-labs
```
Este comando inicia um novo container e mapeia a porta 80 e 3306 no container para a porta 80 e 13306 na sua máquina host, respectivamente.

Ao seguir estas etapas, você configurou com sucesso o ambiente de laboratório necessário.

Após a configuração ser concluída, abra o Firefox e digite http://localhost na barra de endereço.

Se esta é a sua primeira vez visitando http://localhost, por favor, clique em Setup/reset Database for lab para preparar o laboratório e, em seguida, atualize a página web.

Identificando SQL Injection

Você deve ver agora uma página de login simples quando clicar em Less-11. Tente inserir um nome de usuário arbitrário 123 e senha 123.

A página de erro informará "Invalid username or password." (Nome de usuário ou senha inválidos.)

Decifrando o Código Backend

Vamos examinar o código backend responsável pelo processo de autenticação:

// take the variables
if(isset($_POST['uname']) && isset($_POST['passwd']))
{
 $uname=$_POST['uname'];
 $passwd=$_POST['passwd'];

 //logging the connection parameters to a file for analysis.
 $fp=fopen('result.txt','a');
 fwrite($fp,'User Name:'.$uname);
 fwrite($fp,'Password:'.$passwd."\n");
 fclose($fp);

 // connectivity
 @$sql="SELECT username, password FROM users WHERE username='$uname' and password='$passwd' LIMIT 0,1";
 $result=mysql_query($sql);
 $row = mysql_fetch_array($result);
....
}

A consulta SQL real que é executada é:

SELECT * FROM users WHERE username='123' AND password='123' LIMIT 0,1

Esta consulta é simples de entender: se ela retornar uma linha onde tanto o username quanto a password correspondem, então o login é bem-sucedido.

Explorando a Vulnerabilidade

Com base no conhecimento do laboratório anterior, vamos tentar inserir o seguinte payload:

Nome de usuário: 123' or 1=1 # Senha: 123' or 1=1 #

Curiosamente, isso nos permite fazer login com sucesso! A razão para isso é que a consulta SQL real que é executada é:

SELECT * FROM users WHERE username='123' or 1=1 #' AND password='123' or 1=1 #'

No MySQL, o símbolo # é usado para comentar o restante da linha, então a consulta efetivamente se torna:

SELECT * FROM users WHERE username='123' or 1=1

Dado que a condição or 1=1 é sempre verdadeira, a consulta sempre retornará um resultado, levando a um login bem-sucedido.

Também podemos experimentar uma variação que não usa o símbolo de comentário:

Nome de usuário: 123' or '1'='1 Senha: 123' or '1'='1

A consulta SQL que é executada então é:

SELECT * FROM users WHERE username='123' or '1'='1' AND password='123' or '1'='1'

Neste caso, as duas condições or garantem que a condição and entre elas seja sempre verdadeira, levando a um login bem-sucedido.

Conclusão

Como demonstrado acima, existem inúmeras técnicas que podem ser usadas para explorar vulnerabilidades de SQL injection e contornar a autenticação. Sinta-se à vontade para explorar e experimentar diferentes payloads. O objetivo aqui é entender essas vulnerabilidades para que você possa proteger melhor suas próprias aplicações contra elas. Bom hacking ético!

Resumo

Neste laboratório, aprendemos como identificar vulnerabilidades de SQL injection usando a técnica de aspas simples e como determinar o tipo de SQL injection (numérico ou baseado em string) usando payloads específicos. Também exploramos a exploração de vulnerabilidades de SQL injection para contornar a autenticação de login, um cenário comum conhecido como o ataque de "senha universal". Ao conduzir experimentos práticos, ganhamos experiência prática na compreensão e exploração de vulnerabilidades de SQL injection, que são prevalentes em aplicações web se a sanitização de entrada não for implementada corretamente.

Realize Experimentos de SQL Injection no Nmap