我很难让我的本地文件可以从 Chrome 访问 javascript（用于在新窗口中打开），并且已经在 Firefox 中找到了解决方法。我的问题是：为什么javascriptwindow.open默认无法在新的浏览器窗口（带有）中打开文件？我看不到任何安全问题。
我在这个主题上到处都读到的唯一内容是：“网站不应该访问我的磁盘来读取文件。” 但是由于Same-origin policy，javascript实际上不可能读取文件的内容。您可以按如下方式对其进行测试。
例如，在NoScript的设置中，您可以选择 Advanced->Trusted 并标记“允许本地链接”。现在打开 Firefox 控制台并执行（你应该允许弹出窗口）：
x = window.open('file:///%some_path_to_text_file%')
x.document
我收到“错误：访问属性“文档”的权限被拒绝[了解更多] ”。那么，有什么关系呢？在 NoScript 中始终保留“允许本地链接”选项是否安全？
这是一个合理的问题，因为仅仅打开任意文件 URL 就如同读取任意文件 URL 是不好的一样，这并不是很明显。这是简短的答案：
这些是让站点链接到本地文件造成的漏洞：
A1。如果浏览器或任何帮助应用程序（例如 RealPlayer）将不受信任的文件放在可预测的位置，则任何页面都可以链接到该文件，从而读取硬盘上的每个文件。
A2。同源策略（跨域）中的漏洞成为读取硬盘驱动器上的任何文件的漏洞。
但同源漏洞已经被认为严重到足以阻止发布（它们让网站窃取 cookie、密码和 Intranet Web 服务器上的信息）。
A3。使用 file:///con/con 或 /dev/stuff 对浏览器甚至操作系统进行 DoS 攻击。
https://bugzilla.mozilla.org/show_bug.cgi?id=84128#c190
这些问题在今天仍然存在，例如 Firefox for Android 中的 2017 漏洞利用允许恶意网站从/sdcard/Download/(CVE-2017-7759) 读取文件。
提供给 Firefox for Android 的 Android 意图 URL 可用于从 HTTP 或 HTTPS URL 导航到本地“文件：” URL，从而允许通过违反同源策略读取本地数据。
https://nvd.nist.gov/vuln/detail/CVE-2017-7759
重现步骤：
访问远程 (http) 网页：
<script> location="intent:file:///(path)#Intent;type=text/html;end"; </script>实际结果：
上面的 JS 代码将用户重定向到 file: URL。
重定向允许远程页面泄露 /sdcard/Download/ 中的文件。
https://bugzilla.mozilla.org/show_bug.cgi?id=1356893
浏览器安全手册很好地解释了更一般的理由：
在 的情况下
file:，网站通常根本无法导航到本地资源。对此决定给出的三种解释如下：
许多浏览器和浏览器插件将它们的临时文件和缓存数据保存在磁盘上可预测的位置。攻击者可以在正常浏览活动期间首先在这些位置植入一个 HTML 文件，然后尝试通过调用精心制作的
file:///URL 来打开它。如前所述，许多同源策略的实现都渴望赋予本地 HTML 文档（更多）特殊权限，因此这导致了频繁的麻烦。用户对在容器中打开本地、敏感文件、目录或应用程序的随机、不受信任的站点感到不舒服
<IFRAME>，即使嵌入它们的网页在技术上无法读回数据——这是普通用户无法验证的属性。最后，诸如
<SCRIPT>或之类的标签<LINK REL="stylesheet" HREF="...">可用于从磁盘读回某些受约束格式的本地文件，并从跨域脚本中访问数据。虽然没有证明这种类型的特别有用和普遍的攻击，但这构成了潜在的风险。
https://code.google.com/archive/p/browsersec/wikis/Part2.wiki
因此，浏览器尽最大努力执行同源策略，但并不总是成功，正如 Firefox for Android 漏洞和更普遍的XSS 漏洞的存在所证明的那样。
此外，由于缓存文件，远程文件可以拥有真实的file://URL。浏览器会小心地使配置文件和缓存文件名不可预测，但只需要一个位于已知位置的不受信任的文件，游戏就结束了。即使恶意远程 Javascript 无法直接访问文件系统，它也会影响缓存文件和 cookie。
如果有人可以将文件下载到您的计算机（在缓存文件中，或者通过用户同意将其下载到已知目录），并且下载的文件包含 JS，则通过文件引用它：恶意网页会导致 JS 运行，并且由于它来自本地驱动器，因此它将以特权运行。
https://bugzilla.mozilla.org/show_bug.cgi?id=40538
如果攻击者可以将内容放置在用户的硬盘上，例如通过设置 cookie、填充缓存等，并且可以使该内容在浏览器中执行，那么该内容可以将信息传回给攻击者， 不管怎样。
https://bugzilla.mozilla.org/show_bug.cgi?id=101207
file://还值得一问： URL的“同源”应该是什么意思？它应该只是该文件的目录及其子目录，还是应该是整个文件系统？
在 Gecko 1.8 或更早版本中，任何两个
file:URI 都被认为是同源的。换句话说，本地磁盘上的任何 HTML 文件都可以读取本地磁盘上的任何其他文件。从 Gecko 1.9 开始，文件只能读取某些其他文件。具体来说，一个文件只有在源文件的父目录是目标文件的祖先目录时才能读取另一个文件。但是，不能以这种方式加载目录。
https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs
最后，请注意，能够指示浏览器加载文件的恶意脚本即使没有读取文件的能力也会造成危害。加载任意file://URL 可用于使浏览器崩溃或干扰键盘输入。
并非所有 URI 加载都是安全的。例如，加载一些文件：URI 可能会导致浏览器挂起，甚至在某些情况下会导致操作系统崩溃。
https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Safely_loading_URIs
服务器不需要能够读取加载结果来造成损坏。在某些 Win98 系统上，加载
file:///C:/con/con会导致崩溃和数据丢失。类似的结果可能来自file:///dev/*在 Unix 上访问某些东西，我相信 Mac 上也存在类似的问题。
https://bugzilla.mozilla.org/show_bug.cgi?id=101207
以下 HTML 将导致 Mozilla（和 Netscape 4.77）打开 /dev/tty0，这将导致 /dev/tty0 的所有键盘输入被吃掉：
<img src="file:///dev/tty0">我建议 Mozilla 永远不要在通过文件以外的其他方式（http、https、ftp 等）加载内容时尝试打开文件 URI。
https://bugzilla.mozilla.org/show_bug.cgi?id=91316
例如，在 Unix 系统上，单击类似的链接
<A HREF="file:///dev/zero">将导致浏览器开始写入一个无限大的零文件。Windows 上也有类似的问题。
https://bugzilla.mozilla.org/show_bug.cgi?id=47988
所以，总结一下：
本地文件比远程文件具有更大的权限，因此允许远程 Javascript 打开本地 Javascript 可以允许权限提升。
浏览器并不总是完美地执行同源策略，如果所有file://URL 都被认为具有相同的来源，同源策略中的错误可能允许任意文件访问。
某些file://URL 仅通过允许浏览器打开它们就可能导致恶意影响。
相关问题：
如果浏览器能够从计算机打开文件，我可以看到恶意行为者将浏览器漏洞利用有效负载下载到用户的计算机，然后让 js 打开该文件利用浏览器中的某些内容。
在这种情况下，攻击者必须对用户的浏览器进行利用，从而攻击浏览器读取文件的方式。这些漏洞利用相当普遍。
攻击者也有可能将文件下载到用户的计算机，然后使用它的系统级上下文来抓取其他文件并通过将它们嵌入到图像的 src 中来泄露它们（我以前使用过这个）。但我不能 100% 确定在浏览器中从本地运行的文件是否可以访问其他文件，也许其他人可以对此感兴趣，或者如果我有一些额外的时间，我会建立一个概念证明。
在大多数情况下，将互联网内容与本地内容混合并不是一个好主意。