vm2 [![NPM Version][npm-image]][npm-url] [![NPM Downloads][downloads-image]][downloads-url] [![License][license-image]][license-url] [![Known Vulnerabilities][snyk-image]][snyk-url]

vm2 एक सैंडबॉक्स है जो व्हाइटलिस्टेड Node के बिल्ट-इन मॉड्यूल के साथ अविश्वसनीय कोड चला सकता है।

महत्वपूर्ण सुरक्षा अस्वीकरण

vm2 का उपयोग करने से पहले, आपको समझना चाहिए कि यह कैसे काम करता है और इसकी सीमाएँ क्या हैं।

vm2 आपके एप्लिकेशन के उसी Node.js प्रोसेस के भीतर अविश्वसनीय JavaScript कोड को सैंडबॉक्स करने का प्रयास करता है। यह Proxies के एक जटिल नेटवर्क के माध्यम से ऐसा करता है जो सैंडबॉक्स और होस्ट वातावरण के बीच हर अंतःक्रिया को रोकता और मध्यस्थता करता है।

मूलभूत चुनौती

JavaScript एक असाधारण रूप से गतिशील भाषा है। ऑब्जेक्ट्स को प्रोटोटाइप चेन के माध्यम से एक्सेस किया जा सकता है, कंस्ट्रक्टर तक एरर ऑब्जेक्ट्स के माध्यम से पहुँचा जा सकता है, सिंबल प्रोटोकॉल हुक प्रदान करते हैं, और एसिंक्रोनस निष्पादन टाइमिंग विंडो बनाता है। JavaScript में एक ऑब्जेक्ट से दूसरे ऑब्जेक्ट तक पहुँचने के जितने तरीके हैं, वे इन-प्रोसेस सैंडबॉक्स को वायुरोधी बनाना अत्यंत कठिन बना देते हैं।

हम इस वास्तविकता के बारे में ईमानदार हैं: हमारे सर्वोत्तम प्रयासों के बावजूद, शोधकर्ता और सुरक्षा पेशेवर लगातार vm2 सैंडबॉक्स से बचने के नए तरीके खोजते रहते हैं। हम इन कमजोरियों की रिपोर्ट मिलते ही सक्रिय रूप से पैच करते हैं, लेकिन इन-प्रोसेस सैंडबॉक्सिंग की बिल्ली-और-चूहे वाली प्रकृति का मतलब है कि:

भविष्य में नए बाईपास खोजे जाने की संभावना है। ज्ञात कमजोरियों के लिए हमारे सुरक्षा परामर्श देखें।
आपको vm2 को अपडेट रखना ही होगा ताकि नवीनतम सुरक्षा सुधारों का लाभ मिल सके। सुरक्षा परामर्शों की सदस्यता लें और तुरंत अपडेट करें।
vm2 आपकी एकमात्र सुरक्षा पंक्ति नहीं होनी चाहिए। अविश्वसनीय कोड चलाते समय रक्षा की गहराई (defense in depth) आवश्यक है।

अधिक मजबूत विकल्प

यदि आपको मजबूत अलगाव गारंटी की आवश्यकता है, तो इन विकल्पों पर विचार करें जो वास्तविक प्रोसेस या हार्डवेयर-स्तरीय अलगाव प्रदान करते हैं:

vm2 अभी भी कब उपयुक्त हो सकता है

vm2 तब उपयुक्त हो सकता है जब:

आपको होस्ट ऑब्जेक्ट्स के साथ घनिष्ठ एकीकरण और तेज़ सिंक्रोनस संचार की आवश्यकता हो
अविश्वसनीय कोड अपेक्षाकृत विश्वसनीय स्रोत से आता है (जैसे, आंतरिक उपकरण, सत्यापित लेखकों वाले प्लगइन सिस्टम)
आप vm2 को अन्य सुरक्षा परतों (नेटवर्क अलगाव, फाइलसिस्टम प्रतिबंध, संसाधन सीमाएँ) के साथ जोड़ते हैं
आप जोखिम स्वीकार करते हैं और सुरक्षा अपडेट के लिए सक्रिय रूप से निगरानी करते हैं

यदि आप पूरी तरह से अविश्वसनीय स्रोतों (जैसे, मनमाने उपयोगकर्ता सबमिशन) से कोड चला रहे हैं, तो हम दृढ़ता से अनुशंसा करते हैं कि आप मजबूत अलगाव गारंटी वाले समाधान का उपयोग करें।

विशेषताएँ

