Avoiding mass assignment vulnerabilities in Node.js

SnykSec - Apr 24 '23 - - Dev Community

Avoiding mass assignment vulnerabilities in Node.js

This article will demonstrate a mass assignment vulnerability in a Node.js project, how an attacker can exploit it, and ways to protect a web application against it.

Originally published at https://snyk.io/blog/avoiding-mass-assignment-node-js

Mass assignment is a vulnerability that allows attackers to exploit predictable record patterns and invoke illegal actions. Mass assignment usually occurs when properties are not filtered when binding client-provided data-to-data models. Vulnerabilities of this type allow an attacker to create additional objects in POST request payloads, allowing them to modify properties that should be immutable.

Node.js is an open source server environment that can be used cross-platform for web application development. It enables developers to build powerful and scalable applications quickly. At its core, Node.js is a battle-tested and production-ready platform — application security challenges come with supply chain security associated with third-party packages installed to build applications. Creating a Node.js application can sometimes use thousands of open source npm packages from the npmjs registry, opening it up to many different attack vectors.

Mass assignment vulnerabilities are common in Node.js applications that send payloads in POST requests to the database. An attacker can use these vulnerabilities to orchestrate SQL injection attacks or other attacks directed at data contained in databases. An attacker can use a mass assignment vulnerability to take complete control of a system or steal sensitive data, making it essential to defend against this kind of attack.

This article will demonstrate a mass assignment vulnerability in a Node.js project, how an attacker can exploit it, and ways to protect a web application against it.

Removing mass assignment vulnerabilities from Node.js

This example uses Mongoose, an Object Data Modelling (ODM) library for Node.js and MongoDB. It coordinates objects in code and objects in MongoDB, validates schema, and helps manage data relationships.

Based on the information above, if you want to protect mass assignment from a Node.js MongoDB application, you must do it in Mongoose. Below is an example of exploiting mass assignment vulnerability in a Node.js application.

Prerequisites

To follow along with this project, you will need the following:

  • Node.js installed

  • Access to a MongoDB database and a valid connection string. This tutorial relies on a MongoDB Atlas cloud environment, but you can spin-off a local MongoDB server and update the connection string respectively.

Mass assignment in Node.js

To get started with this project, open your terminal and run this command:

1npm ini
Enter fullscreen mode Exit fullscreen mode

Next, you need to install the dependencies:

1npm i mongoose
2npm i express
Enter fullscreen mode Exit fullscreen mode

To handle the data in the form above, we need a newUser.js file under the models folder to handle the user schema.

1const mongoose = require('mongoose');
2
3const Schema = mongoose.Schema;
4
5const userSchema = new Schema({
6
7    first_name: String,
8    last_name: String,
9    email: String,
10    password: String,
11    isAdmin: {
12        type: Boolean,
13        protect: true,
14        default: false
15    }
16
17});
18
19const User = mongoose.model("User", userSchema);
20
21module.exports = User;
22
Enter fullscreen mode Exit fullscreen mode

This model captures all the fields in the registration form. The extra field isAdmin, of type Boolean defines a user’s role. If you set this field to true, you create a user with administrator privileges, and if you set it to false, you create a user without administrator privileges.

Create a new directory called routes and add the file routes.js to handle user details:

1    const express = require("express");
2    const userModel = require("../models/newUser");
3
4    const app = express();
5
6    app.post("/add_user", async (request, response) => {
7        const user = new userModel(request.body);
8
9        try {
10          await user.save();
11          response.send(user);
12        } catch (error) {
13          response.status(500).send(error);
14        }
15    });
16
17module.exports = app;
Enter fullscreen mode Exit fullscreen mode

The code above captures the data in the form, then structures it with the newUSer model.

This code has two flaws that introduce a mass assignment vulnerability. First, it uses a common name and type for a sensitive field — isAdmin. Second, the user model contains a sensitive, unused field. To exploit the vulnerability, let’s start a server.

Create a file named server.js in the project root folder and add the following code, replacing the with the value in your connection string:

