Encontre a Sondagem de SQLi: Lendo Payloads de Injeção em Logs Web
O desafio
Seu endpoint de busca está sendo martelado com consultas estranhas. Escondido entre as buscas normais, um IP está enviando cargas clássicas de injeção SQL - coisas como ' OR '1'='1 e UNION SELECT - sondando se a caixa de busca fala direto com o banco de dados. Filtre as requisições suspeitas, encontre o único atacante, e envie o IP dele.
O que você vai aprender
- Ler a query string de uma requisição, não apenas o IP e o status
- Reconhecer payloads clássicos de SQL injection em logs de acesso
- Diferenciar sondagens de injeção de buscas comuns
- Usar códigos de status de erro como sinal secundário de um ataque de consulta malformada
- Atribuir um ataque web a um único IP de origem
Habilidades testadas
Pré-requisitos
- Entendimento básico de consultas SQL e da cláusula WHERE
- Familiaridade com parâmetros de query de URL
- Conhecimento de códigos de status HTTP (200, 500, 504)
Como funciona
SQL injection acontece quando uma aplicação joga a entrada do usuário direto em uma consulta de banco de dados sem separar código de dado. Um atacante sonda isso enviando entradas que, se refletidas no SQL, mudam o significado da consulta. Em um log de acesso isso fica visível diretamente: a intenção maliciosa é escrita na query string da URL para quem estiver lendo a coluna path.
Aqui o atacante, 203.0.113.200, segue o roteiro padrão contra /search. Uma aspa solta (q=laptop') testa uma quebra de sintaxe e gera um 500. Depois um bypass booleano (' OR '1'='1), uma sondagem de contagem de colunas (UNION SELECT null,null), uma tentativa de roubo de dados (UNION SELECT username,password FROM users), um dump de schema (information_schema.tables), um teste baseado em tempo (AND SLEEP(5) gerando um 504), e um payload destrutivo (;DROP TABLE users). Todo usuário legítimo está apenas digitando nomes de produtos, então as strings de injeção se destacam no instante em que você lê o valor da query em vez de só passar o olho pelos IPs.
Os erros são um indício útil, mas secundário. Filtrar por status:500 traz à tona as linhas em que o SQL malformado quebrou a consulta, e todas pertencem ao mesmo IP - mas as linhas de injeção bem-sucedidas com 200 importam tanto quanto, porque um resultado retornado significa que o bypass pode ter funcionado. A evidência decisiva é o conteúdo do payload somado à sua origem única.
Erros comuns
- Filtrar só por status. Muitos dos piores payloads retornam
200; filtrar apenas porstatus:500deixa passar as injeções que tiveram sucesso. - Passar o olho pelos IPs e ignorar a query string. O ataque está no valor de
q=, você precisa ler. - Tratar buscas estranhas como erros de digitação. Uma aspa solta pode ser um erro de digitação;
UNION SELECT password FROM usersnão é. - Enviar o path ou o payload em vez do IP. A pergunta pede quem - a origem única que envia as injeções.
Como se proteger
SQL injection é prevenida no código, não torcendo para que ninguém tente. Os mesmos payloads que você identificou no log são exatamente o que um WAF e regras de detecção deveriam pegar.
- Use consultas parametrizadas ou prepared statements para que a entrada do usuário seja sempre dado, nunca código SQL.
- Valide e restrinja a entrada (um termo de busca não precisa de aspas, ponto e vírgula, ou da palavra UNION).
- Gere alertas para requisições cuja query string contenha marcadores de injeção como
UNION SELECT,OR 1=1, ouinformation_schema, especialmente quando repetidos vindos de uma mesma origem. - Rode o banco de dados com privilégio mínimo para que uma injeção bem-sucedida não consiga apagar tabelas ou ler dados não relacionados.