🚀 Prova di concetto (PoC) — SQLi cieca basata sul tempo

Effettuare test solo in ambienti autorizzati / di laboratorio. NON eseguire contro sistemi di cui non si è proprietari o per i quali non si ha il permesso esplicito di testare.

Richiesta PoC (esempio):

Passaggi per la conferma

1. Autenticarsi all'istanza Frappe/ERPNext target con un utente che possa accedere all'API di reporting/get_value.
2. Inviare la richiesta GET sopra indicata (o il payload equivalente codificato in URL).
3. Osservare il tempo di risposta; se la risposta viene ritardata di ~15 secondi, ciò indica che l'iniezione basata sul tempo è riuscita.
4. Ripetere la stessa richiesta per confermare la riproducibilità.
5. Rimuovere il payload iniettato +%2F+sleep(15)+& e osservare che la risposta torna immediata — confermando che l'iniezione causa il ritardo temporale.

Note: Sostituire sleep(15) con altre funzioni temporali o valori di tempo adatti al DBMS sottostante (ad es., pg_sleep(n) per PostgreSQL) a seconda del motore di database. Il PoC dimostra l'iniezione cieca tramite timing; payload più complessi potrebbero essere usati per estrarre i dati bit per bit.

🧪 Vettori di attacco e impatto

• Vettore di attacco: Un utente autenticato crea richieste GET a /api/method/frappe.client.get_value con un parametro fieldname malizioso contenente payload SQL (funzioni di ritardo temporale).

• Impatto:

  • Denial of Service: ritardi forzati nella risposta del server (esaurimento delle risorse se abusato).
  • Divulgazione di informazioni: estrazione cieca dei dati tramite tecniche basate sul tempo (query bitwise/condizionate dal tempo).
  • Manipolazione dei dati: potenziale capacità di alterare lo stato del database se sono disponibili altri vettori di SQL injection.
  • Altro: escalation dell'impatto a seconda dei privilegi sul database disponibili per l'utente dell'applicazione.

🔐 Raccomandazioni di mitigazione

1. Query parametrizzate / Prepared Statement: assicurarsi che fieldname e tutti gli input forniti dall'utente non vengano mai concatenati direttamente in SQL. Utilizzare query parametrizzate o API ORM che legano correttamente i parametri.
2. Validazione rigorosa degli input / whitelisting: per i parametri che dovrebbero essere nomi di campi o identificatori, validare rispetto a un allowlist rigoroso di nomi di campo validi noti o utilizzare una mappatura lato server invece di accettare identificatori di campo grezzi dai client.
3. Escape sicuro degli identificatori: se gli identificatori devono essere usati dinamicamente, utilizzare funzioni sicure di quoting/escaping specifiche del database — e comunque limitare i valori consentiti.
4. Account database con privilegi minimi: eseguire l'applicazione con un utente del database che abbia solo i privilegi necessari (sola lettura dove possibile per gli endpoint di reporting).
5. Rate limiting e monitoraggio: applicare limiti di frequenza e rilevare pattern di richieste anomali o test ripetuti di ritardo temporale; generare alert sul traffico sospetto.
6. Audit e logging: registrare le richieste agli endpoint API sensibili e monitorare payload sospetti (ad es., sleep, pg_sleep, benchmark, /, ;).
7. Patch e rilascio: gli sviluppatori di Frappe/ERPNext dovrebbero esaminare frappe.client.get_value e il percorso del codice che gestisce fieldname/filtri, sostituire la concatenazione non sicura con API sicure e rilasciare una patch di sicurezza. Gli operatori dovrebbero applicare gli aggiornamenti tempestivamente.
8. Test di sicurezza: aggiungere test automatizzati per rilevare SQL injection (inclusa quella cieca basata sul tempo) negli endpoint API.

🔗 Riferimenti

• Scopritore / Segnalatore: Mohammed Aloli — GitHub: https://github.com/MoAlali — X: https://x.com/alaliksa_ — LinkedIn: https://www.linkedin.com/in/mohammedaloli/
• Codebase Frappe / ERPNext (revisione e patch): https://github.com/frappe/frappe , https://github.com/frappe/erpnext
• Guida generale sulla SQLi: OWASP SQL Injection Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

🙏 Riconoscimenti

Scoperto da Mohammed Aloli

📢 Esclusione di responsabilità

Queste informazioni sono fornite esclusivamente a scopo difensivo e di remediation. Non tentare di sfruttare questa vulnerabilità contro sistemi di cui non si è proprietari o per i quali non si ha esplicita autorizzazione al test. Gli operatori dovrebbero dare priorità all'applicazione delle patch, applicare correzioni di codifica sicura e seguire le indicazioni di mitigazione sopra riportate.