1const express = require("express");
2const mongoose = require("mongoose");
3const Router = require("./routes/routes")
4
5const app = express();
6
7app.use(express.json());
8
9const username = "<USER>";
10const password = "<USER_PASSWORD>";
11const cluster = "<CLUSTER>";
12const dbname = "<DATABSE_NAME>";
13
14mongoose.connect(
15  `mongodb+srv://${username}:${password}@${cluster}.<APP_ID>.mongodb.net/${dbname}?retryWrites=true&w=majority`,
16  {
17    useNewUrlParser: true,
18    useUnifiedTopology: true
19  }
20);
21
22const db = mongoose.connection;
23db.on("error", console.error.bind(console, "connection error: "));
24db.once("open", function () {
25  console.log("Connected successfully");
26});
27
28app.use(Router);
29
30app.listen(3000, () => {
31  console.log("Server is running at port 3000");
32});
33
Enter fullscreen mode Exit fullscreen mode

Start the server by running node server.js.

A malicious actor can exploit this vulnerability by creating a curl POST request containing the isAdmin field with a value set to true, as shown in the code below:

1curl --location --request POST 'http://localhost:3000/add_user' \
2--header 'Content-Type: application/json' \
3--data-raw '{
4    "first_name": "Mike",
5    "last_name": "Jones",
6    "email": "mikejones@hmail.com",
7    "isAdmin":"true"
8}'
Enter fullscreen mode Exit fullscreen mode

The request above creates a user, Mike, with admin privileges. This user can now use their credentials to log in to the system and do anything an administrator can.

Defending against mass assignment

We can make three adjustments to increase the application’s defense against mass assignment attacks.

Create lean models

Lean models only include what a user is expected to add as inputs, and they exclude sensitive fields.

From the example above, the first and most essential step we can take is to remove the sensitive field from the newUser model, as shown below:

1const mongoose = require("mongoose");
2
3// create a schema
4var userSchema = new mongoose.Schema({
5   first_name: String,
6   last_name: String,
7   email: String,
8   password: String
9
10  //NB: there is no isAdmin field
11
12});
13
14const User = mongoose.model("User", userSchema);
15
16module.exports = User;
Enter fullscreen mode Exit fullscreen mode

Now, if attackers gain access to the source code, they won’t be able to view the sensitive field and use it to orchestrate an attack. You should also avoid using predictable terms in the database to define a user’s role — such as isAdmin, admin, and role — because an attacker may still be able to guess them and launch an attack.

Use an allow-list to specify acceptable input

Another way to protect your app is to specify and limit the fields a POST request can handle. This is known as allow-listing and uses the underscore library. First, install the library:

1npm install underscore
Enter fullscreen mode Exit fullscreen mode

Navigate to the routes folder and replace the route.js code with this:

1const express = require("express");
2const userModel = require("../models/newUser");
3var _ = require('underscore');
4
5const app = express();
6
7app.post("/add_user", async (request, response) => {
8    const user = new userModel( _.pick(request.body, 'first_name', 'last_name', 'email', 'password'));
9
10    try {
11      await user.save();
12      response.send(user);
13    } catch (error) {
14      response.status(500).send(error);
15    }
16});
17
18module.exports = app;
Enter fullscreen mode Exit fullscreen mode

In the code above, we use the pick function to specify the variables extracted from a POST request. This prevents an attacker from using the sensitive isAdmin field.

More mass assignment vulnerability examples in ORMs

Let’s look at three more examples of mass assignment vulnerabilities in common ORM solutions.

Mass assignment vulnerability in Sequelize code

Let’s look at an example of Sequelize code that’s vulnerable to mass assignment. This code defines a user model, creates a user, and saves user details to the database:

1const { Sequelize } = require("sequelize");
2
3const User = sequelize.define("users", {
4    username: {
5        type: DataTypes.STRING,
6        allowNull: false
7    },
8
9    email: {
10        type: DataTypes.STRING,
11        allowNull: false
12    },
13
14    password: {
15        type: DataTypes.STRING,
16        allowNull: false
17    },
18
19    is_verified: {
20        type: DataTypes.BOOLEAN,
21        allowNull: false,
22        default: false
23    },
24
25 });
Enter fullscreen mode Exit fullscreen mode

When creating a new user, the controller calls the model above, as shown below:

