inyección de comandos. En algunos casos, incluso encontrará dos archivos `<target>.env.placeholder` para comparar tokens reales con marcadores de posición.

Todo lo que necesita proporcionar es: el `<target>` o cualquier otro nombre de herramienta o de categoría.
Para objetivos de endpoint, necesitará `<target>-plus-sec-files`, `<target>-plus-content-type`,
`<target>.env.placeholder`, etc. Estos se encuentran en el directorio `~/.gf/`.

> **Nota**: Hasta donde sé, `gf` no tiene patrones predeterminados; debe crearlos usted mismo.

El objetivo aquí es mejorar la calidad de vida. Ser eficiente al mismo tiempo que
se mantienen pruebas de alta calidad. Algo como `gf` cambia las reglas del juego.
Esta herramienta es simplemente `gf` con baterías incluidas.

---

# Instalación

## Manualmente

```bash
cp -r .gf ~/

cp -r .gf ~/.gf.bak
cp -r .gf ~/

git clone https://github.com/emadshanab/gf.git

cp -r gf/.gf ~/

# gf-completion
source /path/to/.gf/.gf-completion.bash

## Instalación```sh
npm install vm2

La herramienta es altamente configurable con diferentes modos de operación como Wiz, Open y Autonomous; también puedes ajustar los umbrales de diversidad y riesgo, dependiendo de tu caso de uso.

```bash
git clone https://github.com/<username>/Wolverine.git
cd Wolverine
pip install -r requirements.txt
python wolverine.py [options]

## Documentación

-   [VM](#vm)
-   [NodeVM](#nodevm)
-   [VMScript](#vmscript)
-   [Manejo de errores](#error-handling)
-   [Depuración de código en un sandbox](#debugging-a-sandboxed-code)
-   [Objetos de solo lectura](#read-only-objects-experimental)
-   [Objetos protegidos](#protected-objects-experimental)
-   [Relaciones entre sandboxes](#cross-sandbox-relationships)
-   [CLI](#cli)
-   [Cambios de 2.x a 3.x](https://github.com/patriksimek/vm2/wiki/2.x-to-3.x-changes)
-   [Documentación de 1.x y 2.x](https://github.com/patriksimek/vm2/wiki/1.x-and-2.x-docs)
-   [Contribuir](https://github.com/patriksimek/vm2/wiki/Contributing)

## VM

VM es un sandbox simple para ejecutar código no confiable de forma síncrona sin la característica `require`. Solo están disponibles los objetos integrados de JavaScript y el `Buffer` de Node. Las funciones de programación (`setInterval`, `setTimeout` y `setImmediate`) no están disponibles por defecto.

**Opciones:**

-   `timeout` - Tiempo de espera del script en milisegundos. **ADVERTENCIA**: Es posible que desee usar esta opción junto con `allowAsync=false`. Además, operar sobre objetos devueltos desde el sandbox puede ejecutar código arbitrario y eludir el tiempo de espera. Se debe comprobar si el objeto devuelto es un primitivo con `typeof` y descartarlo por completo en caso contrario (hacer registros o crear mensajes de error con dicho objeto también podría ejecutar código arbitrario de nuevo).
-   `sandbox` - El objeto global de VM.
-   `compiler` - `javascript` (predeterminado), `typescript`, `coffeescript` o función de compilador personalizada. La librería espera que usted tenga el compilador preinstalado si el valor se establece en `typescript` o `coffeescript`.
-   `eval` - Si se establece en `false`, cualquier llamada a `eval` o a constructores de funciones (`Function`, `GeneratorFunction`, etc.) lanzará un `EvalError` (predeterminado: `true`).
-   `wasm` - Si se establece en `false`, cualquier intento de compilar un módulo WebAssembly lanzará un `WebAssembly.CompileError` (predeterminado: `true`). Nota: `WebAssembly.JSTag` se elimina dentro del sandbox por razones de seguridad, por lo que el código wasm no puede capturar excepciones de JavaScript.
-   `allowAsync` - Si se establece en `false`, cualquier intento de ejecutar código usando `async` lanzará un `VMError` (predeterminado: `true`).
-   `bufferAllocLimit` - Tamaño máximo en bytes para una única solicitud de `Buffer.alloc` / `Buffer.allocUnsafe` / `Buffer.allocUnsafeSlow` / `Buffer(N)` / `new Buffer(N)` desde dentro del sandbox. Las solicitudes que excedan este límite lanzan un `RangeError` de forma síncrona sin realizar la asignación en el host. Predeterminado: `Infinity` (sin límite, totalmente compatible hacia atrás). Los integradores que ejecutan código no confiable en entornos con memoria restringida (Docker / Kubernetes / Lambda / serverless) deberían optar por un límite finito (p. ej. `32 * 1024 * 1024`) como parte de una defensa contra DoS por capas, de la misma manera que optan por `timeout`. Ver [Recomendaciones de endurecimiento](#hardening-recommendations) a continuación.

**IMPORTANTE**: El tiempo de espera solo es efectivo en código síncrono que se ejecute a través de `run`. El tiempo de espera **NO** funciona en ningún método devuelto por VM. Hay algunas situaciones en las que el tiempo de espera no funciona; consulte [#244](https://github.com/patriksimek/vm2/pull/244).```js
import { VM } from 'vm2';

