Risk of remote code execution for untrusted schemas

[koorchik]

Code

import FastestValidator from 'fastest-validator';
const v = new FastestValidator();

const check = v.compile({
  id: { type: 'number', max: 'console.log("ALERT")' }
});

check({id:123});

will print 'ALERT'.

Ajv validator has similar architecture but is secure for such types of attacks.

It is possible to guard against such type of attack with quoting of parameters which can be done in compile-time
"Ajv Safe code generation" - https://ajv.js.org/codegen.html#safe-code-generation

[icebob]

The validation schema is not a user input data, so it's not a real issue and we also don't recommend to do it

[koorchik]

Yes, but the risk of remote code execution for untrusted does exist as it was with ajv before (now it is fixed)

Moreover, according to this library docs: "This is as safe as writing code normally and having it compiled by V8 in the usual way.". But it is half true. For example, with Joi validator, you write code but it is safer.

Joi example with code (code is safe):

function prepareValidator(maxId) {
  return Joi.object({
    id: Joi.number().max(maxId),
  });
}

Code is potentially vulnerable with maxId coming from database, for example

function prepareValidator(maxId) {
  return fastestValidator.compile({ 
    id: {type: 'number', max: maxId} 
  });
}

So, compared to code you expect that data is data (string is string, number is number), and code is code. But here is string data can be a code.

[intech]

@icebob I think this is a real security problem. Possible attack by merging two vectors:
Prototype pollution (very popular in many packages) + eval injection (this issue).

@koorchik Thx for this report!

[FerX]

without losing performance we could insert a sanitization during compilation

[Freezystem]

I know it's a one year old issue but I actually might have a partial solution:

There is a way to execute generated javascript string "safely" using NodeJS VM module.
Deno and Bun will be compatible by importing the module with node:vm.

Although the documentation states:

The node:vm module is not a security mechanism. Do not use it to run untrusted code.

It is still better than running untrusted code from eval() as you can specify a set of available function in the context:

const vm = require('node:vm');

// Create a restricted context
const restrictedContext = {
    // Only include what you want to expose
    console: { log: console.log },
    Math: Math,
    // You can add your own safe versions of functions
    setTimeout: (fn, ms) => {
        // Add your own safety checks
        if (ms > 5000) throw new Error('Timeout too long');
        return setTimeout(fn, ms);
    }
    // Add other safe functions/objects you want to allow
};

const context = vm.createContext(restrictedContext);

// Safe code execution
try {
    vm.runInContext('console.log(Math.random)', context);  // Works
    vm.runInContext('console.warn("error")', context);  // Throws error
    vm.runInContext('setTimeout(() => {}, 10000)', context);  // Throws error
} catch (error) {
    console.error('Execution error:', error);
}