🚀 Prova de Conceito (PoC) — SQLi cega baseada em tempo

Teste apenas em ambientes autorizados / laboratoriais. NÃO execute contra sistemas que você não possua ou para os quais não tenha permissão explícita para testar.

Solicitação PoC (exemplo):

Passos para confirmar

1. Autentique-se na instância Frappe/ERPNext de destino com um usuário que possa acessar a API de relatórios/get_value.
2. Envie a solicitação GET acima (ou payload equivalente codificado em URL).
3. Observe o tempo de resposta; se a resposta for atrasada em ~15 segundos, isso indica injeção baseada em tempo bem-sucedida.
4. Repita a mesma solicitação para confirmar a reprodutibilidade.
5. Remova o payload +%2F+sleep(15)+& injetado e observe que a resposta retorna imediatamente — confirmando que a injeção causa o atraso de tempo.

Notas: Substitua sleep(15) por outras funções de tempo ou valores de tempo adequados ao SGBD do backend (por exemplo, pg_sleep(n) para PostgreSQL), dependendo do mecanismo de banco de dados. A PoC demonstra injeção cega por meio de temporização; payloads mais complexos poderiam ser usados para extrair dados bit a bit.

🧪 Vetores de Ataque e Impacto

• Vetor de ataque: Usuário autenticado cria solicitações GET para /api/method/frappe.client.get_value com um parâmetro fieldname malicioso contendo payloads de SQL (funções de atraso de tempo).

• Impacto:

  • Negação de Serviço: Atrasos forçados na resposta do servidor (esgotamento de recursos se abusado).
  • Divulgação de Informações: Extração cega de dados por meio de técnicas baseadas em tempo (consultas bit a bit/condicionais por tempo).
  • Manipulação de Dados: Capacidade potencial de alterar o estado do banco de dados se outros vetores de injeção de SQL estiverem disponíveis.
  • Outros: Escalonamento do impacto dependendo dos privilégios de banco de dados disponíveis para o usuário da aplicação.

🔐 Recomendações de Mitigação

1. Consultas Parametrizadas / Declarações Preparadas: Garanta que o fieldname e toda entrada fornecida pelo usuário nunca sejam concatenados diretamente no SQL. Use consultas parametrizadas ou APIs ORM que façam a vinculação adequada dos parâmetros.
2. Validação Estrita de Entrada / Lista de Permissões: Para parâmetros que devem ser nomes de campos ou identificadores, valide contra uma lista rigorosa de nomes de campos válidos conhecidos ou use mapeamento no lado do servidor, em vez de aceitar identificadores brutos dos clientes.
3. Escape Seguro de Identificadores: Se identificadores precisarem ser usados dinamicamente, use funções seguras de citação/escape de identificadores específicas do banco de dados — e, ainda assim, restrinja os valores permitidos.
4. Conta de Banco de Dados com Privilégios Mínimos: Execute a aplicação com um usuário de banco de dados que tenha apenas os privilégios necessários (somente leitura, quando possível, para endpoints de relatórios).
5. Limitação de Taxa e Monitoramento: Aplique limites de taxa e detecte padrões de solicitação anômalos ou testes repetidos de atraso de tempo; alerte sobre tráfego suspeito.
6. Auditoria e Registros (Logs): Registre solicitações a endpoints sensíveis da API e monitore payloads suspeitos (por exemplo, sleep, pg_sleep, benchmark, /, ;).
7. Correção e Lançamento de Patch: Os desenvolvedores do Frappe/ERPNext devem auditar frappe.client.get_value e o caminho de código que lida com fieldname/filtros, substituir a concatenação insegura por APIs seguras e lançar um patch de segurança. Os operadores devem aplicar as atualizações prontamente.
8. Testes de Segurança: Adicione testes automatizados para detectar injeção de SQL (incluindo a cega baseada em tempo) nos endpoints da API.

🔗 Referências

• Descobridor / Relator: Mohammed Aloli — GitHub: https://github.com/MoAlali — X: https://x.com/alaliksa_ — LinkedIn: https://www.linkedin.com/in/mohammedaloli/
• Códigos-fonte Frappe / ERPNext (revisão e patch): https://github.com/frappe/frappe , https://github.com/frappe/erpnext
• Orientação geral sobre SQLi: Folha de Dicas (Cheat Sheet) de Prevenção de Injeção de SQL da OWASP — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

🙏 Agradecimentos

Descoberto por Mohammed Aloli

📢 Aviso Legal

Esta informação é fornecida apenas para fins defensivos e de remediação. Não tente explorar esta vulnerabilidade contra sistemas que você não possua ou para os quais não tenha autorização explícita para testar. Os operadores devem priorizar a aplicação de patches, adotar correções de codificação segura e seguir as orientações de mitigação acima.