Was ist NoSQL Injection?

NoSQL Injection ist eine Injection-Schwachstelle in Datenbanken wie MongoDB sowie anderen Dokumenten-, Key-Value- oder Graphdatenbanken. NoSQL bedeutet nicht, dass keine Injection möglich ist. Die Syntax ist lediglich anders: Statt eines normalen Werts übermittelt ein Angreifer beispielsweise Abfrageoperatoren, JavaScript-Ausdrücke oder einen unerwarteten Datentyp.

Ein Login-Endpunkt erwartet möglicherweise einen String als Passwort, akzeptiert aber auch ein Objekt mit einem Vergleichsoperator. Wird dieses Objekt direkt in die Datenbankabfrage übernommen, verändert es die Bedingung und kann die Authentifizierung umgehen. Andere Angriffe lesen Datensätze aus, ändern Filter oder lösen teure Abfragen aus.

Wie lässt sich NoSQL Injection verhindern?

• - Datentyp und erlaubten Inhalt jeder Eingabe vor dem Aufbau einer Abfrage prüfen.
• - Sichere Abfrage-APIs des Datenbanktreibers verwenden und Request-Objekte nie direkt in Query-Objekte übernehmen.
• - Serverseitiges Scripting deaktivieren, wenn es nicht benötigt wird, und das Datenbankkonto einschränken.
• - JSON- und verschachtelte Parameter ebenso sorgfältig testen wie klassische Formularfelder.

Codebeispiel: Request-Objekt nicht als MongoDB-Query übernehmen

Verwundbar: Der Client darf ein Objekt mit Operatoren senden.

const user = await users.findOne({
  email: req.body.email,
  password: req.body.password
});

Sicherer Datenfluss:

if (typeof req.body.email !== 'string' ||
    typeof req.body.password !== 'string') {
  return res.status(400).end();
}

const user = await users.findOne({ email: req.body.email });
if (!user || !await argon2.verify(user.passwordHash, req.body.password)) {
  return res.status(401).end();
}

Die Typprüfung verhindert, dass etwa ein Operatorobjekt anstelle eines Strings in die Query gelangt. Passwörter werden außerdem nicht in der Datenbankabfrage verglichen, sondern als Hash mit einer dafür vorgesehenen Passwortfunktion verifiziert.

Was unterscheidet NoSQL und SQL Injection?

SQL Injection manipuliert häufig einen Abfragestring. NoSQL Injection missbraucht oft strukturierte Objekte und Typverwechslungen. Beide entstehen, wenn Daten eine Vertrauensgrenze überschreiten, ohne sicher begrenzt zu werden.

Welche Varianten gibt es?

• Operator Injection:
  Ein erwarteter Einzelwert wird als Objekt mit Vergleichs- oder Logikoperatoren übergeben und verändert die Auswahl der Datensätze.
• Syntax Injection:
  Eingaben werden in eine textuelle Abfragesprache, Regex oder Suchsyntax eingesetzt und brechen aus dem vorgesehenen Kontext aus.
• Serverseitiges JavaScript:
  Ältere oder bewusst aktivierte Datenbankfunktionen werten vom Angreifer beeinflusste Ausdrücke aus.
• Aggregation und Projektion:
  Manipulierte Pipelines oder Feldlisten legen zusätzliche Informationen offen oder führen teure Operationen aus.

Ein typischer Fehler in JSON-APIs

Eine API erwartet beispielsweise {"username":"anna"}, übernimmt den Request aber unverändert in das Query-Objekt. Sendet ein Client statt des Strings ein verschachteltes Objekt, kann der Datenbanktreiber dieses als Operator interpretieren. Ein Schema, das Typ, Länge und erlaubte Struktur erzwingt, verhindert diesen Wechsel von einem Datenwert zu einem Steuerungsobjekt. Eine reine Zeichenfilterung reicht bei strukturierten Requests nicht aus.

Auswirkungen und Erkennung

NoSQL Injection kann Authentisierungsabfragen umgehen, fremde Dokumente lesen, Suchfilter erweitern, Daten verändern oder durch aufwendige Regex- und Aggregationsabfragen einen Denial of Service auslösen. Tester variieren deshalb Datentypen, Verschachtelung und Operatoren, nicht nur Zeichen. Abweichende Treffermengen, Laufzeiten und Datenbankfehler sind Hinweise. Im Monitoring fallen ungewöhnlich breite Abfragen, teure Ausdrücke und viele Typkonvertierungsfehler auf.

Sichere Implementierung

Request-DTOs oder JSON-Schemas sollten unbekannte Felder ablehnen und skalare Werte tatsächlich als String, Zahl oder Boolean erzwingen. Die Anwendung baut aus validierten Werten selbst ein festes Query-Objekt und übernimmt niemals komplette Filter aus dem Request. Frei konfigurierbare Suchen benötigen Positivlisten für Felder und Operatoren sowie Begrenzungen für Tiefe, Ergebnismenge und Laufzeit. Minimale Datenbankrechte reduzieren den Schaden bei einem verbleibenden Fehler.