A1 - Injection

SQL and NoSQL injections enable an attacker to inject code into the query that would be executed by the database. These flaws are introduced when software developers create dynamic database queries that include user supplied input.

Both SQL and NoSQL databases are vulnerable to injection attack. Here is an example of equivalent attack in both cases, where attacker manages to retrieve admin user's record without knowing password:

1. SQL Injection

Lets consider an example SQL statement used to authenticate the user with username and password

SELECT * FROM accounts WHERE username = '$username' AND password = '$password'

If this statement is not prepared or properly handled when constructed, an attacker may be able to supply admin' --in the username field to access the admin user's account bypassing the condition that checks for the password. The resultant SQL query would looks like:

SELECT * FROM accounts WHERE username = 'admin' -- AND password = ''

2. NoSQL Injection

The equivalent of above query for NoSQL MongoDB database is:

db.accounts.find({username: username, password: password});

While here we are no longer dealing with query language, an attacker can still achieve the same results as SQL injection by supplying JSON input object as below:

{
    "username": "admin",
    "password": {$gt: ""}
}
                        

In MongoDB, $gtselects those documents where the value of the field is greater than (i.e. >) the specified value. Thus above statement compares password in database with empty string for greatness, which returns true.

The same results can be achieved using other comparison operator such as $ne.

Server-side JavaScript Injection (SSJS) is an attack where JavaScript code is injected and executed in a server component. MongoDB specifically, is vulnerable to this attack when queries are run without proper sanitization.

$where operator

MongoDB's $where operator performs JavaScript expression evaluation on the MongoDB server. If the user is able to inject direct code into such queries then such an attack can take place

Lets consider an example query:

 db.allocationsCollection.find({ $where: "this.userId == '" + parsedUserId + "' && " + "this.stocks > " + "'" + threshold + "'" }); 

The code will match all documents which have a userId field as specified by parsedUserId and a stocks field as specified by threshold. The problem is that these parameters are not validated, filtered, or sanitised, and vulnerable to SSJS Injection.

• Prepared Statements: For SQL calls, use prepared statements instead of building dynamic queries using string concatenation.
• Input Validation: Validate inputs to detect malicious values. For NoSQL databases, also validate input types against expected types
• Least Privilege: To minimize the potential damage of a successful injection attack, do not assign DBA or admin type access rights to your application accounts. Similarly minimize the privileges of the operating system account that the database process runs under.

Note: These vulnerabilities are not present when using an Atlas M0 cluster with NodeGoat.

The Allocations page of the demo application is vulnerable to NoSQL Injection. For example, set the stocks threshold filter to:

1'; return 1 == '1

This will retrieve allocations for all the users in the database.

An attacker could also send the following input for the threshold field in the request's query, which will create a valid JavaScript expression and satisfy the $where query as well, resulting in a DoS attack on the MongoDB server:

http://localhost:4000/allocations/2?threshold=5';while(true){};' 

You can also just drop the following into the Stocks Threshold input box:

';while(true){};'

For these vulnerabilities, bare minimum fixes can be found in allocations.html and allocations-dao.js

Log injection vulnerabilities enable an attacker to forge and tamper with an application's logs.

An attacker may craft a malicious request that may deliberately fail, which the application will log, and when attacker's user input is unsanitized, the payload is sent as-is to the logging facility. Vulnerabilities may vary depending on the logging facility:

1. Log Forging (CRLF)

Lets consider an example where an application logs a failed attempt to login to the system. A very common example for this is as follows:

var userName = req.body.userName;
console.log('Error: attempt to login with invalid user: ', userName);
                        

When user input is unsanitized and the output mechanism is an ordinary terminal stdout facility then the application will be vulnerable to CRLF injection, where an attacker can create a malicious payload as follows:

curl http://localhost:4000/login -X POST --data 'userName=vyva%0aError: alex moldovan failed $1,000,000 transaction&password=Admin_123&_csrf='
                        

Error: attempt to login with invalid user:  vyva
Error: alex moldovan failed $1,000,000 transaction
                        

2. Log Injection Escalation

An attacker may craft malicious input in hope of an escalated attack where the target isn't the logs themselves, but rather the actual logging system. For example, if an application has a back-office web app that manages viewing and tracking the logs, then an attacker may send an XSS payload into the log, which may not result in log forging on the log itself, but when viewed by a system administrator on the log viewing web app then it may compromise it and result in XSS injection that if the logs app is vulnerable.

• Do not allow user input into logs
• Encode to proper context, or sanitize user input

// Step 1: Require a module that supports encoding
var ESAPI = require('node-esapi');
// - Step 2: Encode the user input that will be logged in the correct context
// following are a few examples:
console.log('Error: attempt to login with invalid user: %s', ESAPI.encoder().encodeForHTML(userName));
console.log('Error: attempt to login with invalid user: %s', ESAPI.encoder().encodeForJavaScript(userName));
console.log('Error: attempt to login with invalid user: %s', ESAPI.encoder().encodeForURL(userName));
                        

For the above Log Injection vulnerability, example and fix can be found at routes/session.js