bug: fix NoSQL operator injection in admin loginHandler

[devin-ai-integration]

Summary

POST /login passed req.body.username/req.body.password straight into User.find({...}), so a JSON body like {"username":"admin@snyk.io","password":{"$gt":""}} (or {"$gt":""} for both) turned the credential check into an operator query and granted an admin session (CWE-943).

loginHandler now rejects anything that is not a primitive string before touching the DB, and compares with explicit $eq so a nested object can never be interpreted as an operator:

if (typeof username !== 'string' || typeof password !== 'string' || !validator.isEmail(username)) return res.status(401).send()
User.find({ username: { $eq: username }, password: { $eq: password } }, ...)

err from the query is now propagated to next instead of being ignored (it previously caused a users.length TypeError).

tests/login-nosql-injection.spec.js stubs the mongoose model with an in-memory collection implementing $eq/$gt/$ne semantics (mongoose 4.2.4 can't talk to a modern mongod) and asserts operator payloads and object usernames get 401 with no session, while valid credentials still redirect to /admin. README and exploits/nosql-exploits.sh updated to reflect that the ns4/ns5 payloads now fail.

Written by Devin

Devin-Org: engineering

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review