अविश्वसनीय कोड को आपके कोड के साथ एक ही प्रोसेस में सुरक्षित रूप से चलाता है
सैंडबॉक्स के कंसोल आउटपुट पर पूर्ण नियंत्रण
सैंडबॉक्स की प्रोसेस के तरीकों तक सीमित पहुँच होती है
सैंडबॉक्स से मॉड्यूल (बिल्ट-इन और बाहरी) require करना संभव है
आप कुछ (या सभी) बिल्ट-इन मॉड्यूल तक पहुँच सीमित कर सकते हैं
आप सैंडबॉक्स के बीच सुरक्षित रूप से विधियों को कॉल कर सकते हैं और डेटा तथा कॉलबैक का आदान-प्रदान कर सकते हैं
ज्ञात एस्केप विधियों के पैच के साथ सक्रिय रूप से रखरखाव किया जाता है (देखें सुरक्षा अस्वीकरण)
ट्रांसपाइलर समर्थन

यह कैसे काम करता है

यह एक सुरक्षित कॉन्टेक्स्ट बनाने के लिए आंतरिक VM मॉड्यूल का उपयोग करता है।
यह सैंडबॉक्स से बचने को रोकने के लिए Proxies का उपयोग करता है।
यह मॉड्यूल तक पहुँच को नियंत्रित करने के लिए बिल्ट-इन require को ओवरराइड करता है।

vm2 के आंतरिक कार्यों की गहराई से जानकारी के लिए CONTRIBUTING.md फ़ाइल देखें।

Node के vm और vm2 के बीच क्या अंतर है?

इसे स्वयं आज़माएँ:```js import { runInNewContext } from "node:vm";

runInNewContext('this.constructor.constructor("return process")().exit()'); console.log('Never gets executed.');

I don't see any content after "INPUT:" to translate. Please provide the chunk text so I can translate it.```js
import { VM } from 'vm2';

new VM().run('this.constructor.constructor("return process")().exit()');
// Throws ReferenceError: process is not defined

स्थापना```sh

npm install vm2

## त्वरित उदाहरण```js
import { VM } from 'vm2';

const vm = new VM();
vm.run(`process.exit()`); // TypeError: process.exit is not a function

I don't see any content after the INPUT: marker, so there is nothing to translate.```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', );

## प्रलेखन

