JavaScript非常强大，而且浏览器无疑会运行给出的所有JavaScript代码似乎很奇怪。这样安全吗？
#1 楼
该标准旨在确保安全。实现可能不是。浏览器隔离JavaScript，因为它在浏览器进程内部执行。它无法执行浏览器JavaScript解释器或JIT编译器不允许的任何操作。但是，由于其复杂性，发现漏洞并非罕见，这些漏洞使JavaScript可以危害浏览器并利用浏览器进程的特权获得任意代码执行的权限。
因为这些类型的安全性错误非常普遍，许多浏览器都会实现沙箱。这是一种保护机制，试图隔离受感染的浏览器进程并防止其造成进一步的危害。沙盒的工作方式取决于浏览器。 Firefox的沙箱非常有限，而Chrome和Edge的沙箱却很多。但是，尽管进行了深度防御，但浏览器漏洞通常可以与沙箱转义漏洞结合在一起。
评论
正是这一点：Javascript本身并不是“不安全的”（就损害PC而言-对于Web应用程序，Javascript可能是一个很大的挑战）。问题是，浏览器的复杂性，功能和纯尺寸的增长是巨大的-几年之内，浏览器已经从简单的html显示工具发展为类似OS的软件。因此，很可能浏览器中始终存在漏洞，并且可以通过Javascript加以利用。另一点：插件。由“某人”撰写，但被浏览器嘲笑，因此您有更多的漏洞可以利用。
– Alex
18年11月30日在7:06
@forest操作系统提供的沙箱和浏览器提供的沙箱之间是有区别的。第一个可以被浏览器利用。但是如果是操作系统沙箱，例如提供对FAT32分区上任何文件的访问权，但这并不意味着浏览器将允许JS读取它。例如。 firefox仍将在受限环境中运行JS，但是它可能不使用操作系统提供（附加）保护。
–马滕·博德威斯（Maarten Bodewes）
18-11-30在7:15
“ Firefox的沙箱非常有限，而Chrome和Edge的沙箱非常多”：有趣的是，我想对此有所了解。例如，此答案相反。你有资料吗？还是我应该问另一个问题？
–法比奥说恢复莫妮卡
18年11月30日在22:15
@FabioTurati该答案不正确。他们所说的Firefox中的沙箱旨在防止单个崩溃选项卡使整个浏览器崩溃，而不是孤立妥协。例如，Chrome / Chromium将GPU沙盒化，而Firefox没有（最后一次检查）。 Firefox（在* nix上）将jemalloc与4个MiB堆配合使用，这使堆喷射攻击更容易禁用ASLR，而Chromium则不然。 Firefox的PresArena也不及Chromium的PartitionAlloc。 Firefox已经对其进行了测试，而Chromium正在CFI上工作，并且有数百个内核对其进行24/7模糊测试。
–森林
18/12/1在2:19
还要注意，尽管浏览器内部的JavaScript总是图灵完备的语言，但它始终可能是“恶意的”并且可以执行“恶意的事情”。但是，这取决于您如何定义“恶意”。它可以例如轻松打开弹出窗口（“广告软件”）或在浏览器窗口内显示类似的项目。恶意JS如果通过广告（例如，当然，JS从浏览器中“爆发”是另一种“恶意”的方式。
–地毯
18/12/2在18:53
#2 楼
安全吗？
不是。更确切地说，它与浏览器实现一样安全。浏览器（包括其JavaScript引擎）是复杂的软件，需要定期添加新功能-因为用户需要它们。
这意味着，即使知名的浏览器肯定具有质量测试程序，针对已知漏洞的代码，在实现功能时始终存在未被发现的缺陷的风险。
当前，公认的方式是，一旦检测到违规，就会发布包含修复程序的新版本。但是，在发现漏洞和安装补丁之间，浏览器容易受到攻击，这就是为什么建议保持浏览器为最新版本以便仅暴露零日漏洞的原因。
评论
好吧……“没有什么是百分百安全的”。这样，您可以回答“不是”。一切。考虑到实践/现实方面，OP确实希望得到一个答案。你这样做更不用说沙箱和浏览器内置的其他功能很长时间了。
–地毯
18/12/2在18:45
@rugk：沙箱只是用来保护系统免受恶意代码攻击的工具，它非常有效……直到攻击者发现漏洞！这就是为什么我宁愿坚持使浏览器保持最新状态，而不是使用各种用于保护它的工具来保持更新的原因。
– Serge Ballesta
18/12/2在22:56
#3 楼
确实，在JavaScript级别上，浏览器旨在将正在执行的代码沙盒化（主要是通过不公开任何危险的API），但是JavaScript是一种非常复杂的语言，可以解析和执行。ECMAScript是JavaScript背后的标准，由于围绕我们今天遇到的对初学者友好的编程语言的巨大市场膨胀，ECMAScript正在快速更新，并引入了越来越复杂的功能以实现运行时。反过来，这又扩大了攻击的范围并允许错误蔓延。
一个很好的例子是Patrick Biernat，Markus Gaasedelen和Amy Burnett在pwn2own 2018上所做的最新工作。
http://blog.ret2.io/2018/06/05/pwn2own-2018-exploit-development/
博客描述了0day的发现，该代码允许在其中执行任意代码WebKit以及如何利用它在macOS窗口管理器中再利用0day来逃避sanbox，而Safari正在其中运行（这是macOS沙箱，而不是Safari的沙箱）以升级为“ root”并拥有系统。
长话简而言之，通过在启用JavaScript的情况下仅访问链接，就可以完全破坏macOS系统，而无需单个glitc对用户可见。
这就是JavaScript的安全性：与WebKit的JSCore一样安全的复杂软件。
这就是为什么建议要求高安全性的用户禁用JavaScript的原因（例如，在DarkWeb中，这是相当普遍的要求。反转时可能导致UAF（免费使用）漏洞。
标记是在阵列上顺序进行的，假设反向旋转时GC恰好位于阵列的中间，那么后半部分将永远不会被标记，因此被选为收集对象，从而产生UAF（未收集阵列对象本身，仅其元素）。
如何使用UAF来制作更强大的利用原语，从而导致任意代码执行，或多或少是相同技术的变体：首先在新释放的空间中分配一个有趣的对象（例如一个数组），然后创建一个RW原语（例如，通过更改数组的边界），最后将任意操作码写入内存中（例如，在JITted页面中）。
关于此特定0day的详细信息，请参见链接的博客。 。
有趣的部分是0day的发现方式：由于WebKit太大，如果不付出大量努力就无法进行深入的代码审查，因此自动抖动已建立。必须使我们反思这样一个事实，当我们有数十万或数百万行代码时，很难使每一行相对于每一行都表现良好。
评论
错字：“免费使用后使用”，而不是“免费使用后使用”。
–大卫·康拉德（David Conrad）
18/12/3在19:23
苹果公司的家伙真的不喜欢Array.reverse（）...
– Adriano Repetti
18/12/5在9:17
#4 楼
如其他答案所述，每个浏览器都有其自己的脚本引擎，该脚本引擎旨在沙盒化JavaScript执行，并且每个引擎都试图限制可能导致恶意行为的JavaScript功能。但是通常来说，JavaScript在浏览器中从来都不是安全的。恶意代码开发人员一直在寻找方法来利用每个引擎的工作方式及其可用的JavaScript功能来实现恶意目标。现在，这是恶意代码开发人员与浏览器/引擎开发人员之间的不间断竞赛，最终，即使只是很短的时间，恶意开发人员也总是会获胜。因此，很难将JavaScript称为安全的。 “现在应该安全”是一种更准确的说法。
#5 楼
JavaScript非常强大。
，这就是为什么许多用户认为它不安全并使用浏览器扩展来阻止它的原因。 JavaScript允许网站以无法追踪的方式跟踪用户，包括使用指纹识别器删除用户的cookie后识别用户。许多较新的Web API（例如WebUSB）允许一些根本不安全的事物，但是浏览器在访问不安全的API（例如USB和相机）时会请求用户权限。
评论
究竟！这就是为什么我将NoScript用于Firefox。有多年了。
–迈克·沃特斯
18/12/3在22:54
我相信所有浏览器在允许网站访问麦克风，摄像头，GPS之前都会询问...
–好奇
18/12/18在6:19
@curiousguy仍然有大量不需要权限的JS API，可以结合使用以识别您的身份，例如电池API
– Qwertie
18/12/18在23:11
@Qwertie是的，Mozilla FF团队只是声称具有隐私意识。他们提供了一种很简单的方法来检查链接是否被访问：即使没有JS也可以使用多年。他们只是不在乎！
–好奇
18/12/18在23:37
#6 楼
JavaScript本质上并没有什么安全性，在许多方面都比其他语言更不安全：沙箱，浏览器将在其中执行提供安全性的JavaScript。请在此处查看Chrome沙箱上的文档，请注意，这里没有引用JavaScript或ECMA脚本。如今，浏览器中执行的大部分代码都是用JavaScript编写的。随着WebAssembly的兴起，我们可能会看到浏览器平台从当今的单一语言锁定（如过去的大型机）切换到可以使用任何WebAssembly兼容语言的开放平台。在某种程度上，这将证明JavaScript不是特别安全/特殊，因为届时许多语言将在浏览器中执行。所有这些语言都将使用浏览器提供的沙箱执行。
评论
在这种情况下，eval语句并不会真正降低安全性。当攻击者能够将未经过滤的字符串传递给它时，Eval构成了威胁，从而使他们可以在目标系统上运行任意代码。在这种情况下，攻击者是编写Javascript的人，而目标系统是运行Java的浏览器。攻击者已经在目标系统上运行任意代码，问题是沙盒的安全性。
–雷
18/12/4在0:16
#7 楼
与计算机级别的可执行代码（如ActiveX所用）相比，它是安全的。机器代码程序具有对操作系统和库提供给以该用户帐户运行的任何程序的任何接口的访问权限，该操作实际上受硬件和操作系统的限制而受到严格限制它实际上-使这种程序与运行它的用户一样强大。可能有一些工具会尝试通过截取所提供的某些接口来限制它，但是很难阻止程序意识到此类措施来规避它们。并以仅提供正在运行接口的程序并希望提供接口的功能来编写。
评论
但是JavaScript可以被编译并作为机器代码运行。实际上通常是这样。
–森林
18/12/3在7:16
使用由USER（而不是DEVELOPER）控制的编译器。
–rackandboneman
18/12/3在9:11
的确，JIT编译器确实限制了它可以吐出的字节码。
–森林
18/12/3在9:15
#8 楼
JavaScript是“相对安全的”，但不是“绝对安全的”。您在系统上运行的任何代码都可能造成危害。除了从未使用过的系统之外，没有完全安全的系统。 JavaScript比将未知的USB设备放入计算机更安全，比从黑幕网站下载或获取可疑电子邮件附件的二进制文件更安全，并且比告诉您执行以下操作的网站上的某些脚本更安全将它们复制并粘贴到您的外壳中。它具有安全功能：沙箱可帮助隔离进程，相对有限的API具有安全约束，可避免运行任意计算机指令，并且安全控制意味着限制敏感数据（例如指纹或跨域数据共享）的暴露。这些位于操作系统的控件之上，这些控件已应用于浏览器二进制文件，以限制不良行为，以及防病毒应用程序可以帮助阻止此类攻击。
但这并不是绝对安全的。浏览器的运行时引擎，浏览器本身，防病毒甚至处理器本身中的错误都可能危害JavaScript的安全性。该系统的安全性只有其最弱的安全性。 JavaScript的安全性主要是为了防止“偶然的”漏洞利用（例如8岁的人第一次学习JavaScript并意外编写漏洞利用），但是对于专门的攻击者却没有机会。 JavaScript非常复杂，可能会以怪异的和出乎意料的方式存在错误。并尽其所能尝试寻找装甲中的短处。 JavaScript实现的弱点。 JavaScript足够大，以至于存在这样的问题，因为实际上甚至不可能自动化所有可能发现这些bug的测试。
一般而言，您可能在典型网站上运行的任何典型脚本都可能是“安全的”，尤其是那些由主要搜索引擎链接的脚本。但是，一旦您走开了人迹罕至的道路，即使有一个弱点，也很有可能在某个时候使您的系统受到损害。完全接管系统只需要一个非常好的漏洞，有时甚至是串联两个或三个即可。 ），请始终使您的所有软件保持最新，并始终注意浏览器警告，例如无效证书等。即使那样，您也不是100％安全的，但是您将积极参与自己的缓解策略。
#9 楼
此答案将解决问题中提出的两点，以及问题中未提出的一个浏览器“功能”。在定义
requestFileSystem且直接写入磁盘的Chromium / Chrome浏览器中，这种限制在技术上不存在。即用户文件系统中Chromium / Chrome配置目录的File System文件夹。 请参阅如何使用JavaScript在文件（用户目录）中进行写入？
不允许访问其他浏览器窗口或域。
如果从已经打开的
window打开了window，则window之间的通信可以使用，包括但不限于postMessage，MessageChannel，SharedWorker或仅查询字符串参数。请参阅如何使用用户脚本加载共享的Web worker？
在OP中未提及的另一点必须在此处针对Chromium / Chrome提出：在这些浏览器中，Web Speech API的
SpeechRecognition实现会记录用户的语音（生物识别码），并将该记录发送到远程服务，而无需直接通知用户正在发生的事情。目前尚不清楚录音是由未公开的“ Web服务”永久保留还是在某些时候被“删除”。默认情况下？#10 楼
这是安全的，因为它被设计为安全的。或者至少在某种程度上是安全的，这比不正式的“ JavaScript强大”确实表明它可能足够安全，可以使您放心。在实践中，没有一款软件是绝对安全的，这取决于程度。 Javascript非常安全，大多数公司都愿意让员工使用公司的硬件访问网站。JavaScript旨在防止攻击者访问您的文件或任何私人信息。例如，它具有阻止一个站点上的脚本查看来自另一个站点的数据的支持（称为跨站点攻击）。
当然，这并不完美。最近Spectre和Meltdown引起了恐慌，这是一对利用某些处理器中的漏洞来摆脱运行JavaScript的沙箱的漏洞。必须用一些相当丑陋的软件黑客来修补漏洞处理器。
但是一般来说，执行这样的脚本是“安全的”，因为许多安全专家花费了大量时间来确保安全感是合理的。但这完全取决于您的威胁模型。如果您有数十亿美元的资产，您甚至可能都不希望相信JavaScript的安全性！
所以真正的问题是，您对“安全性”的要求是什么？您认为Windows安全吗？ Internet Explorer呢？ Adobe Acrobat Reader？ OpenJPEG？ Linux内核？ OpenSSL的？安全性和可用性总是矛盾的。您必须使用某些东西（或也许不用。除非已计算出新的流感种类，否则Amish尚未受到0天的打击）要真正理解您是否可以称其为“安全”或您不需要威胁模型，定义某人可能如何攻击您的模型，也不需要可用性模型来定义缓解威胁模型时需要实现的可用性。没有这些，我们必须阅读您的文字和历史，以猜测“安全”的含义。
评论
致低级投票者：对于您为什么认为此正确答案应被低级投票的解释，将不胜感激。
–Cort Ammon
18/12/2在17:37
我之所以投票，是因为您高估了JavaScript的安全性，尤其是当需要使用每个新版本的新浏览器来修复JS引擎中许多新发现的漏洞时，尤其如此。可以在某些国家/地区以3万美元左右的价格购买JS漏洞的事实表明，过于乐观地认为它是如此的安全，以至于需要花费十亿美元的资产才能将其破坏。您最初认为JavaScript是“安全的”，因为它被设计为安全的，这是不正确的。
–森林
18/12/3在3:16
我之所以投票，是因为它以肯定的陈述“ It's Safe”开头，这是不正确的。继续指出，这只是相对安全的。
–本
18/12/3在11:54
@Ben谢谢。这解释了很多。我添加了一些文字来指出为什么我称其为“安全”，这与OP绘制时所显示的栏有关。
–Cort Ammon
18/12/3在16:10
评论
评论不作进一步讨论；此对话已移至聊天。