material • 21/05/2026

Material introdutório de SQL Injection

Uma aula prática sobre SQL Injection usando o laboratório da PortSwigger

por rideckszz

C:\>aula_ □ ×

SQL Injection

Uma aula prática sobre como uma entrada simples pode mudar a lógica de uma consulta SQL.

O foco é entender como a aplicação se comporta quando a entrada altera a consulta.

1. O que é SQL Injection?
C:\>conceito_ □ ×

Quando texto vira SQL

SQL Injection acontece quando a aplicação coloca uma entrada do usuário direto dentro de uma consulta SQL.

O banco deveria receber só um valor. Mas, se a aplicação montar a query de forma insegura, a entrada pode mudar a lógica do comando.

A Injeção SQL é uma vulnerabilidade de aplicação web que ocorre quando entradas fornecidas por usuários não são devidamente tratadas antes de serem usadas em consultas ao banco de dados.

Quando a aplicação concatena dados arbitrários diretamente em uma consulta, ela pode falhar em distinguir entre o que é dado inserido pelo usuário e o que é sintaxe SQL.

Quando o encapsulamento de uma string é quebrado por caracteres especiais, o banco de dados pode executar uma instrução modificada com os privilégios da própria aplicação.

Dado

Algo que o usuário envia: categoria, busca, nome, ID, filtro.

Comando

A estrutura SQL interpretada pelo banco: condições, operadores, comentários.

Falha

A aplicação mistura essas duas coisas.

Resumo: SQLi aparece quando a aplicação não separa bem dado e comando.

2. Exemplo rápido: login

Em um cenário clássico de formulário de login, a consulta original no código fonte geralmente possui uma estrutura parecida com esta:

SELECT * FROM users
WHERE username = '$_POST["username"]'
AND password = '$_POST["password"]'

Se uma entrada malformada for inserida no campo de usuário, a instrução resultante pode fazer com que parte da verificação seja ignorada.

O ponto importante não é o payload em si. O problema é a aplicação montar uma consulta juntando texto do usuário com a estrutura do SQL.

C:\>raciocínio_ □ ×

Falha → Exploit → Impacto

Falha

Entrada do usuário entra na query.

Exploit

A lógica da consulta é alterada.

Impacto

A aplicação mostra ou permite algo que não deveria.

3. Tipos de SQLi

A exploração costuma ser dividida pelo modo como a informação retorna para quem está testando a aplicação.

In-band

O teste e o retorno dos dados acontecem pelo mesmo canal da aplicação. Exemplos: erro visível ou retorno direto na página.

Blind

A aplicação não mostra diretamente o resultado. A inferência acontece por diferença de conteúdo, resposta ou tempo.

Out-of-band

Os dados são retornados por outro canal, como DNS ou HTTP externo. É menos comum em labs iniciais.

Dentro dessas categorias, aparecem técnicas como exploração baseada em erro, exploração baseada em UNION, inferência booleana e inferência baseada em tempo.

C:\>impactos_ □ ×

O que pode acontecer?

  • burlar lógica de autenticação;
  • mostrar dados escondidos;
  • listar informações do banco;
  • ler dados sensíveis;
  • alterar o comportamento da aplicação.
4. Lab da PortSwigger
C:\>prática_ □ ×

Hidden data lab

O lab tem uma falha no filtro de categoria de produtos.

Quando uma categoria é selecionada, a aplicação monta uma consulta SQL com esse valor.

O laboratório usado na aula é:

Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data Nível: Apprentice Plataforma: PortSwigger Web Security Academy

Neste lab, a vulnerabilidade está no filtro de categoria de produtos.

Quando o usuário seleciona uma categoria, a aplicação executa uma consulta semelhante a esta:

SELECT * FROM products
WHERE category = 'Gifts'
AND released = 1

O trecho released = 1 indica que a aplicação tenta mostrar apenas produtos publicados.

C:\>objetivo_ □ ×

O que vamos observar?

  • onde a categoria aparece na requisição;
  • como o filtro muda a resposta;
  • qual parte da query recebe a entrada;
  • como uma mudança lógica afeta os produtos exibidos.
5. Acessando o lab
https://portswigger.net/web-security/sql-injection/lab-retrieve-hidden-data

1

Abrir o lab da PortSwigger.

2

Clicar em Access the lab.

3

Testar o filtro de categorias normalmente.

4

Observar a URL e a resposta da página.

Antes de tentar resolver, observe o comportamento normal da aplicação. A página muda quando você troca a categoria? A URL muda? Existe algum parâmetro que parece controlar o filtro?

6. Burp Suite
C:\>requisição_ □ ×

Olhar antes de mexer

  1. abrir o Burp;
  2. ativar o proxy;
  3. selecionar uma categoria;
  4. interceptar a requisição;
  5. achar o parâmetro da categoria.

Pergunta para a turma: esse parâmetro parece ser só um valor de texto ou pode alterar a lógica da query?

A ideia de usar o Burp aqui é simples: ver a requisição de forma mais clara, identificar o parâmetro que representa a categoria e testar pequenas mudanças no valor enviado.

7. Pensando no exploit
C:\>lógica_ □ ×

Não comece pelo payload

Primeiro, pense na regra que a aplicação está tentando impor.

Ela filtra por categoria e depois limita o resultado aos produtos publicados.

Categoria

A entrada escolhe quais produtos aparecem.

Released

A aplicação tenta esconder produtos não publicados.

Teste

A pergunta é: dá para mudar essa lógica?

A consulta tem duas partes importantes na cláusula WHERE: uma ligada à categoria e outra ligada ao estado de publicação do produto.

A exploração do lab consiste em entender se a entrada da categoria consegue interferir nessa lógica.

8. Checklist do lab
C:\>durante a prática_ □ ×

Checklist

  • qual parâmetro controla a categoria?
  • onde ele entra na query?
  • qual era o resultado esperado?
  • o que muda quando a lógica muda?
  • qual é o impacto no lab?
9. Exploração manual

A exploração manual é importante porque ajuda a validar a vulnerabilidade e entender o comportamento da aplicação antes de qualquer automação.

A busca por pontos de injeção envolve testar entradas controladas pelo usuário, como parâmetros GET, parâmetros POST, cookies e cabeçalhos HTTP.

Alguns sinais comuns de comportamento vulnerável são:

Aspas

Podem quebrar o encapsulamento de strings e revelar erro de sintaxe.

Lógica

Condições booleanas ajudam a observar se a resposta muda.

10. Laboratório prático
C:\>lab_ □ ×

Inicie sua instância

Ao final da aula, você pode iniciar uma instância isolada do laboratório para praticar SQL Injection. Este laboratório é diferente do da PortSwigger, mas segue a mesma lógica.

Atualmente, apenas usuários logados com uma conta @dac.unicamp.br podem iniciar instâncias de laboratórios práticos.

C:\labs\web-sqli-01_ □ ×
laboratório prático

Ambiente isolado para prática

Inicie uma instância temporária ao final da aula para praticar o conteúdo com segurança.

aguardando login
Faça login para usar o laboratório.