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:
const Sandbox = require('sandbox');
const s = new Sandbox();
s.run('lol)hai', (output) => {
console.log(output);
//output='Syntax error'
});
// Example 4 - Restricted code
s.run('process.platform', (output) => {
console.log(output);
//output=Null
});
// Example 5 - Infinite loop
s.run('while (true) {}', (output) => {
console.log(output);
//output='Timeout'
});
경험상 자신의 JavaScript 파일만 실행해야 한다.
이론은 미뤄두고, 실제로는 런타임에 동적으로 전달되는 JavaScript 파일을 실행해야 한다.
예를 들어, 사용자 정의 로더를 허용하고 빌드 시간동안 동적으로 실행되는 webpack과 같은 프레임워크의 사용을 떠올려 보아라.
일부 악성 플러그인이 있는 경우 우리는 손상을 최소화하고 흐름이 성공적으로 종료되도록 하기를 원한다. 이를 위해서는 리소스, 충돌 및 공유된 정보의 측면에서 완전히 격리된 샌드박스 환경에서 플러그인을 실행해야 한다.
이런 격리를 실행하는데 도움이 될 수 있는 세 가지 주요 옵션은 다음과 같다:
const Sandbox = require('sandbox');
const s = new Sandbox();
s.run('lol)hai', (output) => {
console.log(output);
///output='Syntax error'/
});
/// 제한된 코드/
s.run('process.platform', (output) => {
console.log(output);
///output=Null/
});
/// 무한 루프/
s.run('while (true) {}', (output) => {
console.log(output);
///output='Timeout'/
});