Wie der Angriff funktioniert

Der Kern jeder Injection ist die fehlende Trennung von Code und Daten. Eine Anwendung baut dynamische Abfragen oder Befehle per String-Verkettung mit Benutzereingaben zusammen.

Der Interpreter (SQL-Datenbank, NoSQL-Engine, Shell) kann dann nicht mehr unterscheiden, was ursprünglich gemeintes Kommando und was eingeschleuste Eingabe ist.

  • SQL: Eine WHERE-Klausel wird per Konkatenation gebildet, der Angreifer schmuggelt mit Zeichen wie ', -- oder OR 1=1 zusätzliche SQL-Logik ein.
  • NoSQL/MongoDB: Statt eines Strings sendet der Angreifer in einem JSON-Body ein verschachteltes Objekt mit Query-Operatoren, etwa {"$ne":"invalid"} oder {"$in":[...]}, die die Abfragelogik umbiegen; manche Engines erlauben über $where sogar JavaScript-Ausführung.
  • OS-Command: Benutzereingabe gelangt in einen an die Shell übergebenen Befehl; Metazeichen wie &, |, ; oder ` verketten zusätzliche Befehle (PortSwigger nennt & && | || als systemübergreifende Befehlstrenner).

Laut OWASP gilt durchgehend: Erst eine parametrisierte/sichere API trennt Code und Daten zuverlässig. Prepared Statements binden alle SQL-Teile vorab und behandeln Eingaben rein als Werte.

1. AusgangslageUngeprüfte Eingabe im Request oder JSON
→
2. AngriffWird in SQL, NoSQL oder einen Befehl eingeschleust
→
3. ErgebnisDaten ausgelesen oder Befehl ausgeführt

Ungeprüfte Eingaben landen ungetrennt in Abfragen oder Befehlen.

Beispiel

NoSQL-Operator-Injection zur Authentifizierungs-Umgehung über einen JSON-Login (PortSwigger).

  1. Erwartete Anfrage an eine Login-API: POST mit Content-Type: application/json und Body {"username":"wiener","password":"peter"} . Die App baut daraus eine MongoDB-Abfrage, die Benutzername und Passwort vergleicht.
  2. Angriff - der Client ersetzt die String-Werte durch verschachtelte Operator-Objekte: {"username":{"$ne":"invalid"},"password":{"$ne":"invalid"}} .
  3. Wirkung laut PortSwigger: Werden beide Eingaben als Operator verarbeitet, liefert die Abfrage alle Datensätze, bei denen Benutzername und Passwort ungleich "invalid" sind - der Angreifer wird ohne gültiges Passwort als erster Nutzer der Collection eingeloggt.
  4. Gezielt auf ein bekanntes/erratenes Konto lässt sich laut PortSwigger ein Payload bauen wie: {"username":{"$in":["admin","administrator","superadmin"]},"password":{"$ne":""}} .

Quelle: PortSwigger.

Auswirkung

Unbefugter Zugriff auf sensible Daten (Passwörter, Kreditkartendaten, personenbezogene Daten), Veränderung oder Löschung von Daten sowie Umgehung von Authentifizierung und Zugriffskontrollen.

SQL-Injection war laut PortSwigger Ursache vieler hochkarätiger Datenpannen mit Reputationsschaden und regulatorischen Strafen, teils mit dauerhaftem Backdoor-Zugang.

NoSQL-Injection kann laut PortSwigger zusätzlich Authentifizierung umgehen, Daten extrahieren/ändern, Denial of Service verursachen und Code auf dem Server ausführen.

OS-Command-Injection führt typischerweise zur vollständigen Kompromittierung von Anwendung und Daten und erlaubt das Weiterspringen (Pivoting) auf andere Systeme der Infrastruktur.

So schützt man sich

  • Sichere/parametrisierte APIs verwenden (OWASP-Hauptverteidigung): bei SQL Prepared Statements mit Variablen-Binding bzw. parametrisierte Abfragen; analog ORM-/HQL-Named-Parameter - dadurch trennt die Datenbank Code und Daten unabhängig von der Eingabe.
  • OS-Befehle möglichst gar nicht direkt aufrufen - stattdessen Bibliotheksfunktionen nutzen (z.B. mkdir() statt system("mkdir ...")); lässt sich der Aufruf nicht vermeiden, Parametrisierung (z.B. Javas ProcessBuilder mit getrennten Argumenten, kein Shell-Aufruf) plus Eingabevalidierung kombinieren.
  • Positive/Allowlist-Eingabevalidierung als zusätzliche Schicht (nicht als alleinige Verteidigung): Befehle gegen eine erlaubte Liste prüfen, Argumente per strikter Allowlist-Regex inkl. Längenbegrenzung und ohne Metazeichen (& | ; $ > < ` \ ! ' " ( )) und ohne Whitespace.
  • Bei NoSQL/JSON-APIs erwartete Datentypen erzwingen: Werte als String validieren und verschachtelte Operator-Objekte ablehnen, damit keine $ne/$in/$where-Operatoren in die Abfrage gelangen.
  • Falls keine parametrisierte API verfügbar ist, Eingaben kontextspezifisch mit der korrekten Escape-Syntax des jeweiligen Interpreters maskieren (von OWASP nur als letzte Option, für SQL ausdrücklich als STRONGLY DISCOURAGED eingestuft).
  • Least Privilege umsetzen: Datenbank- und Prozessrechte minimal halten, isolierte Konten mit begrenzten Rechten pro Aufgabe, um den Schaden im Falle einer Ausnutzung zu begrenzen.

Quellen

Weiterlesen
ÜbersichtOWASP API Security Top 10 AngriffCredential Stuffing & Account Takeover