1// Create a User
2const user = {
3    username: req.body.username,
4    email: req.body.email,
5    password: req.body.password,
6    is_verified: false
7  };
8
9//Save User in the database
10User.create(user)
11.then(data => {
12    res.send(data);
13})
14.catch(err => {
15    res.status(500).send({
16    message:
17        err.message || "Error occurred. User not created!"
18    });
19});
Enter fullscreen mode Exit fullscreen mode

The code above is vulnerable because it exposes the sensitive field is_verified. An attacker can create a POST request with the is_verified field set as true, allowing them to bypass the verification step.

We can remove the mass assignment vulnerability in this code by removing the is_verified field when creating the user. The safe code would look like this:

1// Create a User
2const user = {
3    username: req.body.username,
4    email: req.body.email,
5    password: req.body.password
6  };
Enter fullscreen mode Exit fullscreen mode

This limits the acceptable POST request variables to username, email, and password.

Mass assignment vulnerability in Prisma code

Below is an example of a mass assignment vulnerable Prisma code that exposes the sensitive field Role.

1model User {
2    id             Int    @id @default(autoincrement())
3    username        String
4    email          String
5    Role           Boolean    @default(USER)
6  }
7
8enum Role {
9    USER
10    ADMIN
11}
Enter fullscreen mode Exit fullscreen mode

To add a user, we create a route add_user.

1const { PrismaClient } = require("@prisma/client");
2const express = require("express");
3const prisma = new PrismaClient();
4
5const app = express();
6
7app.use(express.json());
8
9app.post('/add_user', async (req, res) => {
10    const user = await prisma.user.create({ data: req.body });
11    res.json(user);
12  });
Enter fullscreen mode Exit fullscreen mode

This POST request will expect the body with a user object. The code above is vulnerable to mass assignment attacks because a hacker can add the field role to ADMIN to gain administrator privileges.

We can remove the vulnerability in the code above by excluding the sensitive field Role from the model.

1model User {
2    id             Int    @id @default(autoincrement())
3    username        String
4    email          String
5  }
Enter fullscreen mode Exit fullscreen mode

Mass assignment vulnerability in MySQL code

Here’s an example of mass assignment-vulnerable MySQL code that exposes the sensitive field isAdmin:

1// Defining the user data
2let user = {
3    username: req.body.username,
4    email: req.body.email,
5    password: req.body.password,
6    isAdmin: req.body.role
7};
Enter fullscreen mode Exit fullscreen mode

This code adds the user defined above:

1// Saving user details
2app.post('/add_user',(req, res) => {
3
4let myQuery = "INSERT INTO users SET ?";
5
6    let query = connection.query(myQuery, user,(err, results) => {
7        if(err) throw err;
8        res.send(apiResponse(results));
9    });
10
11});
Enter fullscreen mode Exit fullscreen mode

The code above has a mass assignment vulnerability because it exposes a sensitive field — isAdmin — and allows us to include it in a POST request. An attacker can create a POST request that sets the isAdmin field to be true, creating an admin user.

We can fix this vulnerability by excluding the sensitive field when creating the user object. Here’s the safe code:

1// Defining the user data
2let user = {
3    username: req.body.username,
4    email: req.body.email,
5    password: req.body.password
6};
Enter fullscreen mode Exit fullscreen mode

The default value of false for the isAdmin field can be set by altering the table using the following command:

1ALTER TABLE users ALTER isAdmin SET DEFAULT ‘false’;
Enter fullscreen mode Exit fullscreen mode




Keeping your code safe in Node.js

Node.js is secure, but sometimes the packages required to build a web application aren’t. For Node.js applications that send requests to a database, the mass assignment vulnerability is one of the most common attack vectors. It allows malicious users to perform SQL injection attacks, which involve sending malicious requests to a database.

However, sanitizing inputs can easily prevent mass assignment in Node.js. You can do this by not exposing sensitive fields, limiting acceptable fields, or blocking the editing of some fields.

Check out the complete source code example in our GitHub repository, and run your own local security experiments for how to avoid mass assignment vulnerability in Node.js.

Follow Snyk’s Top 10 Node.js Security Best Practices to optimize the security of your Node.js application.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .