patriksimek/vm2Sandbox de JavaScript aislado para Node.js que ejecuta código no confiable con acceso restringido a módulos integrados y recursos del host mediante la intercepción basada en Proxy.
[![Known Vulnerabilities][snyk-image]][snyk-url]vm2 es un sandbox que puede ejecutar código no confiable con los módulos integrados de Node permitidos en la lista blanca.
npm install vm2
## Ejemplos rápidos```js
import { VM } from 'vm2';
const vm = new VM();
vm.run(`process.exit()`); // TypeError: process.exit is not a function
Aquí tienes la traducción al español del fragmento 5 de 55:
Nota: El fragmento proporcionado está vacío. No hay contenido que traducir.```js import { NodeVM } from 'vm2';
const vm = new NodeVM({ require: { external: true, root: './', }, });
vm.run(
var request = require('request'); request('http://www.google.com', function (error, response, body) { console.error(error); if (!error && response.statusCode == 200) { console.log(body); // Show the HTML for the Google homepage. } });,
'vm.js',
);
## Aviso de seguridad importante
**Antes de usar vm2, debes entender cómo funciona y sus limitaciones.**
vm2 intenta aislar código JavaScript no confiable **dentro del mismo proceso de Node.js** que tu aplicación. Lo hace mediante una compleja red de [Proxies](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Proxy) que interceptan y median cada interacción entre el sandbox y el entorno anfitrión.
### El desafío fundamental
JavaScript es un lenguaje extraordinariamente dinámico. Se puede acceder a los objetos a través de cadenas de prototipos, se puede llegar a los constructores mediante objetos de error, los símbolos proporcionan enlaces de protocolo y la ejecución asíncrona crea ventanas de sincronización. La gran cantidad de formas de pasar de un objeto a otro en JavaScript hace que construir un sandbox hermético dentro del proceso sea extremadamente difícil.
**Somos honestos sobre esta realidad:** A pesar de nuestros mejores esfuerzos, los investigadores y profesionales de seguridad descubren continuamente nuevas formas de escapar del sandbox de vm2. Parcheamos activamente estas vulnerabilidades a medida que se reportan, pero la naturaleza de gato y ratón del sandboxing dentro del proceso significa que:
1. **Es probable que se descubran nuevas evasiones en el futuro.** Consulta nuestros [avisos de seguridad](https://github.com/patriksimek/vm2/security/advisories) para conocer las vulnerabilidades conocidas.
2. **Debes mantener vm2 actualizado** para beneficiarte de los últimos parches de seguridad. Suscríbete a los avisos de seguridad y actualiza con prontitud.
3. **vm2 no debe ser tu única línea de defensa.** La defensa en profundidad es esencial al ejecutar código no confiable.
### Alternativas más robustas
Si necesitas garantías de aislamiento más sólidas, considera estas alternativas que proporcionan **aislamiento real a nivel de proceso o hardware**:
| Solución | Enfoque | Rendimiento | Compensaciones |
|----------|---------|-------------|----------------|
| **[isolated-vm](https://github.com/laverdet/isolated-vm)** | Aislamientos V8 separados (heap V8 diferente) | Rápido | En modo de mantenimiento; requiere actualizaciones manuales de V8 |
| **Proceso separado / Worker** | `child_process` o hilos Worker con permisos limitados | Medio | Mayor sobrecarga de IPC; los datos deben serializarse |
| **Contenedores / VMs** | Docker, gVisor, Firecracker | Lento | Sobrecarga de inicio; uso intensivo de recursos |
| **Servicios gestionados** | Ejecución de código basada en la nube (p. ej., AWS Lambda, Cloudflare Workers) | Variable | Latencia de red; dependencia externa |
### Cuándo vm2 puede seguir siendo apropiado
vm2 puede ser adecuado cuando:
- Necesitas una integración estrecha con objetos del anfitrión y comunicación síncrona rápida
- El código no confiable proviene de una fuente relativamente confiable (p. ej., herramientas internas, sistemas de plugins con autores verificados)
- Combinas vm2 con otras capas de seguridad (aislamiento de red, restricciones del sistema de archivos, límites de recursos)
- Aceptas el riesgo y supervisas activamente las actualizaciones de seguridad
**Si ejecutas código de fuentes completamente no confiables (p. ej., envíos de usuarios arbitrarios), recomendamos encarecidamente usar una solución con garantías de aislamiento más sólidas.**
## Entornos de ejecución
| Entorno | Estado |
|---------|--------|
| Node.js | Compatible. El sandbox es un límite de seguridad. |
| Bun | **Experimental.** Compatibilidad funcional parcial — **no** es un límite de seguridad. |
Se aplican dos limitaciones separadas a Bun, y ninguna implica la otra.
**No es un límite de seguridad.** El modelo de amenazas de vm2, el catálogo de ataques en
[`docs/ATTACKS.md`](https://github.com/patriksimek/vm2/blob/main/docs/ATTACKS.md) y cada prueba de regresión en `test/ghsa/`
se derivan de los internals de V8. JavaScriptCore, que usa Bun, tiene sus propios
equivalentes, y ninguno ha sido auditado contra el puente de vm2. Que la suite pase
bajo Bun demuestra compatibilidad, no que el sandbox se mantenga allí. **No uses
vm2 en Bun para aislar código no confiable.**
**La compatibilidad es parcial, no paridad.** Una ejecución exitosa en Bun cubre solo las pruebas
que realmente se ejecutan allí. `test/bun-skips.js` enumera lo que se excluye y por qué,
y las brechas de comportamiento conocidas incluyen:
- `Buffer.from(arrayLike)` devuelve un buffer de longitud cero
- Los metadatos `filename` / `lineOffset` / `columnOffset` de `VMScript` no son
observables, porque los objetos CallSite de JSC no llevan métodos
- `Object.freeze` en un objeto anfitrión congelado con un accessor no configurable
lanza un `TypeError` de invariante de proxy donde V8 no lo hace
- algunas operaciones de `Buffer` a través del límite del sandbox son drásticamente más lentas —
un `allocUnsafe` de 64 MB tarda más de 400 segundos frente a 1.7 en Node, lo suficientemente lento
como para parecer un cuelgue
Trata la compatibilidad con Bun como un esfuerzo de mejor compatibilidad para código confiable, y consulta la
lista de omisiones antes de depender de cualquier comportamiento particular.
## Características
- Ejecuta código no confiable de forma segura en un solo proceso junto a tu código
- Control total sobre la salida de consola del sandbox
- El sandbox tiene acceso limitado a los métodos del proceso
- Es posible requerir módulos (integrados y externos) desde el sandbox
- Puedes limitar el acceso a ciertos módulos integrados (o a todos)
- Puedes llamar métodos de forma segura e intercambiar datos y callbacks entre sandboxes
- Mantenido activamente con parches para métodos de escape conocidos (consulta [Aviso de seguridad](#important-security-disclaimer))
- Soporte de transpilador
## Cómo funciona
- Utiliza el módulo VM interno para crear un contexto seguro.
- Utiliza [Proxies](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Proxy) para evitar escapar del sandbox.
- Sobrescribe el require integrado para controlar el acceso a los módulos.
Para un análisis en profundidad de los internals de vm2, consulta [docs/ATTACKS.md](https://github.com/patriksimek/vm2/blob/main/docs/ATTACKS.md).
## ¿Cuál es la diferencia entre el vm de Node y vm2?
Pruébalo tú mismo:```js
import { runInNewContext } from "node:vm";
runInNewContext('this.constructor.constructor("return process")().exit()');
console.log('Never gets executed.');
I need the actual content of chunk 9 to translate it. Please provide the Markdown text you want translated.```js import { VM } from 'vm2';