flawopen.com/Referencia/Inyección NoSQL en MongoDB: cuando la entrada cambia la consulta

Inyección NoSQL en MongoDB: cuando la entrada cambia la consulta

MongoDB no ejecuta SQL, así que concatenar cadenas SQL no es el problema. Puede existir NoSQL Injection si la aplicación acepta un objeto anidado no confiable donde esperaba un valor escalar y lo pasa a un filtro MongoDB. Es un fallo de validación de entrada de la aplicación, no una CVE del servidor MongoDB.

Límite de confianza: del JSON de la solicitud al filtro MongoDB

Filtro de consulta

Documento BSON que MongoDB interpreta como comparaciones de campos y, si están presentes, operadores de consulta.

Inyección de operadores

La aplicación recibe una estructura controlada por el usuario donde esperaba un único valor literal.

Validación de escalares

Comprobar tipo, longitud y formato permitido antes de que la entrada influya en una operación de base de datos.

Proyección

Lista de campos elegida por el servidor para limitar la exposición accidental de datos.

Cómo ocurre el fallo

Patrones vulnerables y reforzados en Node.js

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);
  }
});

El flujo reforzado rechaza los campos que no sean cadenas antes de acceder a la base de datos, no acepta filtros enviados por el cliente, construye en el código de la aplicación una clave fija para el filtro, devuelve solo los campos seleccionados y verifica el hash de la contraseña después de buscar al usuario. El ejemplo supone que z es Zod, users es la colección de MongoDB y argon2 es una biblioteca configurada para el hash de contraseñas; la creación de la sesión queda fuera del ejemplo.

Comprobaciones para verificar la corrección

• ✓Envía una cadena normal y confirma que el controlador consulta solo el campo exacto definido por la aplicación.
• ✓Envía un objeto, matriz, número, booleano, null, campo ausente, cadena demasiado larga y propiedad desconocida; verifica que el esquema rechaza formas inválidas antes de llamar a MongoDB.
• ✓Comprueba que la llamada a la base de datos recibe un filtro construido por el servidor, nunca un filtro del cliente ni un fragmento JSON sin procesar.
• ✓Verifica que la proyección excluye hashes de contraseñas y campos ajenos, y que el rol de base de datos tiene solo los permisos necesarios.
• ✓Almacena contraseñas con Argon2id o bcrypt y verifica el hash en la aplicación; nunca consultes MongoDB usando la contraseña enviada como filtro.

Fuentes primarias

• MongoDB — buenas prácticas de bibliotecas cliente: validar entradas antes de convertir JSON a BSON
• OWASP — guía de seguridad NoSQL
• MongoDB — crear un filtro de consulta (driver de C#): la validación es responsabilidad de la aplicación