JavaScript 沙箱探索

更新時間：2021年10月29日 10:03:15 作者：rxliuli blog

這篇文章主要介紹了JavaScript 沙箱探索，沙箱是基于 event bus 形式的通信實現(xiàn)上層的功能，文章的例子選擇接口實現(xiàn)了 web worker 與 quickjs 的 EventEmitter，,需要的朋友可以參考一下

1、場景

最近基于 web 在做一些類似于插件系統(tǒng)一樣的東西，所以折騰了一下 js 沙箱，以執(zhí)行第三方應(yīng)用的代碼。

2、沙箱基礎(chǔ)功能

在實現(xiàn)之前（好吧，其實是在調(diào)研了一些方案之后），確定了沙箱基于 event bus 形式的通信實現(xiàn)上層的功能，基礎(chǔ)的接口如下

export interface IEventEmitter {
  /**
   * 監(jiān)聽事件
   * @param channel
   * @param handle
   */
  on(channel: string, handle: (data: any) => void): void;

  /**
   * 取消監(jiān)聽
   * @param channel
   */
  offByChannel(channel: string): void;

  /**
   * 觸發(fā)事件
   * @param channel
   * @param data
   */
  emit(channel: string, data: any): void;
}

/**
 * 一個基本 js vm 的能力
 */
export interface IJavaScriptShadowbox extends IEventEmitter {
  /**
   * 執(zhí)行任意代碼
   * @param code
   */
  eval(code: string): void;

  /**
   * 銷毀實例
   */
  destroy(): void;
}

除了通信的能力之外，還額外要求了兩個方法：

eval: 執(zhí)行一段 js 代碼
destroy: 銷毀沙箱，供內(nèi)部實現(xiàn)處理一些清理任務(wù)

JavaScript 沙箱示意圖：

下面吾輩將分別演示使用 iframe/web worker/quickjs 執(zhí)行任意 js 的方法

3、iframe 實現(xiàn)

老實說，談到 web 中的沙箱，可能第一時間想到的就是 iframe 了，但它是以 html 作為入口文件，而非 js，這對于希望將 js 作為入口而不一定需要顯示 iframe 的場景而言就不甚友好了。

當(dāng)然可以將 js 代碼包裹到 html 中然后執(zhí)行

function evalByIframe(code: string) {
  const html = `<!DOCTYPE html><body><script>$[code]</script></body></html>`;
  const iframe = document.createElement("iframe");
  iframe.width = "0";
  iframe.height = "0";
  iframe.style.display = "none";
  document.body.appendChild(iframe);
  const blob = new Blob([html], { type: "text/html" });
  iframe.src = URL.createObjectURL(blob);
  return iframe;
}

evalByIframe(`
document.body.innerHTML = 'hello world'
console.log('location.href: ', location.href)
console.log('localStorage: ',localStorage)
`);

但 iframe 有以下幾個問題：

幾乎與 eval 沒有什么區(qū)別（主要是使用 Object.createObjectURL 導(dǎo)致同源了）– 致命的
可以訪問所有瀏覽器的 api – 我們更希望它僅能訪問注入的 api，而不允許訪問所有 dom api

4、web worker 實現(xiàn)

基本上，web worker 是一個受限的 js 運行時，以 js 為入口，和 iframe 差不多的通信機制

function evalByWebWorker(code: string) {
  const blob = new Blob([code], { type: "application/javascript" });
  const url = URL.createObjectURL(blob);
  return new Worker(url);
}

evalByWebWorker(`
console.log('location.href: ', location.href)
// console.log('localStorage: ', localStorage)
`);

但同時，它確實比 iframe 要更好一點

僅支持有限的瀏覽器 api，包括 localStorage/document 在內(nèi)的 api 均無法訪問，具體參考：[MDN] Web Workers 可以使用的函數(shù)和類
所有注入的 api 均為異步操作，畢竟基于 postMessage/onmessage

5、quickjs 實現(xiàn)

使用 quickjs 的主要靈感來源于figma 構(gòu)建插件系統(tǒng)的一篇博客，quickjs 中文文檔

quickjs 是什么？它是一個 JavaScript 的運行時，雖然我們最常用的運行時是瀏覽器和 nodejs，但也有許多其他的運行時，可以在 GoogleChromeLabs/jsvu 找到更多。而 quickjs 是其中一個輕量級、嵌入式、并且支持編譯為 wasm 運行在瀏覽器上的一個運行時，同時它對 js 的特性支持到 es2020（包括最喜愛的 Promise 和 async/await）。

async function evalByQuickJS(code: string) {
  const quickJS = await getQuickJS();
  const vm = quickJS.createVm();
  const res = vm.dump(vm.unwrapResult(vm.evalCode(code)));
  vm.dispose();
  return res;
}

 
console.log(await evalByQuickJS(`1+1`));

優(yōu)點：

事實上，在安全性方面它是無可匹敵的，因為運行在不同的 vm 上，很難出現(xiàn)現(xiàn)有微前端基于 Proxy 可能出現(xiàn)的安全問題。
雖然沒有實際測試，但 figma 的那篇博客中指出瀏覽器的結(jié)構(gòu)化克隆在處理大型對象時存在性能問題，而 quickjs 不存在這種問題。

缺點：

沒有全局 api，包括常見的 console/setTimeout/setInterval 都不是 js 的特性，而是瀏覽器、nodejs 運行時實現(xiàn)的，所以必須手動實現(xiàn)并注入，這是一個顯著的缺點。
無法使用瀏覽器的 DevTool 調(diào)試
由于底層使用 c 實現(xiàn)，所以需要手動管理內(nèi)存的釋放