Nota: Este aviso exclui intencionalmente um payload de exploração executável. Detalhes de prova de conceito foram compartilhados de forma privada com o mantenedor para permitir a correção.

Endpoint afetado (exemplo)

URL de teste local de exemplo:

Detalhes da vulnerabilidade

• Tipo: Injeção SQL (Cega Baseada em Tempo)
• Parâmetro: product_id (GET)
• Localização: admin/admin/edit_product.php
• Vetor de ataque: Remoto (URL manipulada); nenhuma autenticação é necessária se o endpoint administrativo estiver publicamente acessível ou alcançável pelo atacante.
• Pré-condições: O endpoint deve aceitar o parâmetro product_id e incluí-lo em uma instrução SQL sem parametrização.

Evidências (resumo dos testes de temporização)

Tentativas de injeção baseadas em temporização usando a semântica SLEEP() do banco de dados produziram atrasos mensuráveis no servidor, consistentes com uma injeção bem-sucedida:

• SLEEP(6) → atraso de resposta observado ≈ 6,01s
• SLEEP(15) → atraso de resposta observado ≈ 15,00s
• SLEEP(0) → atraso de resposta de linha de base ≈ 0,01s

Esses resultados indicam um ponto de injeção SQL cega que permite inferência baseada em tempo. O nome do banco de dados observado durante os testes: onlineshop.

Impacto

A exploração bem-sucedida desta vulnerabilidade permite que atacantes:

• Confirmem e enumerem o conteúdo do banco de dados por meio de técnicas cegas/baseadas em tempo.
• Exfiltrem dados (esquema, nomes de tabelas, linhas) com ferramentas automatizadas (ex.: sqlmap) usando técnicas baseadas em tempo.
• Potencialmente escalem para comprometimento adicional, dependendo dos privilégios do banco de dados e do contexto da aplicação.

Severidade estimada: Alta

Reprodução (alto nível)

1. Envie uma solicitação manipulada ao parâmetro product_id que inclua construções SQL de atraso de tempo (testes realizados com variações de SLEEP()).
2. Observe o tempo de resposta do servidor para inferir se a expressão injetada foi executada.
3. Testes repetidos com diferentes payloads permitem extração automatizada por meio de técnicas baseadas em tempo.

PoC passo a passo completo omitido do aviso público — entre em contato com o relator para obter o PoC criptografado sob os termos de divulgação responsável.

Correção recomendada

1. Use consultas parametrizadas / prepared statements para todo acesso ao banco de dados. Não concatene entrada do usuário em strings SQL.
   • Exemplo (PHP + PDO):
     root@kitploit:~

     $stmt = $pdo->prepare('SELECT * FROM products WHERE id = ?');
     $stmt->execute([$product_id]);
     

2. Valide e sanitize a entrada: trate product_id como um inteiro e valide de acordo (ex.: filter_input(INPUT_GET, 'product_id', FILTER_VALIDATE_INT)).
3. Privilégio mínimo: garanta que o usuário do banco de dados usado pela aplicação web tenha privilégios mínimos (evite DROP, ALTER, GRANT ou direitos administrativos).
4. Tratamento de erros: evite vazar erros do banco de dados para o cliente. Use mensagens de erro genéricas e registre erros detalhados no lado do servidor.
5. WAF / limitação de taxa: como mitigação temporária, implemente regras de WAF para detectar padrões comuns de SQLi e aplique limites de taxa para retardar tentativas de extração em massa.
6. Audite endpoints relacionados: revise outros endpoints e parâmetros administrativos para padrões de injeção semelhantes.

Comando sqlmap sugerido

(Incluído para conveniência do fornecedor/mantenedor — não publique payloads de PoC publicamente)

Referências

• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection

Contato / Créditos

Descobridor: Hafiz Pradana Gemilang

• Email: [email protected]
• GitHub: https://github.com/hafizgemilang/CVE-2025-52021

Fornecedor / Repositório: https://github.com/PuneethReddyHC/online-shopping-system-advanced

Aviso legal: Este aviso público omite payloads exploráveis para proteger os usuários. Detalhes técnicos completos e PoC estão disponíveis para o fornecedor mediante solicitação, sob uma política de divulgação responsável acordada.