A1 - Injection

Exploitability: EASY Prevalence: COMMON Detectability: AVERAGE Technical Impact: SEVERE


Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.


When eval(), setTimeout(), setInterval(), Function()are used to process user provided inputs, it can be exploited by an attacker to inject and execute malicious JavaScript code on server.

Attack Mechanics

Web applications using the JavaScript eval()function to parse the incoming data without any type of input validation are vulnerable to this attack. An attacker can inject arbitrary JavaScript code to be executed on the server. Similarly setTimeout(), and setInterval()functions can take code in string format as a first argument causing same issues as eval().

This vulnerability can be very critical and damaging by allowing attacker to send various types of commands.

Denial of Service Attack:

An effective denial-of-service attack can be executed simply by sending the commands below to eval()function:


This input will cause the target server's event loop to use 100% of its processor time and unable to process any other incoming requests until process is restarted.

An alternative DoS attack would be to simply exit or kill the running process:


File System Access

Another potential goal of an attacker might be to read the contents of files from the server. For example, following two commands list the contents of the current directory and parent directory respectively:


Once file names are obtained, an attacker can issue the command below to view the actual contents of a file:


An attacker can further exploit this vulnerability by writing and executing harmful binary files using fsand child_processmodules.

How Do I Prevent It?

To prevent server-side js injection attacks:
  • Validate user inputs on server side before processing
  • Do not use eval()function to parse user inputs. Avoid using other commands with similar effect, such as setTimeOut(), setInterval(), and Function().
  • For parsing JSON input, instead of using eval(), use a safer alternative such as JSON.parse(). For type conversions use type related parseXXX()methods.
  • Include "use strict"at the beginning of a function, which enables strict mode within the enclosing function scope.

Source Code Example

In routes/contributions.js, the handleContributionsUpdate()function insecurely uses eval()to covert user supplied contribution amounts to integer.

        // Insecure use of eval() to parse inputs
        var preTax = eval(req.body.preTax);
        var afterTax = eval(req.body.afterTax);
        var roth = eval(req.body.roth);
This makes application vulnerable to SSJS attack. It can fixed simply by using parseInt()instead.
        //Fix for A1 -1 SSJS Injection attacks - uses alternate method to eval
        var preTax = parseInt(req.body.preTax);
        var afterTax = parseInt(req.body.afterTax);
        var roth = parseInt(req.body.roth);

In addition, all functions begin with use strictpragma.

Further Reading


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.

Attack Mechanics

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.

SSJS Attack Mechanics

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.

2. NoSQL SSJS Injection

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


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


How Do I Prevent It?

Here are some measures to prevent SQL / NoSQL injection attacks, or minimize impact if it happens:
  • 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.
For the above NoSQL vulnerability, bare minimum fixes can be found in allocations.html and allocations-dao.js