Cómo evitar las vulnerabilidades de asignación masiva en Node.js

La asignación masiva es una vulnerabilidad que permite a los atacantes aprovechar patrones de registros predecibles y ejecutar acciones no autorizadas. Suele ocurrir cuando no se filtran las propiedades al vincular datos proporcionados por el cliente con modelos de datos. Las vulnerabilidades de este tipo permiten que un atacante agregue objetos adicionales a las cargas útiles de las solicitudes POST y modifique propiedades que deberían ser inmutables.

Node.js es un entorno de servidor de código abierto que se puede usar en distintas plataformas para desarrollar aplicaciones web. Permite a los desarrolladores crear aplicaciones potentes y escalables con rapidez. En esencia, Node.js es una plataforma probada en batalla y lista para producción; los desafíos de seguridad de las aplicaciones incluyen la seguridad de la cadena de suministro asociada con los paquetes de terceros que se instalan para crearlas. A veces, crear una aplicación de Node.js implica usar miles de paquetes npm de código abierto del registro de npm, lo que la expone a diversos vectores de ataque.

Las vulnerabilidades de asignación masiva son comunes en las aplicaciones de Node.js que envían cargas útiles a la base de datos en solicitudes POST. Un atacante puede aprovechar estas vulnerabilidades para orquestar ataques de inyección SQL u otros ataques dirigidos a los datos almacenados en las bases de datos. También puede aprovechar una vulnerabilidad de asignación masiva para tomar el control total de un sistema o robar datos confidenciales, por lo que es fundamental defenderse de este tipo de ataque.

En este artículo se muestra una vulnerabilidad de asignación masiva en un proyecto de Node.js, cómo puede explotarla un atacante y cómo proteger una aplicación web.

Cómo eliminar las vulnerabilidades de asignación masiva en Node.js

En este ejemplo se usa Mongoose, una biblioteca de modelado de datos de objetos (ODM) para Node.js y MongoDB. Coordina los objetos del código con los objetos de MongoDB, valida esquemas y ayuda a administrar las relaciones entre los datos.

Con base en la información anterior, si quieres proteger una aplicación de Node.js con MongoDB contra la asignación masiva, debes hacerlo en Mongoose. A continuación, se muestra un ejemplo de cómo explotar una vulnerabilidad de asignación masiva en una aplicación de Node.js.

Requisitos previos

Para seguir este proyecto, necesitarás lo siguiente:

• Tener Node.js instalado

• Acceso a una base de datos MongoDB y una cadena de conexión válida. Este tutorial usa un entorno en la nube de MongoDB Atlas, pero puedes iniciar un servidor local de MongoDB y actualizar la cadena de conexión según corresponda.

Asignación masiva en Node.js

Para empezar con este proyecto, abre la terminal y ejecuta este comando:

1npm init

A continuación, instala las dependencias:

1npm i mongoose
2npm i express

Para procesar los datos del formulario anterior, necesitamos un archivo newUser.js en la carpeta models para gestionar el esquema del usuario.

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

Este modelo incluye todos los campos del formulario de registro. El campo adicional isAdmin, de tipo Boolean, define el rol del usuario. Si estableces este campo en true, crearás un usuario con privilegios de administrador; si lo estableces en false, crearás un usuario sin esos privilegios.

Crea un directorio llamado routes y agrega el archivo routes.js para gestionar los datos del usuario:

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;

El código anterior captura los datos del formulario y luego los estructura con el modelo newUSer.

Este código tiene dos fallas que introducen una vulnerabilidad de asignación masiva. Primero, usa un nombre y un tipo comunes para un campo confidencial: isAdmin. Segundo, el modelo del usuario contiene un campo confidencial que no se usa. Para explotar la vulnerabilidad, iniciemos un servidor.

Crea un archivo llamado server.js en la carpeta raíz del proyecto y agrega el siguiente código. Reemplaza <APP_ID> por el valor de tu cadena de conexión:

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

Inicia el servidor con node server.js.

Un actor malicioso puede explotar esta vulnerabilidad creando una solicitud curl POST que incluya el campo isAdmin con el valor true, como se muestra en el código a continuación:

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}'

La solicitud anterior crea un usuario, Mike, con privilegios de administrador. Este usuario ahora puede usar sus credenciales para iniciar sesión en el sistema y hacer todo lo que puede hacer un administrador.

Cómo defenderte contra la asignación masiva

Podemos hacer tres ajustes para reforzar la protección de la aplicación contra los ataques de asignación masiva.

Crea modelos reducidos

Los modelos reducidos solo incluyen los datos que se espera que el usuario ingrese y excluyen los campos confidenciales.

A partir del ejemplo anterior, el primer paso y el más importante es eliminar el campo confidencial del modelo newUser, como se muestra a continuación:

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;

Ahora, si los atacantes obtienen acceso al código fuente, no podrán ver el campo confidencial ni usarlo para orquestar un ataque. También debes evitar usar términos predecibles en la base de datos para definir el rol de un usuario, como isAdmin, admin y role, porque un atacante aún podría adivinarlos y lanzar un ataque.

Valida el esquema de los datos de entrada del usuario

Validación con underscore

Otra forma de proteger tu aplicación es especificar y limitar los campos que puede procesar una solicitud POST. Esto se conoce como lista de permitidos y utiliza la biblioteca underscore. Primero, instala la biblioteca:

1npm install underscore

Ve a la carpeta routes y reemplaza el código de route.js por este:

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;

En el código anterior, usamos la función pick para especificar las variables que se extraen de una solicitud POST. Esto evita que un atacante use el campo confidencial isAdmin.

