flawopen.com/Referência/Injeção NoSQL no MongoDB: quando a entrada muda a consulta

Injeção NoSQL no MongoDB: quando a entrada muda a consulta

MongoDB não executa SQL, portanto a concatenação de strings SQL não é o problema. Ainda pode haver NoSQL Injection quando a aplicação aceita um objeto aninhado não confiável onde esperava um valor escalar e o passa a um filtro MongoDB. É uma falha de validação de entrada na aplicação, não uma CVE do servidor MongoDB.

Limite de confiança: do JSON da requisição ao filtro MongoDB

Filtro de consulta

Documento BSON interpretado pelo MongoDB como comparações de campos e, quando presentes, operadores de consulta.

Injeção de operador

A aplicação recebe uma estrutura controlada pelo usuário onde deveria aceitar apenas um valor literal.

Validação de escalar

Verificar tipo, tamanho e formato permitido antes que a entrada influencie uma operação no banco.

Projeção

Lista de campos selecionada pelo servidor para limitar a exposição acidental de dados.

Como a falha acontece

Padrões vulnerável e endurecido em 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);
  }
});

O fluxo protegido rejeita campos que não sejam texto antes de acessar o banco, não aceita filtros enviados pelo cliente, monta em código da aplicação uma chave fixa para o filtro, retorna apenas os campos selecionados e verifica o hash da senha depois de localizar o usuário. O exemplo pressupõe que z seja Zod, users seja a coleção MongoDB e argon2 seja uma biblioteca configurada para hash de senhas; a criação da sessão fica fora do exemplo.

Verificações para validar a correção

• ✓Envie uma string normal e confirme que o handler consulta apenas o campo exato definido pela aplicação.
• ✓Envie objeto, array, número, booleano, null, campo ausente, string longa e propriedade desconhecida; confirme que o schema rejeita formatos inválidos antes de chamar o MongoDB.
• ✓Confirme que a chamada ao banco recebe um filtro criado pelo servidor, nunca um filtro do cliente ou fragmento JSON bruto.
• ✓Verifique que a projeção exclui hashes de senha e campos alheios, e que a função de banco tem apenas as permissões necessárias.
• ✓Armazene senhas com Argon2id ou bcrypt e valide o hash na aplicação; nunca consulte MongoDB usando a senha enviada como filtro.

Fontes primárias

• MongoDB — boas práticas para bibliotecas cliente: validar entrada antes de converter JSON em BSON
• OWASP — guia de segurança NoSQL
• MongoDB — criação de filtro de consulta (driver C#): a validação é responsabilidade da aplicação