Como evitar vulnerabilidades de atribuição em massa no Node.js

A atribuição em massa é uma vulnerabilidade que permite aos invasores explorar padrões previsíveis de registros e executar ações não autorizadas. Ela geralmente ocorre quando as propriedades não são filtradas ao vincular dados fornecidos pelo cliente a modelos de dados. Vulnerabilidades desse tipo permitem que um invasor crie objetos adicionais nos payloads de requisições POST e modifique propriedades que deveriam ser imutáveis.

Node.js é um ambiente de servidor de código aberto que pode ser usado em diferentes plataformas para desenvolver aplicações web. Ele permite que desenvolvedores criem aplicações poderosas e escaláveis com rapidez. Em sua essência, o Node.js é uma plataforma testada em campo e pronta para produção — mas os desafios de segurança das aplicações também envolvem a segurança da cadeia de suprimentos, associada a pacotes de terceiros instalados para criá-las. Às vezes, uma aplicação Node.js pode usar milhares de pacotes npm de código aberto do registro npm, ficando exposta a diversos vetores de ataque.

Vulnerabilidades de atribuição em massa são comuns em aplicações Node.js que enviam payloads ao banco de dados em requisições POST. Um invasor pode explorar essas vulnerabilidades para orquestrar ataques de injeção de SQL ou outros ataques direcionados aos dados armazenados nos bancos de dados. Também pode usar uma vulnerabilidade de atribuição em massa para assumir o controle total de um sistema ou roubar dados confidenciais. Por isso, é essencial se proteger contra esse tipo de ataque.

Este artigo demonstra uma vulnerabilidade de atribuição em massa em um projeto Node.js, como um invasor pode explorá-la e como proteger uma aplicação web.

Como eliminar vulnerabilidades de atribuição em massa no Node.js

Este exemplo usa Mongoose, uma biblioteca de mapeamento de objetos para Node.js e MongoDB (ODM). Ela coordena os objetos no código e no MongoDB, valida o esquema e ajuda a gerenciar as relações entre os dados.

Com base nas informações acima, para proteger uma aplicação Node.js com MongoDB contra atribuição em massa, você precisa fazer isso no Mongoose. Veja abaixo um exemplo de exploração de uma vulnerabilidade de atribuição em massa em uma aplicação Node.js.

Pré-requisitos

Para acompanhar este projeto, você precisará de:

• Node.js instalado

• Acesso a um banco de dados MongoDB e uma string de conexão válida. Este tutorial usa um ambiente na nuvem do MongoDB Atlas, mas você também pode configurar um servidor MongoDB local e atualizar a string de conexão conforme necessário.

Atribuição em massa no Node.js

Para começar este projeto, abra o terminal e execute este comando:

1npm init

Em seguida, instale as dependências:

1npm i mongoose
2npm i express

Para lidar com os dados do formulário acima, precisamos criar um arquivo newUser.js na pasta models para gerenciar o esquema do usuário.

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 reúne todos os campos do formulário de cadastro. O campo extra isAdmin, do tipo Boolean, define a função do usuário. Se você definir esse campo como true, criará um usuário com privilégios de administrador; se definir como false, criará um usuário sem esses privilégios.

Crie um novo diretório chamado routes e adicione o arquivo routes.js para gerenciar os dados do usuário:

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;

O código acima captura os dados do formulário e, em seguida, os estrutura com o modelo newUSer.

Este código tem duas falhas que introduzem uma vulnerabilidade de atribuição em massa. Primeiro, ele usa um nome e um tipo comuns para um campo confidencial: isAdmin. Segundo, o modelo de usuário contém um campo confidencial que não é usado. Para explorar a vulnerabilidade, vamos iniciar um servidor.

Crie um arquivo chamado server.js na pasta raiz do projeto e adicione o código a seguir, substituindo <APP_ID> pelo valor da sua string de conexão:

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

Inicie o servidor executando node server.js.

Um agente malicioso pode explorar essa vulnerabilidade criando uma requisição curl POST que contenha o campo isAdmin definido como true, conforme mostrado abaixo:

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

A requisição acima cria um usuário, Mike, com privilégios de administrador. Esse usuário pode usar suas credenciais para entrar no sistema e fazer tudo o que um administrador pode fazer.

Como se defender contra a atribuição em massa

Podemos fazer três ajustes para aumentar a proteção da aplicação contra ataques de atribuição em massa.

Crie modelos enxutos

Modelos enxutos incluem apenas os dados que se espera que o usuário forneça e excluem campos confidenciais.

No exemplo acima, a primeira e mais importante medida é remover o campo confidencial do modelo newUser, como mostrado abaixo:

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;

Assim, se os invasores conseguirem acessar o código-fonte, não poderão ver o campo confidencial nem usá-lo para orquestrar um ataque. Evite também usar termos previsíveis no banco de dados para definir a função do usuário — como isAdmin, admin e role —, pois um invasor ainda pode adivinhá-los e lançar um ataque.

