SQLi Lab 01 — WHERE clause: retrieving hidden data

Objetivo

#

Explorar SQL Injection no filtro de categoria de produtos para exibir itens com released = 0 — ocultos ao usuário por design.

Query executada pela aplicação:

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

Conceito

#

A condição AND released = 1 funciona como controle de acesso — produtos não publicados ficam ocultos. O problema é que se o valor de category é inserido diretamente na query sem sanitização, o atacante controla a lógica SQL completa.

Ao usar ‘OR 1=1– torna qualquer condição verdadeira. -- comenta o restante da query. Combinados, anulam qualquer filtro que venha depois do ponto de injeção.

Reconhecimento

#

No Burp Suite, interceptei a requisição ao navegar para a categoria Gifts:

GET /filter?category=Gifts HTTP/2

O parâmetro category é passado diretamente via GET — ponto de injeção visível e sem validação aparente.

Exploração

#

No Repeater, modifiquei o parâmetro:

GET /filter?category='+OR+1=1-- HTTP/2

Query resultante no backend:

SELECT * FROM products WHERE category = '' OR 1=1-- AND released = 1

• OR 1=1 — condição sempre verdadeira, retorna todos os produtos
• -- — comenta AND released = 1, descartando o filtro

Resultado

#

Todos os produtos retornados — incluindo os não publicados. Lab resolvido.

Takeaway

#

Condições SQL nunca devem ser usadas como controle de acesso — qualquer injeção bypassa o mecanismo completo. A correção é prepared statements, não validação de input.

Em campo: parâmetros GET de filtragem são alvos frequentemente ignorados por parecerem “inofensivos”. Sempre testar.