我从没想过，有一天我用来看天气的浏览器标签页，竟然也可能成为“扣押”我照片的工具。

但事实就是这样。

这不是一个所谓的 0day 漏洞故事。

没有黑客利用未知漏洞入侵系统，没有偷偷安装的 .exe 文件，也没有一个等待修复的 CVE。

浏览器按照设计工作，API 按照官方说明运行，而我也像一个谨慎用户一样点击了“允许”。

整个攻击链，就这样完成了。

---

那一行代码，竟然真的存在

2026 年 7 月，Check Point Research 发布了一份非常特别的安全分析报告。

他们研究了大约 3000 个归属于 DeepSeek 的文件，其中约 1383 个被发现存在恶意或危险行为。

其中一个样本，是作者上传到 VirusTotal 的 Python Flask 应用，名字叫：

InfernoGrabber v9.0。

有意思的是，大部分内容其实很荒谬。

它像极了 AI 根据一份混乱的“恶意软件需求清单”生成出来的产物：

不存在的功能；

互相矛盾的逻辑；

完全虚构的能力。

就像很多人遇到过的情况：

AI 一本正经地引用一个根本不存在的库。

只不过这一次，它是在生成恶意软件。

然而，在大量错误内容中，有一行代码并不是幻想。

它指向了一个真实存在的能力：

浏览器访问用户本地文件和照片目录。

听起来像 AI 编造出来的漏洞。

但问题是：

这个能力真的存在。

Chromium 浏览器中的 File System Access API，正是为了让网页拥有经过授权的文件访问能力而设计的。

它可以做到 AI 描述中的事情。

---

​这个 API 到底做了什么？

现代网页应用确实有时候需要访问本地文件。

比如：

在线代码编辑器；

图片处理工具；

设计软件。

这些应用希望直接保存修改后的文件，而不是每次都重新下载一个副本。

在这个 API 出现之前：

网页可以读取用户主动上传的文件。

但是不能直接写回你的硬盘。

对于很多正规应用来说，这是一个真实存在的不方便。

所以 Chromium 提供了：

showDirectoryPicker()

以及相关接口。

流程很简单：

你选择一个文件夹；

你授权访问；

网页获得这个文件夹的操作权限。

包括读取。

以及，在授权范围内写入。

问题就在这里。

这个能力并不隐藏。

甚至 File System Access API 的设计文档，本身就考虑过勒索软件风险。

早在 2023 年，USENIX 的论文《RoB: Ransomware over Modern Web Browsers》就研究过类似攻击方式。

设计者知道这扇门可能被利用。

他们依靠的是：

权限弹窗。

以及用户理解自己点击了什么。

但现实是：

很多人并没有真正理解。

我亲自做了一次实验

我不想只看别人分析。

所以我决定自己测试一下边界。

当然，我没有制作真正的攻击程序。

我做的是一个最简单、最无害的版本：

一个网页请求文件夹权限，然后告诉我：

它能看到什么。

它能操作什么。

没有加密。

没有上传。

没有勒索信息。

只是观察权限模型到底在哪里。

我创建了一个测试目录：

~/ransomware-test

里面放了一些无害文件。

然后打开浏览器控制台，执行代码。

第一步：

请求文件夹权限。

const dir = await window.showDirectoryPicker({ 
  mode: "readwrite" 
});

console.log("Got a handle to:", dir.name);

结果非常直接。

浏览器弹出了授权窗口。

我选择测试文件夹。

点击允许。

就这样。

一次点击。

网页获得了这个文件夹的读写权限。

---

第二步：看看它能看到什么

随后，我让网页遍历这个目录。

结果：

所有文件都被列出来。

包括：

文件名；

大小；

子目录。

它并不是猜。

也不是暴力搜索。

它拥有的，是类似本地程序一样的目录视图。

这一刻，抽象风险变成了现实。

---

第三步：证明它真的可以修改文件

这里是整个实验最关键的地方。

我没有进行加密。

因为所谓勒索软件，本质上就是：

读取文件。

加密内容。

覆盖原文件。

所以为了证明写入能力，我只修改了一个测试文件。

代码类似：

const handle = await dir.getFileHandle("decoy-01.txt");

const writable = await handle.createWritable();

await writable.write(
  "this file was modified by a web page in a browser tab\n"
);

await writable.close();

然后重新打开文件。

结果：

原来的内容消失。

新的文本出现。

没有第二次确认。

没有针对这个文件的提醒。

因为第一次授权已经包含写入权限。

这就是整个机制。

遍历。

读取。

覆盖。

真正的勒索软件，只需要把普通写入操作换成：

读取文件内容；

使用密钥加密；

写回密文；

弹出付款页面。

两者之间的区别，可能只有几行代码。

最可怕的地方，不是漏洞

很多人的第一反应是：

“那就关闭这个 API。”

但真正值得关注的，并不是某个具体功能。

而是一种越来越常见的安全模式。

这里没有东西坏掉。

权限提示正常。

浏览器沙箱正常。

Chromium 的路径限制也正常。

网页不能偷偷访问整个硬盘。

它只能访问你主动授权的内容。

真正的问题是：

用户理解中的“允许”，和实际授予的权限之间，存在巨大差距。

你以为：

“我只是让图片网站读取我的照片。”

实际上：

你也允许它修改这些照片。

这两个权限，在系统看来属于同一类授权。

而弹窗无法在短短几秒内，把这种风险解释清楚。

---

最后的思考

“浏览器不用安装病毒，也能勒索你的文件。”

只有：

一个有用功能；

一个相信用户理解权限的设计；

以及一个足够可信的谎言。

真正变化的是安全边界。

过去我们关注：

攻击者能不能运行代码。

现在越来越重要的问题是：

攻击者能不能诱导已经拥有权限的软件，替它完成攻击。

浏览器没有被攻破。

它只是被一个网页请求。

而最危险的部分，也许不是 JavaScript。

而是那个我们每天都会快速点击：

“允许”。

却很少认真看的按钮。

阅读原文：https://mp.weixin.qq.com/s/MZg2BgyZjtvviUyYLItHmg