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

Vue d'ensemble

Une vulnérabilité d'injection SQL de haute sévérité a été identifiée dans le composant search_products.php de Grocery Store Management System 1.0, une application web basée sur PHP/MySQL créée par anirudhkannan.
Le problème provient d'une validation incorrecte des entrées et de la construction non sécurisée de requêtes SQL utilisant le paramètre scost contrôlé par l'utilisateur. Cette faille permet aux attaquants de manipuler la logique SQL sous-jacente, ce qui peut conduire à l'exposition de données sensibles, à leur altération ou à un compromis total de la base de données.

---

Produit affecté

• Nom : Grocery Store Management System
• Éditeur : anirudhkannan
• Version : 1.0
• Dépôt :
  https://github.com/anirudhkannanvp/GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHPMYADMIN-/tree/master
• Fichier concerné :
  Grocery/search_products.php

---

Description de la vulnérabilité

La vulnérabilité existe en raison de la concaténation directe d'entrées utilisateur non validées dans des requêtes SQL.
Le paramètre POST scost, censé représenter une valeur numérique de coût de produit, est intégré dans la clause WHERE SQL sans :

• Assainissement des entrées
• Contrôle de type
• Requêtes paramétrées
• Utilisation de requêtes préparées

Cela permet à un attaquant d'injecter des expressions booléennes SQL arbitraires, modifiant le comportement de la requête et extrayant le contenu de la base de données à l'aide de techniques d'injection SQL booléenne.

La vulnérabilité est exploitable via une requête POST standard envoyée à search_products.php. Lorsque des expressions malveillantes sont fournies, le backend renvoie des différences de réponse mesurables (variations VRAI/FAUX), confirmant que l'entrée utilisateur influence la logique SQL.

---

Cause racine

• Absence de validation côté serveur sur le champ d'entrée scost
• Utilisation directe de la concaténation de chaînes pour construire les requêtes SQL
• Absence de requêtes préparées dans le chemin de code concerné
• Aucun filtrage ni liste blanche pour les champs d'entrée numériques

Ces conditions permettent collectivement aux attaquants de modifier la logique SQL prévue.

---

Sévérité et impact

Cette vulnérabilité est classée Haute en raison de sa faible complexité d'attaque, de l'absence d'exigences d'authentification et de l'impact complet en lecture/écriture sur la base de données.

Impacts potentiels :

• Exposition de données sensibles : les attaquants peuvent extraire des données de produits, d'utilisateurs ou du système.
• Modification ou suppression de données : le SQL injecté peut altérer ou supprimer des entrées de la base de données.
• Contournement d'authentification (possible) : si utilisé dans d'autres parties de la logique de requête de l'application.
• Compromission totale de la base de données : selon les privilèges et la configuration de la base de données.
• Instabilité du système : des requêtes malveillantes pourraient perturber le comportement normal de l'application.

---

Score CVSS v3.1 (évaluation préliminaire)

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

• Vecteur d'attaque (AV) : Réseau
• Complexité d'attaque (AC) : Faible
• Privilèges requis (PR) : Aucun
• Interaction utilisateur (UI) : Aucune
• Portée (S) : Inchangée
• Confidentialité (C) : Haute
• Intégrité (I) : Haute
• Disponibilité (A) : Haute

Sévérité estimée : Haute (9.8)

---

Résumé de l'exploitation

La vulnérabilité peut être exploitée via des valeurs forgées transmises au paramètre scost.
Les attaquants peuvent :

• Influencer la logique booléenne
• Déclencher des réponses conditionnelles
• Énumérer les structures de la base de données
• Extraire des informations sensibles

(Les détails des payloads sont volontairement omis pour éviter toute utilisation abusive.)

---

Atténuation et recommandations

Pour les développeurs / éditeurs

Pour remédier à la vulnérabilité :

1. Mettre en œuvre des requêtes préparées / paramétrées
2. Appliquer une validation stricte des entrées — s'assurer que scost n'accepte que des valeurs numériques
3. Rejeter les caractères suspects — filtrer les opérateurs, guillemets, commentaires et symboles d'expression
4. Appliquer le principe du moindre privilège pour les permissions de la base de données
5. Auditer le code pour rechercher des modèles similaires ailleurs dans l'application

Pour les utilisateurs

En attendant qu'un correctif soit disponible :

• Restreindre l'accès public à l'application
• Utiliser un pare-feu ou un WAF pour bloquer les requêtes malveillantes
• Surveiller les journaux pour détecter tout comportement SQL inhabituel

---

Références

• OWASP Injection SQL : https://owasp.org/www-community/attacks/SQL_Injection
• CWE-89 — Neutralisation incorrecte d'éléments spéciaux dans les commandes SQL