Valide o esquema dos dados de entrada do usuário

Validação com underscore

Outra forma de proteger sua aplicação é especificar e limitar os campos que uma requisição POST pode processar. Essa técnica é conhecida como lista de permissões e usa a biblioteca underscore. Primeiro, instale a biblioteca:

1npm install underscore

Acesse a pasta routes e substitua o 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;

No código acima, usamos a função pick para especificar as variáveis extraídas de uma requisição POST. Isso impede que um invasor use o campo confidencial isAdmin.

O desafio de usar underscore é que a aplicação precisa processar os dados para saber se são válidos. Em outras palavras, os erros não são detectados com antecedência suficiente.

Validação com Zod

Para validar esquemas com rigor, use Zod. Ele valida o esquema para garantir que os dados sigam à risca a estrutura, o padrão e o tipo de dado especificados. O Zod identifica dados incompletos ou incorretos com antecedência, evitando erros na aplicação. Além disso, você pode criar facilmente uma mensagem de erro que oriente o usuário sobre os dados que causaram o erro e o tipo de erro.

O trecho de código demonstra como o Zod funciona. Observe que o trecho a seguir está em TypeScript e exige algumas configurações adicionais.

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

Se o usuário tentar inserir dados que não correspondam ao esquema, receberá um erro invalid_type_error. Se deixar um campo vazio, receberá um erro required_error.

Mais exemplos de vulnerabilidades de atribuição em massa em ORMs

Vamos ver mais três exemplos de vulnerabilidades de atribuição em massa em soluções ORM comuns.

Vulnerabilidade de atribuição em massa em código Sequelize

Veja um exemplo de código Sequelize vulnerável à atribuição em massa. O código define um modelo de usuário, cria um usuário e salva os dados dele no banco de dados:

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

Ao criar um novo usuário, o controlador chama o modelo acima, como mostrado a seguir:

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

O código acima é vulnerável porque expõe o campo confidencial is_verified. Um invasor pode criar uma requisição POST com o campo is_verified definido como true e, assim, ignorar a etapa de verificação.

Podemos eliminar a vulnerabilidade de atribuição em massa neste código removendo o campo is_verified ao criar o usuário. O código seguro seria assim:

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

Isso limita as variáveis aceitas na requisição POST a nome de usuário, e-mail e senha.

Vulnerabilidade de atribuição em massa em código Prisma

Abaixo está um exemplo de código Prisma vulnerável à atribuição em massa, que expõe o 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 adicionar um usuário, criamos uma rota 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 requisição POST espera um objeto de usuário no corpo. O código acima é vulnerável a ataques de atribuição em massa porque um hacker pode definir o campo role como ADMIN para obter privilégios de administrador.

Podemos eliminar a vulnerabilidade no código acima excluindo do modelo o campo confidencial Role.

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

Vulnerabilidade de atribuição em massa em código MySQL

Veja um exemplo de código MySQL vulnerável à atribuição em massa que expõe o 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 adiciona o usuário definido acima:

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

O código acima tem uma vulnerabilidade de atribuição em massa porque expõe um campo confidencial — isAdmin — e permite incluí-lo em uma requisição POST. Um invasor pode criar uma requisição POST que defina o campo isAdmin como true, criando um usuário administrador.

Podemos corrigir essa vulnerabilidade excluindo o campo confidencial ao criar o objeto user. Veja o 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};

O valor padrão false do campo isAdmin pode ser definido alterando a tabela com o seguinte comando:

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

Mantenha seu código seguro no Node.js

O Node.js é seguro, mas às vezes os pacotes necessários para criar uma aplicação web não são. Em aplicações Node.js que enviam requisições a um banco de dados, a vulnerabilidade de atribuição em massa é um dos vetores de ataque mais comuns. Ela permite que usuários maliciosos realizem ataques de injeção de SQL, que envolvem o envio de requisições maliciosas a um banco de dados.

No entanto, é fácil evitar a atribuição em massa no Node.js higienizando os dados de entrada. Você pode fazer isso deixando de expor campos confidenciais, limitando os campos aceitos ou impedindo a edição de determinados campos.

A falta de uma validação rigorosa dos dados de entrada do usuário expõe o sistema a ataques como poluição de protótipo. Esses ataques podem contornar mecanismos de validação fracos, como o underscore. Por isso, use sempre soluções robustas, como o Zod.

Confira o exemplo completo do código-fonte em nosso repositório do GitHub e faça seus próprios testes de segurança locais para ver como evitar vulnerabilidades de atribuição em massa no Node.js.

Siga as 10 principais práticas recomendadas de segurança para Node.js da Snyk para otimizar a segurança da sua aplicação Node.js.