mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-31 17:47:26 +08:00
5f27dcdd24
* translated lint rules * translated limit requests * translated secret management * translated ORM ODM usage * translated secure server * translated commum security best pratices * translated secure headers * translated dependency security * translated bcrypt passwords * translated escape output * translated validation * translated expire jwt * translated login rate limit * translated non root user * translated request payload size limit * translated avoid eval * translated regex * translated safe module loading * translated sandbox * translated child processes * translated hide errors * translated sessions * translated safe redirects * changed links to tranlated files & fixed a typo * translated ESlint and Prettier * translated native over util * translated refactoring * translated ci tools * translated 3 parts in name * translated monitoring * translated smart logging * translated delegate to proxy * translated lock dependencies * translated guard process * translated utilize cpu * translated create maintenance endpoint * translated apm products * translated production code * translated measure memory * translated frontend out * translated be stateless * translated detect vulnerabilities * translated assign transation ID * translated set NODE_ENV * translated LTS release * translated log rounting * translated break into components * translated create layers * translated wrap utilities * translated separate express * translated config guide * corrected typos and updated anchors * corrected files names
34 lines
1.8 KiB
Markdown
34 lines
1.8 KiB
Markdown
# Run unsafe code in a sandbox
|
|
|
|
### One Paragraph Explainer
|
|
|
|
As a rule of thumb, one should run his own JavaScript files only. Theories aside, real-world scenarios demand to execute JavaScript files that are being passed dynamically at run-time. For example, consider a dynamic framework like webpack that accepts custom loaders and execute those dynamically during build time. In the existence of some malicious plugin we wish to minimize the damage and maybe even let the flow terminate successfully - this requires to run the plugins in a sandbox environment that is fully isolated in terms of resources, crashes and the information we share with it. Three main options can help in achieving this isolation:
|
|
|
|
- a dedicated child process - this provides a quick information isolation but demand to tame the child process, limit its execution time and recover from errors
|
|
- a cloud serverless framework ticks all the sandbox requirements but deployment and invoking a FaaS function dynamically is not a walk in the park
|
|
- some npm libraries, like [sandbox](https://www.npmjs.com/package/sandbox) and [vm2](https://www.npmjs.com/package/vm2) allow execution of isolated code in 1 single line of code. Though this latter option wins in simplicity it provides a limited protection
|
|
|
|
### Code example - Using Sandbox library to run code in isolation
|
|
|
|
```javascript
|
|
const Sandbox = require("sandbox")
|
|
, s = new Sandbox()
|
|
|
|
s.run( "lol)hai", function( output ) {
|
|
console.log(output);
|
|
//output='Synatx error'
|
|
});
|
|
|
|
// Example 4 - Restricted code
|
|
s.run( "process.platform", function( output ) {
|
|
console.log(output);
|
|
//output=Null
|
|
})
|
|
|
|
// Example 5 - Infinite loop
|
|
s.run( "while (true) {}", function( output ) {
|
|
console.log(output);
|
|
//output='Timeout'
|
|
})
|
|
```
|