Nota: questo advisory esclude intenzionalmente un payload di sfruttamento eseguibile. I dettagli della proof-of-concept sono stati condivisi privatamente con il maintainer per consentire la correzione.

Endpoint interessato (esempio)

Esempio di URL di test locale:

Dettagli della vulnerabilità

• Tipo: SQL Injection (cieca basata sul tempo)
• Parametro: product_id (GET)
• Posizione: admin/admin/edit_product.php
• Vettore di attacco: Remoto (URL appositamente costruito); nessuna autenticazione richiesta se l'endpoint admin è pubblicamente accessibile o raggiungibile dall'attaccante.
• Precondizioni: L'endpoint deve accettare il parametro product_id e includerlo in un'istruzione SQL senza parametrizzazione.

Evidenze (riepilogo test di temporizzazione)

I tentativi di injection basati sulla temporizzazione utilizzando la semantica SLEEP() del database hanno prodotto ritardi misurabili lato server coerenti con un'injection riuscita:

• SLEEP(6) → ritardo di risposta osservato ≈ 6.01s
• SLEEP(15) → ritardo di risposta osservato ≈ 15.00s
• SLEEP(0) → ritardo di risposta di base ≈ 0.01s

Questi risultati indicano un punto di SQL injection cieca che consente l'inferenza basata sul tempo. Nome del database osservato durante i test: onlineshop.

Impatto

Lo sfruttamento riuscito di questa vulnerabilità consente agli attaccanti di:

• Confermare ed enumerare il contenuto del database tramite tecniche cieche/basate sul tempo.
• Esfiltrare dati (schema, nomi di tabelle, righe) con strumenti automatizzati (es. sqlmap) utilizzando tecniche basate sul tempo.
• Potenzialmente escalare a ulteriori compromissioni a seconda dei privilegi del database e del contesto applicativo.

Severità stimata: Alta

Riproduzione (livello generale)

1. Inviare una richiesta appositamente costruita al parametro product_id che includa costrutti SQL con ritardo temporale (test eseguiti con variazioni di SLEEP()).
2. Osservare il tempo di risposta del server per dedurre se l'espressione iniettata è stata eseguita.
3. Test ripetuti con payload diversi consentono l'estrazione automatizzata tramite tecniche basate sul tempo.

La PoC completa passo-passo è omessa dall'advisory pubblico — contattare il reporter per una PoC cifrata secondo i termini di divulgazione responsabile.

Raccomandazioni per la correzione

1. Utilizzare query parametrizzate / prepared statements per tutti gli accessi al database. Non concatenare input utente nelle stringhe SQL.
   • Esempio (PHP + PDO):
     root@kitploit:~

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

2. Validare e sanificare l'input: trattare product_id come un intero e validarlo di conseguenza (es. filter_input(INPUT_GET, 'product_id', FILTER_VALIDATE_INT)).
3. Privilegio minimo: assicurarsi che l'utente del database utilizzato dall'applicazione web abbia privilegi minimi (evitare DROP, ALTER, GRANT o diritti amministrativi).
4. Gestione degli errori: evitare di divulgare errori del database al client. Utilizzare messaggi di errore generici e registrare gli errori dettagliati lato server.
5. WAF / rate-limiting: come mitigazione temporanea, implementare regole WAF per rilevare pattern SQLi comuni e applicare limiti di frequenza per rallentare i tentativi di estrazione di massa.
6. Audit degli endpoint correlati: rivedere altri endpoint e parametri admin per pattern di injection simili.

Comando sqlmap suggerito

(Incluso per comodità del vendor/maintainer — non pubblicare payload PoC pubblicamente)

Riferimenti

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

Contatti / Crediti

Scopritore: Hafiz Pradana Gemilang

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

Vendor / Repo: https://github.com/PuneethReddyHC/online-shopping-system-advanced

Disclaimer: Questo advisory pubblico omette payload sfruttabili per proteggere gli utenti. I dettagli tecnici completi e la PoC sono disponibili al vendor su richiesta secondo una politica di divulgazione responsabile concordata.