-   [VM](#vm)
-   [NodeVM](#nodevm)
-   [VMScript](#vmscript)
-   [त्रुटि प्रबंधन](#error-handling)
-   [सैंडबॉक्स किए गए कोड की डिबगिंग](#debugging-a-sandboxed-code)
-   [केवल-पठनीय ऑब्जेक्ट](#read-only-objects-experimental)
-   [संरक्षित ऑब्जेक्ट](#protected-objects-experimental)
-   [क्रॉस-सैंडबॉक्स संबंध](#cross-sandbox-relationships)
-   [CLI](#cli)
-   [2.x से 3.x परिवर्तन](https://github.com/patriksimek/vm2/wiki/2.x-to-3.x-changes)
-   [1.x और 2.x दस्तावेज़](https://github.com/patriksimek/vm2/wiki/1.x-and-2.x-docs)
-   [योगदान](https://github.com/patriksimek/vm2/wiki/Contributing)

## VM

VM एक सरल सैंडबॉक्स है जो `require` सुविधा के बिना अविश्वसनीय कोड को समकालिक रूप से चलाने के लिए है। केवल JavaScript के अंतर्निहित ऑब्जेक्ट और Node का `Buffer` उपलब्ध हैं। शेड्यूलिंग फ़ंक्शन (`setInterval`, `setTimeout` और `setImmediate`) डिफ़ॉल्ट रूप से उपलब्ध नहीं हैं।

**विकल्प:**

-   `timeout` - स्क्रिप्ट टाइमआउट मिलीसेकंड में। **चेतावनी**: आप इस विकल्प का उपयोग `allowAsync=false` के साथ करना चाहेंगे। इसके अलावा, सैंडबॉक्स से लौटाए गए ऑब्जेक्ट्स पर कार्य करने से मनमाना कोड चल सकता है और टाइमआउट को दरकिनार किया जा सकता है। यह जाँच करनी चाहिए कि क्या लौटाया गया ऑब्जेक्ट `typeof` के साथ एक प्रिमिटिव है; अन्य मामलों में इसे पूरी तरह से त्याग दें (ऐसे ऑब्जेक्ट के साथ लॉगिंग करना या त्रुटि संदेश बनाना भी फिर से मनमाना कोड चला सकता है)।
-   `sandbox` - VM का वैश्विक ऑब्जेक्ट।
-   `compiler` - `javascript` (डिफ़ॉल्ट), `typescript`, `coffeescript` या कस्टम कंपाइलर फ़ंक्शन। यदि मान `typescript` या `coffeescript` पर सेट है तो लाइब्रेरी अपेक्षा करती है कि आपके पास कंपाइलर पहले से इंस्टॉल हो।
-   `eval` - यदि `false` पर सेट किया गया है, तो `eval` या फ़ंक्शन कंस्ट्रक्टर्स (`Function`, `GeneratorFunction`, आदि) पर कोई भी कॉल `EvalError` फेंकेगा (डिफ़ॉल्ट: `true`)।
-   `wasm` - यदि `false` पर सेट किया गया है, तो WebAssembly मॉड्यूल को संकलित करने का कोई भी प्रयास `WebAssembly.CompileError` फेंकेगा (डिफ़ॉल्ट: `true`)। ध्यान दें: सुरक्षा कारणों से `WebAssembly.JSTag` सैंडबॉक्स के अंदर से हटा दिया गया है, इसलिए wasm कोड JavaScript अपवादों को पकड़ नहीं सकता।
-   `allowAsync` - यदि `false` पर सेट किया गया है, तो `async` का उपयोग करके कोड चलाने का कोई भी प्रयास `VMError` फेंकेगा (डिफ़ॉल्ट: `true`)।
-   `bufferAllocLimit` - सैंडबॉक्स के अंदर से एकल `Buffer.alloc` / `Buffer.allocUnsafe` / `Buffer.allocUnsafeSlow` / `Buffer(N)` / `new Buffer(N)` अनुरोध के लिए बाइट्स में अधिकतम आकार। इस सीमा से अधिक के अनुरोध बिना होस्ट आवंटन किए समकालिक रूप से `RangeError` फेंकते हैं। डिफ़ॉल्ट: `Infinity` (कोई सीमा नहीं, पूरी तरह से पिछड़ा-संगत)। मेमोरी-सीमित वातावरणों (Docker / Kubernetes / Lambda / serverless) में अविश्वसनीय कोड चलाने वाले एम्बेडर्स को स्तरित DoS सुरक्षा के भाग के रूप में एक सीमित कैप (जैसे `32 * 1024 * 1024`) चुनना चाहिए, उसी तरह जैसे वे `timeout` चुनते हैं। नीचे [सुरक्षा सुदृढ़ीकरण अनुशंसाएँ](#hardening-recommendations) देखें।

**महत्वपूर्ण**: टाइमआउट केवल उस समकालिक कोड पर प्रभावी है जिसे आप `run` के माध्यम से चलाते हैं। टाइमआउट VM द्वारा लौटाई गई किसी भी विधि पर काम **नहीं** करता। कुछ स्थितियाँ हैं जब टाइमआउट काम नहीं करता - देखें [#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

आप VM से मान भी प्राप्त कर सकते हैं।```js let number = vm.run('1337'); // returns 1337

**टिप**: अधिक उपयोग उदाहरणों के लिए परीक्षण देखें।

## NodeVM

`VM` के विपरीत, `NodeVM` आपको उसी तरह से मॉड्यूल require करने की अनुमति देता है जैसे आप नियमित Node के संदर्भ में करते हैं।

**विकल्प:**

-   `console` - `inherit` कंसोल सक्षम करने के लिए, `redirect` घटनाओं पर पुनर्निर्देशित करने के लिए, `off` कंसोल अक्षम करने के लिए (डिफ़ॉल्ट: `inherit`)।
-   `sandbox` - VM का ग्लोबल ऑब्जेक्ट।
-   `compiler` - `javascript` (डिफ़ॉल्ट), `typescript`, `coffeescript` या कस्टम कंपाइलर फ़ंक्शन (जो कोड और उसका फ़ाइल पथ प्राप्त करता है)। यदि मान `typescript` या `coffeescript` पर सेट है तो लाइब्रेरी आपसे अपेक्षा करती है कि कंपाइलर पहले से इंस्टॉल हो।
-   `eval` - यदि `false` पर सेट किया जाता है, तो `eval` या फ़ंक्शन कंस्ट्रक्टर्स (`Function`, `GeneratorFunction`, आदि) को कोई भी कॉल `EvalError` फेंकेगा (डिफ़ॉल्ट: `true`)।
-   `wasm` - यदि `false` पर सेट किया जाता है, तो WebAssembly मॉड्यूल को संकलित करने का कोई भी प्रयास `WebAssembly.CompileError` फेंकेगा (डिफ़ॉल्ट: `true`)। ध्यान दें: सुरक्षा कारणों से `WebAssembly.JSTag` को सैंडबॉक्स के अंदर हटा दिया जाता है, इसलिए wasm कोड JavaScript अपवादों को पकड़ नहीं सकता।
-   `bufferAllocLimit` - `VM` के समान अर्थ — सैंडबॉक्स के अंदर से एकल `Buffer.alloc` परिवार अनुरोध के लिए बाइट्स में अधिकतम आकार। डिफ़ॉल्ट: `Infinity`। [कठोरीकरण अनुशंसाएँ](#hardening-recommendations) देखें।
-   `sourceExtensions` - सोर्स कोड के रूप में मानने के लिए फ़ाइल एक्सटेंशन की सरणी (डिफ़ॉल्ट: `['js']`)।
-   `require` - `true`, एक ऑब्जेक्ट या Resolver जो `require` विधि को सक्षम करता है (डिफ़ॉल्ट: `false`)।
-   `require.external` - मान `true`, अनुमत बाहरी मॉड्यूल की सरणी, या एक ऑब्जेक्ट हो सकते हैं (डिफ़ॉल्ट: `false`)। `/node_modules/${any_allowed_external_module}/(?!/node_modules/)` से मेल खाने वाले सभी पथों को require करने की अनुमति है।
-   `require.external.modules` - अनुमत बाहरी मॉड्यूल की सरणी। यह वाइल्डकार्ड का भी समर्थन करता है, इसलिए उदाहरण के लिए `['@scope/*-ver-??]` निर्दिष्ट करने पर `@scope/something-ver-aa`, `@scope/other-ver-11`, आदि के रूप में नाम वाले सभी मॉड्यूल का उपयोग करने की अनुमति मिलेगी। `*` वाइल्डकार्ड पथ विभाजकों से मेल नहीं खाता।
-   `require.external.transitive` - बूलियन जो दर्शाता है कि बाहरी मॉड्यूल की ट्रांज़िटिव निर्भरताएँ अनुमत हैं या नहीं (डिफ़ॉल्ट: `false`)। **चेतावनी**: जब किसी मॉड्यूल को ट्रांज़िटिव रूप से require किया जाता है, तो कोई भी मॉड्यूल उसे सामान्य रूप से require कर सकता है, भले ही यह उसके लोड होने से पहले संभव न हो।
-   `require.builtin` - अनुमत बिल्ट-इन मॉड्यूल की सरणी, सभी के लिए ["\*"] स्वीकार करता है (डिफ़ॉल्ट: none)। **चेतावनी**: "\*" खतरनाक हो सकता है क्योंकि नए बिल्ट-इन जोड़े जा सकते हैं।
-   `require.root` - प्रतिबंधित पथ जहाँ स्थानीय मॉड्यूल require किए जा सकते हैं (डिफ़ॉल्ट: प्रत्येक पथ)।
-   `require.mock` - मॉक मॉड्यूल का संग्रह (दोनों बाहरी या बिल्ट-इन)।
-   `require.context` - `host` (डिफ़ॉल्ट) होस्ट में मॉड्यूल require करने और उन्हें सैंडबॉक्स में प्रॉक्सी करने के लिए। `sandbox` सैंडबॉक्स में मॉड्यूल लोड करने, संकलित करने और require करने के लिए। `callback(moduleFilename, ext)` प्रति मॉड्यूल संदर्भ को गतिशील रूप से चुनने के लिए। यदि कुछ भी निर्दिष्ट नहीं है तो डिफ़ॉल्ट सैंडबॉक्स होगा। `events` को छोड़कर, बिल्ट-इन मॉड्यूल हमेशा होस्ट में require किए जाते हैं और सैंडबॉक्स में प्रॉक्सी किए जाते हैं।
-   `require.import` - स्टार्ट पर NodeVM में लोड किए जाने वाले मॉड्यूल की सरणी।
-   `require.resolve` - एक अतिरिक्त लुकअप फ़ंक्शन, उस स्थिति में जब कोई मॉड्यूल पारंपरिक node लुकअप पथों में से किसी में नहीं मिला हो।
-   `require.customRequire` - होस्ट से मॉड्यूल लोड करने के लिए `require` फ़ंक्शन के बजाय उपयोग करें।
-   `require.strict` - require द्वारा लोड किए गए मॉड्यूल पर स्ट्रिक्ट मोड लागू न करने के लिए `false` (डिफ़ॉल्ट: `true`)।
-   `require.fs` - कस्टम फ़ाइल सिस्टम कार्यान्वयन।
-   `nesting` - **चेतावनी**: इसकी अनुमति देना एक सुरक्षा जोखिम है क्योंकि स्क्रिप्ट एक NodeVM बना सकती हैं जो किसी भी होस्ट मॉड्यूल को require कर सकती है। VMs नेस्टिंग सक्षम करने के लिए `true` (डिफ़ॉल्ट: `false`)।
-   `wrapper` - स्क्रिप्ट को CommonJS रैपर में लपेटने के लिए `commonjs` (डिफ़ॉल्ट), स्क्रिप्ट द्वारा लौटाए गए मान को प्राप्त करने के लिए `none`।
-   `argv` - `process.argv` में पास की जाने वाली सरणी।
-   `env` - `process.env` में पास किया जाने वाला ऑब्जेक्ट।
-   `strict` - लोड किए गए मॉड्यूल को स्ट्रिक्ट मोड में रखने के लिए `true` (डिफ़ॉल्ट: `false`)।

**महत्वपूर्ण**: टाइमआउट NodeVM के लिए प्रभावी नहीं है, इसलिए यह `while (true) {}` या समान बुराई से प्रतिरक्षित नहीं है।

**याद रखें**: आप जितने अधिक मॉड्यूल की अनुमति देते हैं, आपका सैंडबॉक्स उतना ही नाज़ुक होता जाता है।```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);
});

जब wrapper को none पर सेट किया जाता है, तो NodeVM सिंक्रोनस कोड के लिए VM की तरह अधिक व्यवहार करता है।```js assert.ok(vm.run('return true') === true);

**सुझाव**: अधिक उपयोग उदाहरणों के लिए परीक्षण देखें।

### सापेक्ष पथ द्वारा मॉड्यूल लोड करना

सापेक्ष पथ द्वारा मॉड्यूल लोड करने के लिए, यदि स्क्रिप्ट एक स्ट्रिंग है, तो आपको vm के `run` मेथड के दूसरे आर्गुमेंट के रूप में उस स्क्रिप्ट का पूरा पथ पास करना होगा जिसे आप चला रहे हैं। फिर फ़ाइलनाम स्क्रिप्ट द्वारा उत्पन्न किसी भी स्टैक ट्रेस में प्रदर्शित किया जाता है।```js
vm.run('require("foobar")', '/data/myvmscript.js');

यदि आप जो स्क्रिप्ट चला रहे हैं वह एक VMScript है, तो पथ VMScript कंस्ट्रक्टर में दिया गया है।```js const script = new VMScript('require("foobar")', { filename: '/data/myvmscript.js' }); vm.run(script);

### रिज़ॉल्वर

`makeResolverFromLegacyOptions` के माध्यम से एक रिज़ॉल्वर बनाया जा सकता है और इसका उपयोग कई `NodeVM` इंस्टेंसों के लिए किया जा सकता है, जिससे संकलित मॉड्यूल कोड साझा करने की अनुमति मिलती है और संभवतः लोडिंग समय में तेज़ी आती है। `NodeVM` का पहला उदाहरण `makeResolverFromLegacyOptions` का उपयोग करके निम्नानुसार फिर से लिखा जा सकता है।```js
const resolver = makeResolverFromLegacyOptions({
	external: true,
	builtin: ['fs', 'path'],
	root: './',
	mock: {
		fs: {
			readFileSync: () => 'Nice try!',
		},
	},
});
const vm = new NodeVM({
	console: 'inherit',
	sandbox: {},
	require: resolver,
});

VMScript

आप प्रीकंपाइल्ड स्क्रिप्ट का उपयोग करके प्रदर्शन बढ़ा सकते हैं। प्रीकंपाइल्ड VMScript को कई बार चलाया जा सकता है। यह ध्यान रखना महत्वपूर्ण है कि कोड किसी भी VM (context) से बंधा नहीं होता है; बल्कि, इसे प्रत्येक रन से पहले, केवल उस रन के लिए बांधा जाता है।```js import { VM, VMScript } from 'vm2';

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

यह `VM` और `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));

कोड पहली बार चलने पर स्वचालित रूप से संकलित हो जाता है। कोई भी script.compile() के साथ कोड को कभी भी संकलित कर सकता है। एक बार कोड संकलित हो जाने पर, इस विधि का कोई प्रभाव नहीं होता।

त्रुटि प्रबंधन

कोड संकलन और सिंक्रोनस कोड निष्पादन में त्रुटियों को try-catch द्वारा संभाला जा सकता है। एसिंक्रोनस कोड निष्पादन में त्रुटियों को Node के process में uncaughtException इवेंट हैंडलर जोड़कर संभाला जा सकता है।```js try { var script = new VMScript('Math.random()').compile(); } catch (err) { console.error('Failed to compile script.', err); }

try { vm.run(script); } catch (err) { console.error('Failed to execute script.', err); }

process.on('uncaughtException', err => { console.error('Asynchronous error caught.', err); });

## सैंडबॉक्स्ड कोड को डीबग करना

आप सैंडबॉक्स में चल रहे कोड को इस प्रकार डीबग या निरीक्षण कर सकते हैं जैसे कि वह सामान्य प्रक्रिया में चल रहा हो।

-   आप ब्रेकपॉइंट्स का उपयोग कर सकते हैं (जिसके लिए आपको एक स्क्रिप्ट फ़ाइल नाम निर्दिष्ट करना आवश्यक है)
-   आप `debugger` कीवर्ड का उपयोग कर सकते हैं।
-   आप सैंडबॉक्स में चल रहे कोड के अंदर जाने के लिए step-in का उपयोग कर सकते हैं।

### उदाहरण

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

/tmp/sandbox.js```js const foo = 'ahoj';

// The debugger keyword works just fine everywhere. // Even without specifying a file name to the VMScript object. debugger;

## Read-only objects (experimental)

सैंडबॉक्स्ड स्क्रिप्ट्स को प्रॉक्सी किए गए ऑब्जेक्ट्स से प्रॉपर्टीज़ जोड़ने, बदलने या हटाने से रोकने के लिए, आप ऑब्जेक्ट को read-only बनाने हेतु `freeze` मेथड्स का उपयोग कर सकते हैं। यह केवल VM के अंदर प्रभावी है। Frozen ऑब्जेक्ट्स गहरे रूप से प्रभावित होते हैं। Primitive types को freeze नहीं किया जा सकता।

**`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

freeze का उपयोग करने का उदाहरण:```js const vm = new VM(); // Objects specified in the sandbox cannot be frozen. vm.freeze(util, 'util'); // Second argument adds object to global.

vm.run('util.add = (a, b) => a - b'); // Fails silently when not in strict mode. console.log(util.add(1, 1)); // returns 2

**महत्वपूर्ण:** उन ऑब्जेक्ट्स को फ़्रीज़ करना संभव नहीं है जो पहले से ही VM के लिए प्रॉक्सी किए जा चुके हैं।

## संरक्षित ऑब्जेक्ट्स (प्रायोगिक)

`freeze` के विपरीत, यह विधि सैंडबॉक्स्ड स्क्रिप्ट्स को ऑब्जेक्ट्स पर प्रॉपर्टीज़ जोड़ने, बदलने या हटाने की अनुमति देती है, एक अपवाद के साथ - फ़ंक्शन संलग्न करना संभव नहीं है। इसलिए सैंडबॉक्स्ड स्क्रिप्ट्स `toJSON`, `toString` या `inspect` जैसी विधियों को संशोधित नहीं कर सकती हैं।

**महत्वपूर्ण:** उन ऑब्जेक्ट्स को प्रोटेक्ट करना संभव नहीं है जो पहले से ही VM के लिए प्रॉक्सी किए जा चुके हैं।

## क्रॉस-सैंडबॉक्स संबंध```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);

CLI

आप vm2 को कमांड लाइन में उपयोग करने से पहले, इसे npm install vm2 -g के साथ वैश्विक रूप से इंस्टॉल करें।```sh vm2 ./script.js

## सुरक्षा सख्तीकरण अनुशंसाएँ

vm2 सैंडबॉक्स एस्केप (अविश्वसनीय कोड द्वारा होस्ट रिएल्म एक्सेस प्राप्त करना) को रोकता है। यह अपने आप में संसाधन क्षय या डिनायल-ऑफ-सर्विस के हर रूप को नहीं रोकता है। अविश्वसनीय कोड चलाने वाले एम्बेडर्स को सैंडबॉक्स के चारों ओर निम्नलिखित स्तरित सुरक्षा उपाय जोड़ने चाहिए।

### 1. `bufferAllocLimit` के साथ मेमोरी आवंटन सीमित करें

एकल `Buffer.alloc(N)` कॉल, जहाँ `N` हमलावर-नियंत्रित हो, एक सिंक्रोनस होस्ट C++ आवंटन के रूप में चलता है जिसे V8 का `timeout` बाधित नहीं कर सकता। मेमोरी-विवश वातावरण में एक ~100-बाइट सैंडबॉक्स पेलोड 100 MB+ होस्ट RSS में उछाल ला सकता है और OOM के कारण होस्ट प्रोसेस को क्रैश कर सकता है। व्यक्तिगत आवंटन को सीमित करने के लिए `bufferAllocLimit` सेट करें (उदा. `32 * 1024 * 1024`):```js
const vm = new VM({
	timeout: 1000,
	bufferAllocLimit: 32 * 1024 * 1024,
	allowAsync: false,
});

यह कैप अप्रचलित Buffer(N) और new Buffer(N) पथों पर भी लागू होता है। ध्यान दें कि समग्र समाप्ति (कई छोटे आवंटन, Buffer.concat, Uint8Array, String.repeat, Array(n).fill(), आदि) इस कैप द्वारा कवर नहीं होती है — पूर्ण कवरेज के लिए होस्ट-पक्षीय मेमोरी सीमा (--max-old-space-size, कंटेनर सीमा, cgroup) के साथ संयोजित करें।

2. होस्ट-पक्षीय `unhandledRejection` हैंडलर स्थापित करें

होस्ट-प्रोसेस abort DoS का एक वर्ग मौजूद है जहाँ सैंडबॉक्स कोड एक async function, async function*, या await using बनाता है जिसका बॉडी एक मान फेंकता है जो स्टैक फ़ॉर्मेटिंग के दौरान होस्ट-रियल्म त्रुटि ट्रिगर करता है (जैसे e.name = Symbol(); e.stack)। V8 rejection promise को रियल्म के intrinsic Promise के माध्यम से बनाता है, जो vm2 के Promise सबक्लास wrap को बायपास करता है, इसलिए rejection होस्ट तक unhandledRejection के रूप में पहुँचती है। Node 15+ पर डिफ़ॉल्ट व्यवहार प्रक्रिया को समाप्त करना है।

इसे बंद करने के लिए अवलोकनीय होस्ट व्यवहार को बदलना आवश्यक है, इसलिए vm2 डिफ़ॉल्ट रूप से कोई फिक्स शामिल नहीं करता है। एम्बेडर्स को एक प्रोसेस-स्तरीय हैंडलर स्थापित करना चाहिए जो सैंडबॉक्स-उत्पन्न rejections को निगल (या लॉग) करता है:```js // Recommended: filter rejections that originated inside vm2 and swallow them, // while letting your own host-side rejections propagate. process.on('unhandledRejection', (reason, promise) => { // Heuristic: rejections from the sandbox frequently surface as values // without proper Error semantics, or with stacks pointing at vm.js. // Adjust the predicate to match your application. if (looksLikeSandboxOrigin(reason)) { return; // swallow — don't terminate the process } // Otherwise: handle (or rethrow) as normal for your host code. yourLogger.error('unhandled rejection', reason); });

यदि आपके एप्लिकेशन में अनहैंडल्ड रिजेक्शन का कोई अन्य स्रोत नहीं है, तो एक ब्लैंकेट स्वॉलो + लॉग स्वीकार्य है:```js
process.on('unhandledRejection', reason => {
	yourLogger.warn('swallowed sandbox rejection', reason);
});

एक स्कोप्ड फिक्स भविष्य के माइनर रिलीज़ में एक ऑप्ट-इन swallowSandboxUnhandledRejections फ़्लैग के पीछे आ सकता है; तब तक, होस्ट-साइड हैंडलर ही अनुशंसित शमन (mitigation) है।

3. प्रोसेस-स्तरीय मेमोरी सीमा के साथ चलाएँ

bufferAllocLimit सेट होने पर भी, होस्ट प्रोसेस को वर्कलोड के अनुरूप --max-old-space-size (या समतुल्य कंटेनर मेमोरी सीमा) के साथ चलाएँ। यह सीमा एकल-आवंटन प्रिमिटिव के विरुद्ध सुरक्षा देती है; OS-स्तरीय सीमा समग्र रूप से थकावट (aggregate exhaustion) और किसी भी भविष्य के आवंटन प्रिमिटिव से सुरक्षा देती है जिसे vm2 ने अभी तक सीमित नहीं किया है।

4. `require.builtin: ['*']` को एक गैर-सैंडबॉक्स कॉन्फ़िगरेशन के रूप में मानें

'*' वाइल्डकार्ड अधिकांश Node बिल्ट-इन्स तक विस्तारित होता है, जिनमें child_process, fs, dgram, net, http, और dns शामिल हैं। ये पूर्ण होस्ट-क्षमता वाले प्रिमिटिव हैं — require('child_process').execSync('id') सैंडबॉक्स से '*' के अंतर्गत पहुँचा जा सकता है। vm2 का '*' सेमेन्टिक्स जानबूझकर है (कुछ एम्बेडर भरोसेमंद-लेकिन-अलग-थलग कोड चलाते हैं), लेकिन इसे अविश्वसनीय कोड के लिए डिफ़ॉल्ट के रूप में उपयोग नहीं किया जाना चाहिए। अपने सैंडबॉक्स को वास्तव में जिन मॉड्यूल्स की ज़रूरत है, उनके सबसे छोटे सेट की एक स्पष्ट अनुमत-सूची (allowlist) को प्राथमिकता दें।

5. `nesting: true` एक एस्केप हैच है

nesting: true सैंडबॉक्स कोड को require('vm2') करने और नेस्टेड NodeVM बनाने की अनुमति देता है। नेस्टेड VM का require कॉन्फ़िग उस सैंडबॉक्स कोड द्वारा चुना जाता है जो इसे बनाता है, न कि बाहरी VM द्वारा सीमित होता है। ठोस रूप से:```js const vm = new NodeVM({ nesting: true, require: { builtin: [] } }); vm.run( const { NodeVM: NVM } = require('vm2'); // Inner VM's config is whatever the sandbox writes here: const inner = new NVM({ require: { builtin: ['child_process'] } }); inner.run('require("child_process").execSync("id")'); // RCE);

यदि आप `nesting: true` सेट करते हैं, तो आपने प्रभावी रूप से सैंडबॉक्स को वही विश्वास स्तर प्रदान कर दिया है जो आपके पास है। **अविश्वसनीय कोड के लिए `nesting: true` सक्षम न करें।** इसका उपयोग केवल तभी करें जब आप सैंडबॉक्स किए गए कोड पर ही भरोसा करते हों, लेकिन गैर-सुरक्षा कारणों से VM-शैली निष्पादन सेमेन्टिक्स (नया global, नियंत्रित timeouts) चाहते हों।

`nesting: true` **एक स्पष्ट `require` कॉन्फ़िग ऑब्जेक्ट की आवश्यकता रखता है** (जैसे `require: { builtin: [] }` या `require: {}`)। कोई भी अन्य रूप — `require: false`, `require: undefined`, `require: null`, या `require` को पूरी तरह से छोड़ देना — निर्माण के समय `VMError` फेंकता है (GHSA-m4wx-m65x-ghrr, GHSA-8hg8-63c5-gwmx को प्रतिस्थापित करता है)। ये सभी रूप केवल NESTING_OVERRIDE रिज़ॉल्वर उत्पन्न करते हैं: सैंडबॉक्स `require('vm2')` कर सकता है लेकिन और कुछ नहीं, जो बिना किसी वैध उपयोग के एक शुद्ध escape प्रिमिटिव है। सभी require को अस्वीकार करने के लिए, `nesting: true` हटाएँ। नेस्टेड VM की अनुमति देने के लिए, एक स्पष्ट `require` कॉन्फ़िग प्रदान करें ताकि ट्रेड-ऑफ़ कॉल साइट पर दिखाई दे।

## ज्ञात समस्याएँ

-   किसी प्रॉक्सी की गई क्लास को विस्तारित (extend) करने वाली क्लास परिभाषित करना संभव नहीं है। इसमें `Object.create` में प्रॉक्सी की गई क्लास का उपयोग करना भी शामिल है।
-   Direct eval काम नहीं करता है।
-   सैंडबॉक्स arrays को लॉग करने पर properties में array भाग दोहराया जाएगा।
-   सोर्स कोड परिवर्तनों के परिणामस्वरूप किसी फ़ंक्शन के लिए एक अलग सोर्स स्ट्रिंग उत्पन्न हो सकती है।
-   सैंडबॉक्स के अंदर से node प्रक्रिया को क्रैश करने के तरीके मौजूद हैं। [हार्डनिंग अनुशंसाएँ](#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

isolated-vm	अलग V8 आइसोलेट्स (अलग V8 हीप)	तेज़	मेंटेनेंस मोड में; मैनुअल V8 अपडेट की आवश्यकता
अलग प्रोसेस / वर्कर	`child_process` या सीमित अनुमतियों वाले वर्कर थ्रेड	मध्यम	उच्च IPC ओवरहेड; डेटा को क्रमबद्ध (serialize) किया जाना चाहिए
कंटेनर / VM	Docker, gVisor, Firecracker	धीमा	स्टार्टअप ओवरहेड; संसाधन-भारी
प्रबंधित सेवाएँ	क्लाउड-आधारित कोड निष्पादन (जैसे, AWS Lambda, Cloudflare Workers)	परिवर्तनशील	नेटवर्क विलंबता; बाहरी निर्भरता

vm2

सबसे लोकप्रिय