const vm = new VM({
	timeout: 1000,
	allowAsync: false,
	sandbox: {},
});

vm.run('process.exit()'); // throws ReferenceError: process is not defined

**TIP**: Consulta los tests para más ejemplos de uso.

## NodeVM

A diferencia de `VM`, `NodeVM` te permite requerir módulos de la misma manera que lo harías en el contexto normal de Node.

**Opciones:**

-   `console` - `inherit` para habilitar la consola, `redirect` para redirigir a eventos, `off` para desactivar la consola (por defecto: `inherit`).
-   `sandbox` - El objeto global de la VM.
-   `compiler` - `javascript` (por defecto), `typescript`, `coffeescript` o una función de compilador personalizada (que recibe el código y su ruta de archivo). La librería espera que tengas el compilador preinstalado si el valor se establece en `typescript` o `coffeescript`.
-   `eval` - Si se establece en `false`, cualquier llamada a `eval` o a constructores de funciones (`Function`, `GeneratorFunction`, etc.) lanzará un `EvalError` (por defecto: `true`).
-   `wasm` - Si se establece en `false`, cualquier intento de compilar un módulo WebAssembly lanzará un `WebAssembly.CompileError` (por defecto: `true`). Nota: `WebAssembly.JSTag` se elimina dentro del sandbox por razones de seguridad, por lo que el código wasm no puede capturar excepciones de JavaScript.
-   `bufferAllocLimit` - Misma semántica que en `VM`: tamaño máximo en bytes para una sola solicitud de la familia `Buffer.alloc` desde dentro del sandbox. Por defecto: `Infinity`. Consulta [Recomendaciones de endurecimiento](#hardening-recommendations).
-   `sourceExtensions` - Array de extensiones de archivo a tratar como código fuente (por defecto: `['js']`).
-   `require` - `true`, un objeto o un Resolver para habilitar el método `require` (por defecto: `false`).
-   `require.external` - Los valores pueden ser `true`, un array de módulos externos permitidos o un objeto (por defecto: `false`). Todas las rutas que coincidan con `/node_modules/${any_allowed_external_module}/(?!/node_modules/)` pueden ser requeridas.
-   `require.external.modules` - Array de módulos externos permitidos. También admite comodines, por lo que especificar `['@scope/*-ver-??]`, por ejemplo, permitirá usar todos los módulos que tengan un nombre de la forma `@scope/something-ver-aa`, `@scope/other-ver-11`, etc. El comodín `*` no coincide con separadores de ruta.
-   `require.external.transitive` - Booleano que indica si las dependencias transitivas de los módulos externos están permitidas (por defecto: `false`). **ADVERTENCIA**: Cuando un módulo se requiere de forma transitiva, cualquier módulo puede entonces requerirlo normalmente, incluso si esto no era posible antes de que se cargara.
-   `require.builtin` - Array de módulos integrados permitidos, acepta ["\*"] para todos (por defecto: ninguno). **ADVERTENCIA**: "\*" puede ser peligroso ya que se pueden añadir nuevos integrados.
-   `require.root` - Ruta(s) restringida(s) donde se pueden requerir módulos locales (por defecto: todas las rutas).
-   `require.mock` - Colección de módulos simulados (tanto externos como integrados).
-   `require.context` - `host` (por defecto) para requerir módulos en el host y proxyarlos hacia el sandbox. `sandbox` para cargar, compilar y requerir módulos en el sandbox. `callback(moduleFilename, ext)` para elegir dinámicamente un contexto por módulo. El valor por defecto será sandbox si no se especifica nada. Excepto para `events`, los módulos integrados siempre se requieren en el host y se proxyan hacia el sandbox.
-   `require.import` - Un array de módulos a cargar en NodeVM al inicio.
-   `require.resolve` - Una función de búsqueda adicional en caso de que un módulo no se encuentre en una de las rutas de búsqueda tradicionales de node.
-   `require.customRequire` - Se usa en lugar de la función `require` para cargar módulos desde el host.
-   `require.strict` - `false` para no forzar el modo estricto en los módulos cargados por require (por defecto: `true`).
-   `require.fs` - Implementación personalizada del sistema de archivos.
-   `nesting` - **ADVERTENCIA**: Permitir esto es un riesgo de seguridad, ya que los scripts pueden crear una NodeVM que pueda requerir cualquier módulo del host. `true` para habilitar el anidamiento de VMs (por defecto: `false`).
-   `wrapper` - `commonjs` (por defecto) para envolver el script en un wrapper CommonJS, `none` para recuperar el valor devuelto por el script.
-   `argv` - Array a pasar a `process.argv`.
-   `env` - Objeto a pasar a `process.env`.
-   `strict` - `true` para cargar módulos en modo estricto (por defecto: `false`).

**IMPORTANTE**: El timeout no es efectivo para NodeVM, por lo que no es inmune a `while (true) {}` o males similares.

**RECUERDA**: Cuantos más módulos permitas, más frágil se vuelve tu sandbox.```js
import { NodeVM } from 'vm2';

const vm = new NodeVM({
	console: 'inherit',
	sandbox: {},
	require: {
		external: true,
		builtin: ['fs', 'path'],
		root: './',
		mock: {
			fs: {
				readFileSync: () => 'Nice try!',
			},
		},
	},
});

// Sync

let functionInSandbox = vm.run('module.exports = function(who) { console.log("hello "+ who); }');
functionInSandbox('world');

// Async

let functionWithCallbackInSandbox = vm.run('module.exports = function(who, callback) { callback("hello "+ who); }');
functionWithCallbackInSandbox('world', greeting => {
	console.log(greeting);
});

**CONSEJO**: Consulta los tests para ver más ejemplos de uso.

### Cargar módulos mediante ruta relativa

Para cargar módulos mediante ruta relativa, debes pasar la ruta completa del script que estás ejecutando como segundo argumento al método `run` de vm si el script es un string. El nombre del archivo se muestra entonces en cualquier traza de pila generada por el script.```js
vm.run('require("foobar")', '/data/myvmscript.js');

### Resolver

Un resolver puede crearse mediante `makeResolverFromLegacyOptions` y utilizarse para varias instancias de `NodeVM`, lo que permite compartir código de módulos compilados y potencialmente acelerar los tiempos de carga. El primer ejemplo de `NodeVM` puede reescribirse usando `makeResolverFromLegacyOptions` de la siguiente manera.```js
const resolver = makeResolverFromLegacyOptions({
	external: true,
	builtin: ['fs', 'path'],
	root: './',
	mock: {
		fs: {
			readFileSync: () => 'Nice try!',
		},
	},
});
const vm = new NodeVM({
	console: 'inherit',
	sandbox: {},
	require: resolver,
});

Funciona tanto para `VM` como para `NodeVM`.```js
import { NodeVM, VMScript } from 'vm2';

const vm = new NodeVM();
const script = new VMScript('module.exports = Math.random()');
console.log(vm.run(script));
console.log(vm.run(script));

## Depurando código en un sandbox

Puedes depurar o inspeccionar código que se ejecuta en el sandbox como si se ejecutara en un proceso normal.

-   Puedes usar puntos de interrupción (lo que requiere especificar un nombre de archivo de script)
-   Puedes usar la palabra clave `debugger`.
-   Puedes usar step-in para adentrarte en el código que se ejecuta en el sandbox.

### Ejemplo

/tmp/main.js:```js
import { VM, VMScript } from 'vm2';
import { readFileSync } from 'node:fs';

const file = `${__dirname}/sandbox.js`;

// By providing a file name as second argument you enable breakpoints
const script = new VMScript(readFileSync(file), file);

new VM().run(script);

## Objetos de solo lectura (experimental)

Para evitar que los scripts en sandbox añadan, cambien o eliminen propiedades de los objetos proxy, puedes usar los métodos `freeze` para hacer que el objeto sea de solo lectura. Esto solo es efectivo dentro de la VM. Los objetos congelados se ven afectados en profundidad. Los tipos primitivos no se pueden congelar.

**Ejemplo sin usar `freeze`:**```js
const util = {
	add: (a, b) => a + b,
};

const vm = new VM({
	sandbox: { util },
});

vm.run('util.add = (a, b) => a - b');
console.log(util.add(1, 1)); // returns 0

**IMPORTANTE:** No es posible congelar objetos que ya han sido pasados por proxy a la VM.

## Objetos protegidos (experimental)

A diferencia de `freeze`, este método permite que los scripts de la sandbox añadan, cambien o eliminen propiedades de los objetos, con una excepción: no es posible adjuntar funciones. Por lo tanto, los scripts de la sandbox no pueden modificar métodos como `toJSON`, `toString` o `inspect`.

**IMPORTANTE:** No es posible proteger objetos que ya han sido pasados por proxy a la VM.

## Relaciones entre sandboxes```js
const assert = require('assert');
const { VM } = require('vm2');

const sandbox = {
	object: new Object(),
	func: new Function(),
	buffer: new Buffer([0x01, 0x05]),
};

const vm = new VM({ sandbox });

assert.ok(vm.run(`object`) === sandbox.object);
assert.ok(vm.run(`object instanceof Object`));
assert.ok(vm.run(`object`) instanceof Object);
assert.ok(vm.run(`object.__proto__ === Object.prototype`));
assert.ok(vm.run(`object`).__proto__ === Object.prototype);

assert.ok(vm.run(`func`) === sandbox.func);
assert.ok(vm.run(`func instanceof Function`));
assert.ok(vm.run(`func`) instanceof Function);
assert.ok(vm.run(`func.__proto__ === Function.prototype`));
assert.ok(vm.run(`func`).__proto__ === Function.prototype);

assert.ok(vm.run(`new func() instanceof func`));
assert.ok(vm.run(`new func()`) instanceof sandbox.func);
assert.ok(vm.run(`new func().__proto__ === func.prototype`));
assert.ok(vm.run(`new func()`).__proto__ === sandbox.func.prototype);

assert.ok(vm.run(`buffer`) === sandbox.buffer);
assert.ok(vm.run(`buffer instanceof Buffer`));
assert.ok(vm.run(`buffer`) instanceof Buffer);
assert.ok(vm.run(`buffer.__proto__ === Buffer.prototype`));
assert.ok(vm.run(`buffer`).__proto__ === Buffer.prototype);
assert.ok(vm.run(`buffer.slice(0, 1) instanceof Buffer`));
assert.ok(vm.run(`buffer.slice(0, 1)`) instanceof Buffer);

## Hardening recommendations

vm2 previene escapes de la sandbox (código no confiable que obtiene acceso al realm del host). No previene, **por sí solo**, cada forma de agotamiento de recursos o denegación de servicio. Quienes integren vm2 y ejecuten código no confiable deberían añadir las siguientes defensas en capas alrededor de la sandbox.

### 1. Limita la asignación de memoria con `bufferAllocLimit`

Una sola llamada a `Buffer.alloc(N)` con un `N` controlado por el atacante se ejecuta como una asignación síncrona en C++ del host que el `timeout` de V8 no puede interrumpir. En entornos con memoria limitada, un payload de la sandbox de ~100 bytes puede provocar un salto de más de 100 MB en el RSS del host y estrellar el proceso del host por OOM. Establece `bufferAllocLimit` (p. ej. `32 * 1024 * 1024`) para limitar las asignaciones individuales:```js
const vm = new VM({
	timeout: 1000,
	bufferAllocLimit: 32 * 1024 * 1024,
	allowAsync: false,
});

Si tu aplicación no tiene otra fuente de rechazos no manejados, un swallow general + registro es aceptable:```js
process.on('unhandledRejection', reason => {
	yourLogger.warn('swallowed sandbox rejection', reason);
});

Si estableces `nesting: true`, efectivamente le has otorgado al sandbox el mismo nivel de confianza que tienes tú. **No habilites `nesting: true` para código no confiable.** Úsalo solo cuando confíes en el propio código del sandbox pero quieras semántica de ejecución tipo VM (global nuevo, timeouts controlados) por razones no relacionadas con la seguridad.

`nesting: true` **requiere un objeto de configuración `require` explícito** (p. ej. `require: { builtin: [] }` o `require: {}`). Cualquier otra forma — `require: false`, `require: undefined`, `require: null` u omitir `require` por completo — lanza `VMError` en la construcción (GHSA-m4wx-m65x-ghrr, sustituye a GHSA-8hg8-63c5-gwmx). Todas esas formas producen un resolver de solo NESTING_OVERRIDE: el sandbox puede `require('vm2')` pero nada más, lo cual es una primitiva de escape pura sin ningún uso legítimo. Para denegar todos los require, elimina `nesting: true`. Para permitir VMs anidadas, proporciona una configuración `require` explícita para que la compensación sea visible en el lugar de la llamada.

## Problemas conocidos

-   No es posible definir una clase que extienda una clase proxy. Esto incluye usar una clase proxy en `Object.create`.
-   El eval directo no funciona.
-   Al registrar arreglos del sandbox, la parte del arreglo se repetirá en las propiedades.
-   Las transformaciones del código fuente pueden dar lugar a una cadena de código fuente diferente para una función.
-   Hay formas de hacer fallar el proceso de node desde dentro del sandbox. Consulta [Recomendaciones de endurecimiento](#hardening-recommendations).

[npm-image]: https://img.shields.io/npm/v/vm2.svg
[npm-url]: https://www.npmjs.com/package/vm2
[license-image]: https://img.shields.io/npm/l/vm2.svg
[license-url]: https://raw.githubusercontent.com/patriksimek/vm2/resurrection/LICENSE.md
[downloads-image]: https://img.shields.io/npm/dm/vm2.svg
[downloads-url]: https://www.npmjs.com/package/vm2
[snyk-image]: https://snyk.io/test/github/patriksimek/vm2/badge.svg
[snyk-url]: https://snyk.io/test/github/patriksimek/vm2