如何在不使用 VM、转译器或基于白名单的 API 的情况下对用户 JS 进行沙箱处理?

信息安全 xss javascript 沙盒
2021-08-24 14:03:21

我已经完成了我的研究,并且有一些强大的沙箱用户 JS 方法,即:

  • 使用 JS VM,该 VM 使用沙盒形式的 js 运行 JS,例如VM.js
  • 使用像 Google Caja 这样的编译器,它添加了额外的检查来保留某些不变量并禁止特定的代码路径
  • 使用跨域(和/或sandboxed)iframe,也可能与 WebWorker 一起使用,例如Jailed

不幸的是,这些都不适用于我的应用程序。我正在尝试构建一个 jsperf.com 替代方案(即基于 Web 的 JS 基准测试系统),因此前两个已退出,因为它们会影响用户提供的代码的性能,这会使任何基准测试结果完全无效。

Jailed 更接近,但也不是一个很好的选择,因为 A) 它的仅白名单方法非常严格,以至于我的网站无法测试 Web 的许多功能(DOM 操作、IndexedDb、WebWorkers、LocalStorage、等等)没有很多我什至不确定是否会工作的白名单,并且 B)我不确定它的维护(因此安全)有多好(因此安全),因为它的 GitHub 存储库上的活动很少。

什么是我可以安全地用来执行用户提供的 JS 进行基准测试的最宽松的系统(就接近运行非沙盒而言)?沙盒是否iframe足以让基准测试至少可以访问一些DOM 和其他 Web API?WebWorker 真的有必要吗?jsfiddle之类的有什么作用?

1个回答

沙盒的软件工程定义是具有特定安全约束的执行环境。这意味着用户 JavaScript 不应该能够利用或影响包含网页的 JavaScript。

iframe 实现既不会

  • 保证沙盒代码运行时条件与在独立文档中运行时相同,也不
  • 确保父文档不会受到沙盒代码的影响甚至可能崩溃。

如果您有足够的网络和 Web 服务器控制,则可以通过允许经过身份验证的用户通过 HTTPS 向完全独立的辅助站点或站点提供沙盒 JavaScript 来建立相当安全的独立性和真实的执行环境。使用子域可以降低这种方法的成本。您可能不得不使用一些人认为违反 www 模型的 target='_blank' hack。

为了小心不要使用这种安排造成安全漏洞,有一些建议。

  • 使用精确获取沙盒代码的服务器端包含。
  • 小心收紧所有 Web 服务器目录访问。
  • 验证 JavaScript 的语法。