多线程 javascript 的安全隐患答案

【问题标题】：Security implications of multi-threaded javascript多线程 javascript 的安全隐患
【发布时间】：2010-09-07 14:05:21
【问题描述】：

阅读多线程 javascript 上的 this question，我想知道允许 javascript 产生多线程是否会产生任何安全隐患。例如，是否存在恶意脚本反复生成线程以试图压倒操作系统或解释器并触发进入“未定义行为领域”的风险，或者这几乎不是问题？攻击可能会利用支持非线程实现免疫的线程的假设 javascript 实现的任何其他方式？

更新：请注意，锁定浏览器与创建未定义行为漏洞利用不同。

【问题讨论】：

标签： javascript multithreading

【解决方案1】：

不，多线程不会在完美的实现中增加额外的安全问题。线程化的 javascript 会增加 javascript 解释器的复杂性，使其更有可能存在可利用的错误。但是单独的线程不会增加任何安全问题。

线程在 javascript 中不存在，因为“线程糟透了” - 阅读更多来自语言设计器 (http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html)

【讨论】：

【解决方案2】：

好吧，您已经可以锁定浏览器并严重拖慢运行不良 JS 的系统。开明的浏览器已经对这类事情实施了检查，并且会在它失控之前阻止它。

我倾向于假设线程将以类似的方式处理。

也许您可以解释一下“未定义的行为”是什么意思？允许不受信任的脚本直接控制正在运行的操作系统原生线程的数量的解释器将是难以置信天真 - 我不知道 Gears 是如何运行的，但由于API 以WorkerPools 中的Workers 为中心，如果它们不将使用的本机线程总数限制在非常低的数量，我会感到非常惊讶。

【讨论】：

【解决方案3】：

好吧，我认为多线程 javascript 的唯一主要示例是 Google 的 chrome（他们是否会发布它已经 JEEZ），如果我理解它，javascript 将每个选项卡只有一个进程，所以除非它开始生成选项卡（弹出窗口）我会假设这将是一个空问题，但我认为谷歌无论如何都有这个问题，它们在沙箱中运行所有 javascript。

【讨论】：

【解决方案4】：

再次，我们需要区分 1) 语言中的多线程支持（我认为不会认真讨论这种情况）和 2) 在 JavaScript 引擎/解释器中使用多线程浏览器。

对于 #2，我看不出这会如何真正为引擎/解释器添加任何可能的安全问题，除非实现中存在缺陷。

【讨论】：