Server-Side JavaScript Injection

---

Theory

One type of injection unique to NoSQL is JavaScript Injection. This is when an attacker can get the server to execute arbitrary JavaScript in the context of the database. JavaScript injection may, of course, be in-band, blind, or out-of-band, depending on the scenario. A quick example of this would be a server that used the $where query to check username/password combinations:

...
.find({$where: "this.username == \"" + req.body['username'] + "\" && this.password == \"" + req.body['password'] + "\""});
...

In this case, user input is used in the JavaScript query evaluated by $where, leading to JavaScript injection. An attacker could do many things here. For example, to bypass authentication, they could pass " || ""==" as the username and password so that the server would evaluate db.users.find({$where: 'this.username == "" || ""=="" && this.password == "" || ""==""'}) which results in every document being returned and presumably logging the attacker in as one of the returned users.

---

MangoOnline

In this section, we will be looking at the fourth web application - MangoOnline. This application is vulnerable to Server-Side JavaScript Injection.

The site itself is just a login form with nothing else to look at.

Authentication Bypass

We can fill out the form with arbitrary data and intercept the login request to take a better look. The request looks similar to the one for MangoMail from the authentication bypass section.

If we try the same authentication bypass methods as before, however, we will, unfortunately, realize none of them work. At this point, we might want to check if some SSJI payloads work in case the server is running a $where query, which might look like this:

db.users.find({
    $where: 'this.username === "<username>" && this.password === "<password>"'
});

For this example, we could set username to " || true || ""==", which should result in the query statement always returning True, regardless of what this.username and this.password are.

db.users.find({
    $where: 'this.username === "" || true || ""=="" && this.password === "<password>"'
});

Since this is just JavaScript that is being evaluated, we can verify that the statement should always return true by using the developer console in our browser:

As expected, the statement returns True, even with this.username and this.password being undefined. With this confirmation, we can try to log in with this "username" and an arbitrary password, taking care to URL-encode the necessary characters.

This should result in us being able to bypass authentication altogether since the $where query returned True on all documents.

Note that the real username of whoever we logged in (whichever document we matched) is not displayed. Rather the SSJI payload we used is.

Blind Data Extraction

So we proved that we can bypass authentication with Server-Side Javascript Injection, and we have established that the username of the user we logged in as is not given to us, so let's work on extracting that information!

The steps to do this are essentially the same as the steps from the Blind Data Extraction and Automating Blind Data Extraction sections, simply with different syntax.

As a first request, we can use the payload: " || (this.username.match('^.*')) || ""==" to verify that there is a username which matches ^.*. This is expected to return true (log us in), so it's more of a sanity check.

Next, we can start guessing what the first character of the username is with payloads like: " || (this.username.match('^a.*')) || ""==". If no such username exists, as is the case with ^a.*, then the application will fail to log in.

After a bit of trying, the payload: " || (this.username.match('^H.*')) || ""==" logs us in, meaning there is a username that matches ^H.*.

By continuing these steps, we can dump the entire username.