flawopen.com/Referenz/MongoDB NoSQL Injection: wenn Eingaben Abfragen verändern

MongoDB NoSQL Injection: wenn Eingaben Abfragen verändern

MongoDB führt kein SQL aus; SQL-String-Verkettung ist daher nicht das Problem. Eine NoSQL-Injection kann trotzdem entstehen, wenn eine Anwendung ein nicht vertrauenswürdiges verschachteltes Objekt erwartet, obwohl sie einen Skalar erwartet, und dieses an einen MongoDB-Filter weitergibt. Das ist ein Eingabevalidierungsfehler der Anwendung, keine MongoDB-Server-CVE.

Vertrauensgrenze: vom Request-JSON zum MongoDB-Filter

Abfragefilter

BSON-Dokument, das MongoDB als Feldvergleiche und gegebenenfalls ausdrücklich enthaltene Abfrageoperatoren interpretiert.

Operator-Injection

Die Anwendung übernimmt eine vom Benutzer kontrollierte Struktur an einer Stelle, an der ein einzelner Literalwert erwartet wird.

Skalarvalidierung

Typ, Länge und zulässiges Format prüfen, bevor die Eingabe einen Datenbankvorgang beeinflussen kann.

Projektion

Serverseitig ausgewählte Feldliste, die versehentliche Datenoffenlegung begrenzt.

So entsteht der Fehler

Unsichere und gehärtete Node.js-Muster

app.post("/users/lookup", async (req, res, next) => {
  try {
    // The route expects a string, but req.body.username is untrusted JSON.
    const user = await users.findOne({ username: req.body.username });
    res.json(user ? { username: user.username } : null);
  } catch (error) {
    next(error);
  }
});

const loginSchema = z.object({
  username: z.string().trim().min(1).max(128),
  password: z.string().min(1).max(1024)
}).strict();

app.post("/login", async (req, res, next) => {
  try {
    const parsed = loginSchema.safeParse(req.body);
    if (!parsed.success) return res.sendStatus(400);

    const { username, password } = parsed.data;
    // The application owns the filter key; input supplies only a string value.
    const user = await users.findOne(
      { username },
      { projection: { _id: 1, username: 1, passwordHash: 1 } }
    );
    const passwordMatches = user &&
      await argon2.verify(user.passwordHash, password);
    if (!passwordMatches) return res.sendStatus(401);

    return res.sendStatus(204); // Session creation is application-specific.
  } catch (error) {
    next(error);
  }
});

Der gehärtete Ablauf weist Felder zurück, die keine Zeichenketten sind, bevor auf die Datenbank zugegriffen wird. Er akzeptiert keine vom Client gelieferten Filterobjekte, erstellt den festen Filterschlüssel im Anwendungscode, gibt nur ausgewählte Felder zurück und prüft nach dem Abruf des Benutzers den Passwort-Hash. Im Beispiel steht z für Zod, users für die MongoDB-Collection und argon2 für eine konfigurierte Passwort-Hashing-Bibliothek; die Sitzungserstellung ist bewusst nicht enthalten.

Prüfungen für die Korrektur

• ✓Senden Sie einen normalen String und prüfen Sie, dass der Handler nur das exakt von der Anwendung festgelegte Feld abfragt.
• ✓Senden Sie Objekt, Array, Zahl, Boolean, null, fehlendes Feld, überlangen String und unbekannte Eigenschaft; das Schema muss ungültige Formen vor dem MongoDB-Aufruf ablehnen.
• ✓Prüfen Sie, dass der Datenbankaufruf einen serverseitig erstellten Filter erhält, niemals einen Clientfilter oder rohen JSON-Ausschnitt.
• ✓Prüfen Sie, dass die Projektion Passwort-Hashes und fremde Felder ausschließt und die Datenbankrolle nur erforderliche Rechte besitzt.
• ✓Speichern Sie Passwörter mit Argon2id oder bcrypt und prüfen Sie Hashes in der Anwendung; fragen Sie MongoDB nie mit dem übermittelten Passwort als Filter ab.

Primärquellen

• MongoDB — Best Practices für Clientbibliotheken: Eingaben vor der JSON-zu-BSON-Konvertierung prüfen
• OWASP — NoSQL-Sicherheitsleitfaden
• MongoDB — Abfragefilter erstellen (C#-Treiber): Validierung liegt in der Verantwortung der Anwendung