Agora que você entende SQL Injection na mão — por que os payloads funcionam, como extrair dados, como a injeção cega infere informação —, você ganhou o direito de automatizá-la. O SQLmap é a ferramenta que faz tudo isso em escala industrial: detecta a vulnerabilidade, identifica o tipo de banco, extrai a estrutura e os dados, tudo automaticamente. Esta aula ensina a usá-lo — e reforça por que fazer a SQLi manual primeiro foi essencial, porque quem só conhece o SQLmap é refém dele. Pratique no DVWA e na Metasploitable.
O processo manual, automatizado
O SQLmap automatiza o processo metódico que você faria à mão: ele injeta payloads de teste para detectar se um parâmetro é vulnerável, identifica qual tipo de SQLi funciona (UNION-based, boolean-based, time-based), determina o SGBD (MySQL, PostgreSQL, MSSQL...), e então extrai o que você pedir. O uso básico aponta para um parâmetro suspeito:
# testa um parâmetro GET
sqlmap -u "http://alvo.com/produto?id=1"
# uma vez confirmada a vulnerabilidade, extrai informação progressivamente:
sqlmap -u "http://alvo.com/produto?id=1" --dbs # lista os bancos de dados
sqlmap -u "http://alvo.com/produto?id=1" -D loja --tables # tabelas do banco "loja"
sqlmap -u "http://alvo.com/produto?id=1" -D loja -T usuarios --dump # despeja a tabela
Bancos, tabelas e o dump
Repare que a lógica espelha exatamente o processo manual: descobrir os bancos, depois as tabelas, depois despejar os dados — só que o SQLmap faz cada passo automaticamente, testando dezenas de técnicas e adaptando-se ao banco. Para requisições mais complexas (POST, com cookies de sessão, com cabeçalhos específicos), você fornece a requisição inteira, tipicamente capturada com o Burp Suite (aula Burp Suite: a bancada de trabalho do pentester web):
sqlmap -r requisicao.txt # usa uma requisição HTTP salva (com POST, cookies, etc.)
sqlmap -u "..." --cookie="session=abc123" # fornece o cookie de sessão
sqlmap -r requisicao.txt --dump-all # despeja tudo (use com responsabilidade!)
os-shell, arquivos e evasão de WAF
O SQLmap tem recursos avançados que refletem a profundidade da SQLi: ele pode tentar obter um shell no banco ou no sistema operacional (--os-shell, quando as permissões do banco permitem — conectando SQLi com comprometimento do servidor), ler/escrever arquivos, e usar técnicas de evasão de WAF (com "tamper scripts" que ofuscam os payloads). Essa potência é o que torna o SQLmap uma ferramenta poderosíssima — e é exatamente por isso que ela exige responsabilidade: um --dump-all extrai bancos inteiros de dados (potencialmente dados pessoais protegidos por LGPD, aula A lei que separa a carreira do processo criminal), e o --os-shell compromete o servidor. Você usa esses recursos apenas dentro do escopo autorizado e com a consciência do impacto — extrair mais dados do que o necessário, mesmo num teste autorizado, tem implicações de privacidade.
Por que aprender na mão antes
Agora, o ponto pedagógico central desta aula, que justifica toda a estrutura do curso: por que aprender SQLi na mão antes do SQLmap? Três razões concretas. Primeiro, o SQLmap falha e você precisa saber por quê: ele nem sempre detecta ou explora uma SQLi que existe (filtros customizados, contextos incomuns, WAFs), e quando ele falha, só quem entende SQLi consegue explorar manualmente o que a ferramenta não pegou. Muitas SQLi de bug bounty são encontradas manualmente justamente onde o SQLmap desistiu. Segundo, você precisa interpretar e ajustar: o SQLmap tem dezenas de opções (nível de teste, risco, técnicas, tampers) que só fazem sentido se você entende o que está acontecendo por baixo — o iniciante roda com as opções padrão e conclui erradamente "não é vulnerável". Terceiro, entender evita erros graves: rodar o SQLmap cegamente com opções agressivas pode causar impacto (queries pesadas que sobrecarregam o banco, dados extraídos em excesso). Quem entende usa a ferramenta com precisão cirúrgica; quem não entende, com um machado.
Multiplicador para quem domina o fundamento
Esse é o princípio "manual antes da ferramenta" em sua forma mais clara, e ele vale para todo o restante do bloco web e do curso: as ferramentas (SQLmap, Burp, Nikto, e todas as outras) são multiplicadores de eficiência para quem domina o fundamento, e muletas enganosas para quem não o domina. O profissional usa o SQLmap para velocidade depois de confirmar e entender a vulnerabilidade; o amador o usa como substituto do entendimento e trava assim que a ferramenta não resolve sozinha. Certificações sérias (OSCP, OSWE) inclusive restringem ou proíbem o SQLmap justamente para verificar se você entende SQLi de verdade.
Validar as prepared statements
Do lado defensivo, o SQLmap é também uma ferramenta de teste que o Blue Team e os desenvolvedores usam para validar suas defesas: rodar o SQLmap contra a própria aplicação (em ambiente de teste) confirma se as prepared statements (aula SQL Injection na mão: conversando com o banco de dados) realmente fecharam a SQLi. Se o SQLmap não consegue explorar, é um bom sinal de que a parametrização está correta. E, como toda ferramenta ofensiva conhecida, o SQLmap tem assinaturas que WAFs e IDS detectam — reconhecer um scan de SQLmap nos logs (payloads característicos, volume de requisições) é habilidade defensiva. A defesa de fundo continua a mesma: prepared statements tornam a aplicação imune, e nenhuma ferramenta de exploração — por mais poderosa — quebra o que foi corretamente parametrizado. Da injeção no banco o caminho segue para a injeção no navegador da vítima: o Cross-Site Scripting (XSS).
Fontes e leituras recomendadas
- sqlmap.org — documentação oficial, opções e técnicas
- PortSwigger Academy — para praticar SQLi manual antes/junto do SQLmap
- OWASP — SQL Injection Prevention Cheat Sheet (validação defensiva)
- HackTricks — seção de SQL Injection (manual e com sqlmap)
Exercícios
-
Como o fluxo de comandos do SQLmap (
--dbs,--tables,--dump) espelha o processo manual?✓ Resposta:Espelha porque segue os mesmos passos metódicos: primeiro descobre os bancos (
--dbs), depois as tabelas de um banco (--tables), depois despeja o conteúdo (--dump) — exatamente a sequência "mapear a estrutura, depois saquear os dados" do processo manual, só que automatizada e testando muitas técnicas. -
Que recursos avançados do SQLmap conectam a SQLi com o comprometimento do próprio servidor, e por que exigem responsabilidade?
✓ Resposta:O
--os-shell(obter shell no sistema quando as permissões do banco permitem) e a leitura/escrita de arquivos conectam a SQLi ao comprometimento do servidor. Exigem responsabilidade porque comprometem o servidor e podem extrair dados sensíveis (protegidos por LGPD); usam-se apenas no escopo autorizado e com consciência do impacto. -
Explique as três razões pelas quais aprender SQLi na mão antes do SQLmap é essencial.
✓ Resposta:(1) O SQLmap falha em casos que existem (filtros, WAFs, contextos incomuns), e só quem entende SQLi explora manualmente o que ele não pega; (2) suas dezenas de opções só fazem sentido para quem entende o que ocorre por baixo, evitando falsos negativos por rodar só o padrão; (3) entender evita erros graves, como impacto por opções agressivas ou extração excessiva de dados.
-
Por que rodar o SQLmap "cegamente" pode levar tanto a falsos negativos quanto a impacto indesejado?
✓ Resposta:Falsos negativos: com opções padrão, o SQLmap pode não detectar uma SQLi que exigiria nível/risco maior ou tampers, levando a concluir erradamente "não é vulnerável". Impacto: opções agressivas geram queries pesadas que sobrecarregam o banco e extraem dados em excesso, causando problemas mesmo num teste autorizado.
-
Como o SQLmap pode ser usado defensivamente, e por que ele não consegue explorar uma aplicação corretamente parametrizada?
✓ Resposta:Defensivamente, rodar o SQLmap contra a própria aplicação (em teste) valida se as defesas (prepared statements) fecharam a SQLi — se ele não explora, a parametrização está correta. Ele não consegue explorar uma aplicação corretamente parametrizada porque a entrada nunca é interpretada como comando; não há estrutura de consulta para quebrar, independentemente do payload.
