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

Übersicht

Eine schwerwiegende SQL-Injection-Sicherheitslücke wurde in der Komponente search_products.php des Grocery Store Management System 1.0 entdeckt, einer PHP/MySQL-basierten Webanwendung von anirudhkannan.
Das Problem entsteht durch fehlerhafte Eingabevalidierung und die unsichere Konstruktion von SQL-Abfragen unter Verwendung des benutzergesteuerten Parameters scost. Diese Schwachstelle ermöglicht es Angreifern, die zugrunde liegende SQL-Logik zu manipulieren, was potenziell zur Offenlegung sensibler Daten, zur Datenänderung oder zur vollständigen Kompromittierung der Datenbank führen kann.

---

Betroffenes Produkt

• Name: Grocery Store Management System
• Anbieter: anirudhkannan
• Version: 1.0
• Repository:
  https://github.com/anirudhkannanvp/GROCERY-STORE-MANAGEMENT-SYSTEM-USING-PHP-AND-MYSQL-PHPMYADMIN-/tree/master
• Betroffene Datei:
  Grocery/search_products.php

---

Beschreibung der Schwachstelle

Die Sicherheitslücke besteht aufgrund der direkten Verkettung von unvalidierter Benutzereingabe in SQL-Abfragen.
Der POST-Parameter scost, der einen numerischen Produktkostenwert darstellen soll, wird ohne:

• Eingabesanitierung
• Typüberprüfung
• Parametrisierte Abfragen
• Verwendung von Prepared Statements

in die SQL-WHERE-Klausel eingebettet.

Dies erlaubt es einem Angreifer, beliebige SQL-boolesche Ausdrücke einzuschleusen, das Abfrageverhalten zu ändern und Datenbankinhalte mittels boolean-basierter SQL-Injection-Techniken zu extrahieren.

Die Schwachstelle ist durch eine standardmäßige POST-Anfrage an search_products.php ausnutzbar. Wenn bösartige Ausdrücke übergeben werden, liefert das Backend messbare Antwortunterschiede (TRUE/FALSE-Variationen), was bestätigt, dass die Benutzereingabe die SQL-Logik beeinflusst.

---

Grundursache

• Fehlende serverseitige Validierung des scost-Eingabefelds
• Direkte Verwendung von Zeichenkettenverkettung zum Erstellen von SQL-Abfragen
• Fehlen von Prepared Statements im betroffenen Codepfad
• Keine Filterung oder Whitelisting für numerische Eingabefelder

Diese Bedingungen ermöglichen es Angreifern gemeinsam, die beabsichtigte SQL-Logik zu verändern.

---

Schweregrad & Auswirkungen

Diese Schwachstelle wird aufgrund ihrer geringen Angriffskomplexität, des Fehlens von Authentifizierungsanforderungen und der vollständigen Lese-/Schreib-Auswirkung auf die Datenbank als Hoch eingestuft.

Mögliche Auswirkungen umfassen:

• Offenlegung sensibler Daten: Angreifer können Produkt-, Benutzer- oder Systemdaten extrahieren.
• Datenänderung oder -löschung: Injiziertes SQL kann Datenbankeinträge verändern oder entfernen.
• Authentifizierungsumgehung (möglich): Falls in anderen Teilen der Abfragelogik der Anwendung verwendet.
• Vollständige Datenbankkompromittierung: Abhängig von Datenbankberechtigungen und -konfiguration.
• Systeminstabilität: Bösartige Abfragen könnten das normale Anwendungsverhalten stören.

---

CVSS v3.1-Score (Vorläufige Bewertung)

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

• Angriffsvektor (AV): Netzwerk
• Angriffskomplexität (AC): Niedrig
• Erforderliche Berechtigungen (PR): Keine
• Benutzerinteraktion (UI): Keine
• Scope (S): Unverändert
• Vertraulichkeit (C): Hoch
• Integrität (I): Hoch
• Verfügbarkeit (A): Hoch

Geschätzter Schweregrad: Hoch (9.8)

---

Ausnutzungszusammenfassung

Die Schwachstelle kann durch manipulierte Werte ausgenutzt werden, die an den Parameter scost übergeben werden.
Angreifer können:

• Boolesche Logik beeinflussen
• Bedingte Antworten auslösen
• Datenbankstrukturen enumerieren
• Sensible Informationen extrahieren

(Detaillierte Payloads werden absichtlich weggelassen, um Missbrauch zu verhindern.)

---

Abhilfe & Empfehlungen

Für Entwickler / Anbieter

Um die Sicherheitslücke zu beheben:

1. Prepared Statements / parametrisierte Abfragen implementieren
2. Strenge Eingabevalidierung durchsetzen — sicherstellen, dass scost nur numerische Werte akzeptiert
3. Verdächtige Zeichen zurückweisen — Operatoren, Anführungszeichen, Kommentare und Ausdruckssymbole filtern
4. Datenbankberechtigungen nach dem Prinzip der geringsten Privilegien anwenden
5. Den Codebase auf ähnliche Muster an anderen Stellen der Anwendung prüfen

Für Benutzer

Bis ein Patch verfügbar ist:

• Den öffentlichen Zugriff auf die Anwendung einschränken
• Eine Firewall oder ein WAF verwenden, um bösartige Anfragen zu blockieren
• Protokolle auf ungewöhnliches SQL-bezogenes Verhalten überwachen

---

Referenzen

• OWASP SQL Injection: https://owasp.org/www-community/attacks/SQL_Injection
• CWE-89 — Fehlerhafte Neutralisierung spezieller Elemente in SQL-Befehlen