NoSQL
Descriptionβ
A NoSQL injection vulnerability occurs when users can insert (or βinjectβ) malicious NoSQL code in a legit SQL query that is built from user-submitted input. A successful NoSQL injection exploit can read sensitive data from the database, modify database data, execute administration operations on the database (such as shutting down the DBMS), recover the content of a given file from the DBMS file system and in some cases issue commands to the operating system.
Remediationβ
Primary defenses:
- Use a sanitization library.
- Cast the inputs to the expected type (eg: The username and password are strings so cast the variables to a string).
- Never use
where
,mapReduce
, orgroup
operators with user input: they allow the attacker to inject JavaScript and are therefore much more dangerous than others. For extra safety, setjavascriptEnabled
to false in mongod.conf (if using mongoDB). - Enforce Least Privilege.
Configurationβ
CheckId:
injection/nosql
Optionsβ
- skip_objects : List of object that are to be skipped by the security test.
Examplesβ
Ignoring this checkβ
{
"checks": {
"injection/nosql": {
"skip": true
}
}
}
Check with all default optionsβ
{
"checks": {
"injection/nosql": {
"options": {
"skip_objects": []
}
}
}
}
Scoreβ
- Escape Severity: HIGH
- OWASP: A09:2023
- PCI DSS: 6.5.1
- CWE
- 89
- 564
- 943
- WASC: 19
CVSSβ
- CVSS_VECTOR: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:H/RL:O/RC:C
- CVSS_SCORE: 9.4