CVE-2025-63943 — SQL Injection in Grocery Store Management System 1.0

Panoramica

È stata identificata una vulnerabilità di SQL Injection ad alta severità nel componente search_products.php di Grocery Store Management System 1.0, un'applicazione web basata su PHP/MySQL creata da anirudhkannan.
Il problema deriva da una validazione impropria degli input e dalla costruzione non sicura delle query SQL utilizzando il parametro scost controllato dall'utente. Questa falla consente agli attaccanti di manipolare la logica SQL sottostante, portando potenzialmente all'esposizione di dati sensibili, alla modifica dei dati o al completo compromesso del database.

---

Prodotto interessato

• Nome: Grocery Store Management System
• Vendor: anirudhkannan
• Versione: 1.0
• Repository:
  https://github.com/anirudhkannanvp/GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHPMYADMIN-/tree/master
• File interessato:
  Grocery/search_products.php

---

Descrizione della vulnerabilità

La vulnerabilità esiste a causa della concatenazione diretta di input utente non validato nelle query SQL.
Il parametro POST scost, pensato per rappresentare un valore numerico del costo del prodotto, viene incorporato nella clausola WHERE SQL senza:

• Sanificazione dell'input
• Applicazione del tipo di dato
• Query parametrizzate
• Utilizzo di prepared statement

Ciò consente a un attaccante di iniettare espressioni booleane SQL arbitrarie, alterando il comportamento della query ed estraendo il contenuto del database tramite tecniche di SQL Injection basata su booleani.

La vulnerabilità è sfruttabile tramite una richiesta POST standard a search_products.php. Quando vengono fornite espressioni dannose, il backend restituisce differenze misurabili nelle risposte (variazioni VERO/FALSO), confermando che l'input utente influenza la logica SQL.

---

Causa principale

• Mancanza di validazione lato server sul campo di input scost
• Uso diretto della concatenazione di stringhe per costruire query SQL
• Assenza di prepared statement nel percorso di codice interessato
• Nessun filtro o whitelist per i campi di input numerici

Queste condizioni consentono collettivamente agli attaccanti di modificare la logica SQL prevista.

---

Severità e impatto

Questa vulnerabilità è classificata come Alta a causa della bassa complessità di attacco, dell'assenza di requisiti di autenticazione e dell'impatto pieno di lettura/scrittura sul database.

Impatti potenziali:

• Esposizione di dati sensibili: gli attaccanti possono estrarre dati di prodotti, utenti o di sistema.
• Modifica o cancellazione dei dati: SQL iniettato può alterare o rimuovere voci del database.
• Bypass dell'autenticazione (possibile): se utilizzata in altre parti della logica delle query dell'applicazione.
• Compromissione totale del database: a seconda dei privilegi e della configurazione del DB.
• Instabilità del sistema: query dannose potrebbero interrompere il normale comportamento dell'applicazione.

---

Punteggio CVSS v3.1 (Valutazione preliminare)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• Vettore di attacco (AV): Rete
• Complessità di attacco (AC): Bassa
• Privilegi richiesti (PR): Nessuno
• Interazione utente (UI): Nessuna
• Scope (S): Invariato
• Riservatezza (C): Alta
• Integrità (I): Alta
• Disponibilità (A): Alta

Severità stimata: Alta (9.8)

---

Riepilogo dello sfruttamento

La vulnerabilità può essere sfruttata tramite valori appositamente costruiti passati al parametro scost.
Gli attaccanti possono:

• Influenzare la logica booleana
• Attivare risposte condizionali
• Enumerare le strutture del database
• Estrarre informazioni sensibili

(I payload dettagliati sono stati volutamente omessi per prevenire un uso improprio.)

---

Mitigazione e raccomandazioni

Per sviluppatori / vendor

Per rimediare alla vulnerabilità:

1. Implementare prepared statement / query parametrizzate
2. Applicare una validazione rigorosa dell'input — assicurarsi che scost accetti solo valori numerici
3. Rifiutare caratteri sospetti — filtrare operatori, virgolette, commenti e simboli di espressioni
4. Applicare permessi di database con privilegi minimi
5. Controllare il codebase per individuare pattern simili altrove nell'applicazione

Per utenti

Fino a quando non sarà disponibile una patch:

• Limitare l'accesso pubblico all'applicazione
• Utilizzare un firewall o WAF per bloccare richieste dannose
• Monitorare i log per attività SQL anomale

---

Riferimenti

• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
• CWE-89 — Improper Neutralization of Special Elements in SQL Commands