Pentest

SQL Injection na Pratica: Explorando, Detectando e Mitigando em Lab Controlado

Por Equipe Basilisk ·

Demonstracao tecnica de SQLi com sqlmap em ambiente proprio, focando em deteccao defensiva e fixes parametrizados que realmente seguram o trafego em producao.

SQL Injection completou 27 anos em 2026 e continua no top 3 do OWASP. Nao porque os atacantes ficaram mais espertos, e sim porque ORMs mal usados, queries dinamicas em dashboards internos e endpoints GraphQL com resolvers ingenuos ainda concatenam strings. No lab que vamos montar aqui, partimos de uma instancia DVWA rodando em Docker, MySQL 8.0 com binlog ativado, e um proxy Burp Suite 2025.6 capturando cada request. O objetivo nao e impressionar com um dump de tabela users: e treinar o olho para reconhecer os sinais de instrumentacao defensiva que param o sqlmap antes do segundo payload. Se voce ainda nao montou seu ambiente isolado, vale revisitar Pentest Web do Zero: Montando um Lab Seguro com DVWA, Juice Shop e Burp Suite antes de continuar.

O primeiro experimento usa o endpoint vulneravel de SQLi por GET do DVWA em nivel low. Rodamos sqlmap -u 'http://lab.local/vulnerabilities/sqli/?id=1&Submit=Submit' --cookie='PHPSESSID=...; security=low' --batch --technique=BEUST --level=3 --risk=2. Em 4 segundos o sqlmap identifica injection boolean-based blind no parametro id, em 11 segundos enumera o banco dvwa e suas 2 tabelas. Repare nos payloads enviados: 1 AND 4523=4523, 1 AND 1=2 UNION SELECT NULL,NULL. Esses literais numericos repetitivos sao gold para regras de deteccao em WAF e em SIEM. Anote o user-agent default sqlmap/1.8.x e o padrao de Accept-Encoding ausente, porque vamos transformar isso em sinal mais a frente.

Antes de escalar para tecnicas time-based, abrimos uma segunda aba e ativamos query logging no MySQL com SET GLOBAL general_log = 'ON'. Cada payload do sqlmap aparece em /var/log/mysql/general.log com timestamp em microssegundos. Comparando 30 segundos de trafego legitimo (gerado por um locust simulando 50 usuarios) contra 30 segundos de sqlmap, a entropia das queries explode: o coeficiente de variacao do tamanho da query passa de 0.12 para 1.8. Esse delta sozinho ja alimenta uma regra Sigma decente. Vale combinar com o que cobrimos em Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao para empacotar isso como deteccao reutilizavel no Elastic.

Agora a parte que separa o script kiddie do pentester: explorar second-order SQLi. Inserimos via formulario de cadastro um nome de usuario igual a admin'-- com aspas escapadas pelo prepared statement de cadastro. O problema mora no endpoint de pesquisa interna que reusa esse valor em uma query dinamica sem reparametrizar. Resultado: bypass de autenticacao em uma rota que nem aparecia no scan inicial do sqlmap, porque o payload so dispara em outro contexto. Esse padrao e o mesmo que costuma furar APIs GraphQL com resolvers compartilhando builders, conforme detalhamos em Pentest de APIs REST e GraphQL: Checklist Tecnico para Bug Bounty Legal. sqlmap nao pega isso sozinho, e por isso revisao manual de codigo continua paga em qualquer programa de bug bounty.

Mitigacao real comeca com prepared statements parametrizados, mas nao termina ai. No nosso lab Java/Spring substituimos a string interpolada por NamedParameterJdbcTemplate, validamos input com Bean Validation (jakarta.validation 3.1) e adicionamos uma allowlist de colunas permitidas em ORDER BY (porque PreparedStatement nao parametriza identificadores). Em PHP, PDO com PDO::ATTR_EMULATE_PREPARES=false e obrigatorio em MySQL para evitar o classico bypass de aspas multibyte. Camadas seguintes: least privilege no usuario da aplicacao (GRANT SELECT, INSERT, UPDATE apenas), e um WAF como ModSecurity com CRS 4.4 em modo blocking para parametros numericos. O hardening do servidor segue o mesmo principio coberto em Hardening de Linux Servidor: CIS Benchmark Aplicado sem Quebrar Producao: reduzir superficie antes de confiar em deteccao.

Para fechar o ciclo defensivo, plugamos o general_log no Filebeat, enviamos para um Elastic 8.16 e criamos tres detec coes: pico de erros de sintaxe SQL acima de 5 por minuto por IP, queries contendo UNION SELECT NULL em sequencia, e tempo de execucao de query acima de 3 desvios padrao sobre o baseline horario. Em testes contra sqlmap rodando com --random-agent e --delay=2, as tres regras dispararam em menos de 90 segundos. Adicionamos tambem honeytokens: colunas fake como credit_card_test com strings tracaveis. Se algum dia esse valor aparecer em paste site, sabemos exatamente qual endpoint vazou. Esse loop de feedback red e blue espelha o que defendemos em Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue.

Takeaway pratico: monte o lab, rode o sqlmap uma vez para sentir o ritmo dos payloads, e gaste 80 por cento do tempo restante construindo deteccao e fixes. SQLi nao e problema de criatividade do atacante, e problema de query dinamica que ninguem revisou. Cole no seu calendario uma revisao trimestral de todas as queries que aceitam input externo, parametrize tudo que for valor e use allowlist para tudo que for identificador. O dia que voce conseguir provar que sua aplicacao mata sqlmap em menos de 2 minutos com bloqueio automatico, voce ganhou.

Nenhum comentário ainda

Seja o primeiro a comentar.

Deixe seu comentário

Entre com sua conta Canverly para comentar. Você pode usar a mesma conta em qualquer site da rede.

Entrar com Canverly