El problema de usar underscore es que la aplicación debe procesar los datos para determinar si son válidos. En otras palabras, no detecta los errores con suficiente anticipación.

Validación con Zod

Para validar esquemas de forma sólida, debes usar Zod. Esta herramienta valida el esquema y garantiza que los datos cumplan estrictamente con la estructura, el patrón y el tipo de datos especificados. Zod detecta los datos incompletos o incorrectos con suficiente anticipación para evitar errores en la aplicación. Además, puedes crear fácilmente un mensaje de error que indique al usuario qué datos de entrada causaron el error y de qué tipo es.

Este fragmento de código muestra cómo funciona Zod. Ten en cuenta que está escrito en TypeScript, por lo que requiere configuración adicional.

1import { z, AnyZodObject } from "zod";
2import express, { Request, Response, NextFunction } from 'express';
3
4const app = express();
5
6app.use(express.json());
7
8const dataSchema = z.object({
9    body: z.object({
10        first_name: z.string({
11            required_error: "First name is required",
12            invalid_type_error: "First name must be a string",
13        }),
14        last_name: z.string({
15            required_error: "Last name is required",
16            invalid_type_error: "Last name must be a string",
17        }),
18        password: z.string({
19            required_error: "Password is required",
20        }),
21        email: z
22            .string({
23                required_error: "Email is required",
24            })
25            .email("Not a valid email"),
26    }),
27});
28
29const validate =
30    (schema: AnyZodObject) =>
31    async (req: Request, res: Response, next: NextFunction) => {
32        try {
33            await schema.parseAsync({
34                body: req.body,
35                query: req.query,
36                params: req.params,
37            });
38            return next();
39        } catch (error) {
40            return res.status(400).json(error);
41        }
42    };
43
44app.post("/create",
45    validate(dataSchema),
46    (req: Request, res: Response): Response => {
47        return res.json({
48            ...req.body
49        });
50    }
51);

Si un usuario intenta ingresar datos que no coinciden con el esquema, recibirá un error que indica que se produjo un invalid_type_error. Si deja un campo vacío, recibirá un required_error.

Más ejemplos de vulnerabilidades de asignación masiva en ORM

Veamos otros tres ejemplos de vulnerabilidades de asignación masiva en soluciones ORM comunes.

Vulnerabilidad de asignación masiva en código de Sequelize

Veamos un ejemplo de código de Sequelize vulnerable a la asignación masiva. Este código define un modelo de usuario, crea un usuario y guarda sus datos en la base de datos:

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 });

Al crear un usuario nuevo, el controlador llama al modelo anterior, como se muestra a continuación:

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});

El código anterior es vulnerable porque expone el campo confidencial is_verified. Un atacante puede crear una solicitud POST con el campo is_verified establecido en true y así omitir el paso de verificación.

Podemos eliminar la vulnerabilidad de asignación masiva de este código si quitamos el campo is_verified al crear el usuario. El código seguro se vería así:

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

Esto limita las variables aceptadas en la solicitud POST a username, email y password.

Vulnerabilidad de asignación masiva en código de Prisma

A continuación, se muestra un ejemplo de código de Prisma vulnerable a la asignación masiva que expone el campo confidencial 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}

Para agregar un usuario, creamos la ruta 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  });

Esta solicitud POST espera que el cuerpo incluya un objeto de usuario. El código anterior es vulnerable a los ataques de asignación masiva porque un hacker puede agregar el campo role con el valor ADMIN para obtener privilegios de administrador.

Podemos eliminar la vulnerabilidad del código anterior si excluimos el campo confidencial Role del modelo.

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

Vulnerabilidad de asignación masiva en código de MySQL

Este es un ejemplo de código de MySQL vulnerable a la asignación masiva que expone el campo confidencial 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};

Este código agrega el usuario definido anteriormente:

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});

El código anterior tiene una vulnerabilidad de asignación masiva porque expone un campo confidencial, isAdmin, y permite incluirlo en una solicitud POST. Un atacante puede crear una solicitud POST que establezca el campo isAdmin en true y crear así un usuario administrador.

Podemos corregir esta vulnerabilidad si excluimos el campo confidencial al crear el objeto user. Este es el código seguro:

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

El valor predeterminado false del campo isAdmin se puede establecer modificando la tabla con el siguiente comando:

1ALTER TABLE users ALTER isAdmin SET DEFAULT ‘false’;

Cómo mantener seguro tu código en Node.js

Node.js es seguro, pero a veces los paquetes necesarios para crear una aplicación web no lo son. En las aplicaciones de Node.js que envían solicitudes a una base de datos, la vulnerabilidad de asignación masiva es uno de los vectores de ataque más comunes. Permite que usuarios maliciosos realicen ataques de inyección SQL, que consisten en enviar solicitudes maliciosas a una base de datos.

Sin embargo, puedes prevenir fácilmente la asignación masiva en Node.js depurando los datos de entrada. Para hacerlo, evita exponer campos confidenciales, limita los campos aceptados o impide que se editen ciertos campos.

Si no implementas una validación sólida de los datos de entrada del usuario, expones el sistema a ataques como la contaminación de prototipos. Estos ataques pueden eludir mecanismos de validación débiles, como underscore. Por eso, asegúrate de usar siempre soluciones sólidas como Zod.

Consulta el ejemplo completo de código fuente en nuestro repositorio de GitHub y realiza tus propios experimentos de seguridad locales para aprender cómo evitar las vulnerabilidades de asignación masiva en Node.js.

Sigue las 10 mejores prácticas de seguridad de Snyk para Node.js para optimizar la seguridad de tu aplicación de Node.js.