feat: Add NoSQL injection vulnerability guide#168
feat: Add NoSQL injection vulnerability guide#168bearsyankees merged 2 commits intousestrix:mainfrom
Conversation
This file provides a comprehensive guide on NoSQL injection vulnerabilities, detailing methodologies, injection surfaces, detection channels, and prevention strategies across various NoSQL databases.
Greptile SummaryThis PR adds Confidence Score: 5/5Safe to merge — new prompt-only file with no runtime logic changes and no registration required. All findings are P2 (style/documentation suggestions). The file is self-contained, auto-discovered, and has no impact on existing functionality. No files require special attention. Important Files Changed
Prompt To Fix All With AIThis is a comment left during a code review.
Path: strix/prompts/vulnerabilities/nosql_injection.jinja
Line: 92-97
Comment:
**Nested sub-tags in `detection_channels` diverge from sibling guides**
`<detection_channels>` wraps four sub-elements (`<operator_based>`, `<boolean_based>`, `<timing_based>`, `<error_based>`), while every other guide in this directory (e.g. `sql_injection.jinja`) keeps `detection_channels` as a flat bullet list. The inconsistency is harmless at runtime — modules are loaded as raw text — but makes the template harder to maintain and visually scan alongside peers. Consider flattening the section to match the established pattern.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: strix/prompts/vulnerabilities/nosql_injection.jinja
Line: 152-153
Comment:
**`$where` JavaScript is disabled by default in modern MongoDB**
The guide presents `$where` payloads as a primary extraction path without mentioning that server-side JavaScript is **disabled by default since MongoDB 3.6+** (via `--noscripting`). Pro tip #5 does mention checking if SSJS is enabled, but given that the `javascript_injection` and `data_extraction` sections both lean heavily on `$where` first, a brief "requires SSJS to be enabled (off by default in modern deployments)" caveat near the `<where_clause>` section would prevent wasted tester effort on the most common MongoDB configurations.
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "feat: Add NoSQL injection vulnerability ..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| - Label/relationship injection to access unauthorized graph nodes | ||
| </neo4j> | ||
| </dbms_primitives> | ||
|
|
||
| <authentication_bypass> | ||
| <mongodb_operators> |
There was a problem hiding this comment.
detection_channels diverge from sibling guides
<detection_channels> wraps four sub-elements (<operator_based>, <boolean_based>, <timing_based>, <error_based>), while every other guide in this directory (e.g. sql_injection.jinja) keeps detection_channels as a flat bullet list. The inconsistency is harmless at runtime — modules are loaded as raw text — but makes the template harder to maintain and visually scan alongside peers. Consider flattening the section to match the established pattern.
Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/prompts/vulnerabilities/nosql_injection.jinja
Line: 92-97
Comment:
**Nested sub-tags in `detection_channels` diverge from sibling guides**
`<detection_channels>` wraps four sub-elements (`<operator_based>`, `<boolean_based>`, `<timing_based>`, `<error_based>`), while every other guide in this directory (e.g. `sql_injection.jinja`) keeps `detection_channels` as a flat bullet list. The inconsistency is harmless at runtime — modules are loaded as raw text — but makes the template harder to maintain and visually scan alongside peers. Consider flattening the section to match the established pattern.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
|
|
||
| <mapreduce> |
There was a problem hiding this comment.
$where JavaScript is disabled by default in modern MongoDB
The guide presents $where payloads as a primary extraction path without mentioning that server-side JavaScript is disabled by default since MongoDB 3.6+ (via --noscripting). Pro tip #5 does mention checking if SSJS is enabled, but given that the javascript_injection and data_extraction sections both lean heavily on $where first, a brief "requires SSJS to be enabled (off by default in modern deployments)" caveat near the <where_clause> section would prevent wasted tester effort on the most common MongoDB configurations.
Prompt To Fix With AI
This is a comment left during a code review.
Path: strix/prompts/vulnerabilities/nosql_injection.jinja
Line: 152-153
Comment:
**`$where` JavaScript is disabled by default in modern MongoDB**
The guide presents `$where` payloads as a primary extraction path without mentioning that server-side JavaScript is **disabled by default since MongoDB 3.6+** (via `--noscripting`). Pro tip #5 does mention checking if SSJS is enabled, but given that the `javascript_injection` and `data_extraction` sections both lean heavily on `$where` first, a brief "requires SSJS to be enabled (off by default in modern deployments)" caveat near the `<where_clause>` section would prevent wasted tester effort on the most common MongoDB configurations.
How can I resolve this? If you propose a fix, please make it concise.
|
merging, thanks @timlzh! |
2 participants
Adds a detailed NoSQL injection detection guide following the existing template structure.
Changes
✅ Added
nosql_injection.jinja- NoSQL Operator injection, JavaScript execution, ODM exploitation, blind extraction techniquesTesting
Guide follows the established format and includes:
Examples
MongoDB Operator Injection
Authentication bypass:
{"username": {"$ne": ""}, "password": {"$ne": ""}}Regex extraction:
{"password": {"$regex": "^a.*"}}for character-by-character enumerationQuery string notation:
?username=admin&password[$ne]=wrongpassJavaScript Execution
$where clause:
{"$where": "sleep(5000)"}for timing-based detection$functionoperator (MongoDB 4.4+): Server-side JS in aggregation pipelinesObject.keys()enumeration for field discoveryBlind Extraction
Binary search via regex ranges:
^[a-m]vs^[n-z]Timing oracle: conditional sleep in
$whereclausesReDoS patterns:
{"$regex": "^(a+)+$"}for pathological backtrackingWAF Bypasses
URL encoding:
%24neinstead of$neJSON unicode escapes:
\u0024neOperator alternatives:
$notinstead of$ne,$ninfor negationFramework-Specific Issues
Mongoose:
find(req.body)without sanitizationPyMongo: Unsanitized dictionaries from JSON input
GraphQL + MongoDB: Operator injection via variables