文章总结： 该文档分析了基于ChromiumFileSystemAccessAPI的浏览器原生勒索攻击风险，由AI生成样本触发。攻击者通过伪装成AI工具诱导用户授权文件夹访问，从而在浏览器内加密或破坏文件，无需安装恶意软件。研究指出AI可能帮助攻击者发现非传统攻击路径，并提供了企业安全运营建议，包括浏览器权限管理、EDR监控异常文件行为等。 综合评分： 95 文章分类： web安全,安全意识,红队,恶意软件,漏洞分析

---

浏览器里也能跑勒索？Chromium 文件访问 API 风险

原创

JacobWang JacobWang

NowSec

2026年7月7日 08:00 陕西

在小说阅读器读本章

去阅读

过去提到勒索软件，很多人的第一反应是：恶意程序、木马、宏病毒、EXE、APK、脚本、后门、横向移动、域控、批量加密。

但最近 Check Point Research 披露的一项研究，把勒索攻击的边界往前推了一步：

如果不安装任何软件，不投递本地木马，不利用浏览器漏洞，只是打开一个网页，浏览器里是否也可能跑出“勒索式攻击”？

答案是：在特定条件下，可以。

Check Point Research 在 2026 年 7 月 1 日发布研究《Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique》，分析了一个 AI 生成的恶意样本。这个样本本身并不完整，也没有形成稳定在野攻击，但它把一个看似“幻觉式”的恶意需求，连接到了一个真实存在的浏览器能力：Chromium 的 File System Access API。

这件事真正值得关注的地方，不是“浏览器勒索已经大规模爆发”，而是：

AI 可能正在帮助攻击者发现过去不熟悉、不常用、甚至只存在于理论中的攻击路径。

一、这不是浏览器 0day，而是权限被社会工程化滥用

首先要明确一点：这次研究并不是说 Chrome 或 Chromium 出现了新的 0day 漏洞。

攻击链不依赖浏览器漏洞，不需要 Root 权限，也不需要安装本地程序。它依赖的是一个合法浏览器能力：File System Access API。

根据 Chrome 官方文档，File System Access API 的设计目标，是让 Web 应用在用户授权后，可以读取、保存或修改本地设备上的文件和文件夹。它适合一些正常场景，比如在线 IDE、文本编辑器、图片处理工具、视频处理工具等。用户授权后，Web 应用可以读取本地文件，也可以保存更改，甚至枚举用户选择的目录内容。

换句话说，这个 API 本身不是恶意能力。

问题在于：攻击者可以伪装成一个看似合理的 Web 工具，诱导用户主动授予文件夹访问权限。

比如，一个网页声称自己是“AI 图片增强工具”“头像高清修复工具”“照片批量优化工具”。用户上传或选择照片后，网页再请求访问某个图片目录，用“需要保存增强后的结果”作为理由，让用户点击允许。

一旦用户授权，网页就可能在浏览器权限范围内读取、处理、修改被授权目录中的文件。

Check Point Research 指出，其研究样本展示的浏览器原生勒索思路，是通过钓鱼诱饵诱导受害者向网页授予文件系统访问权限；授权后，网页可以枚举本地文件、读取内容、外传数据、加密或覆盖文件，并展示勒索式提示。整个过程不需要安装原生 payload，也不需要利用浏览器漏洞。

所以，这类风险的关键不是“浏览器被打穿”，而是“权限提示被伪装成正常业务流程”。

二、AI 生成样本为什么危险？

Check Point Research 的研究起点，是一个归因于 DeepSeek 的 AI 生成样本。研究人员分析了过去一年公开遥测中约 3000 个与 DeepSeek 相关的文件，其中 1383 个被 VirusTotal 检测或静态源码分析归类为恶意或危险。在这个数据集中，他们发现了一个实现危险浏览器原生技术的样本。

这个样本并不是一个成熟勒索家族。

它更像是一个“AI 生成的恶意幻想集合”：声称能窃取信息、监听输入、访问摄像头、窃取令牌、加密文件、弹出勒索提示等。但很多能力在普通网页环境中其实无法成立，或者会被浏览器安全模型限制。

但问题就在这里。

虽然大部分功能像是幻觉，但其中有一个点是真实可行的：文件访问流程。

Check Point Research 指出，该样本引用了 showOpenFilePicker()、showDirectoryPicker() 等 File System Access API 相关能力，并尝试递归遍历用户选择目录、读取文件、把内容发送到后端，并显示勒索式警告。

这说明 AI 生成的恶意代码即使整体不可靠，也可能偶然连接到真实平台能力，暴露出一个可操作的攻击思路。

更准确地说：

AI 不一定发明了新漏洞。

但 AI 可能把攻击者原本不懂的浏览器能力，自动拼进攻击链里。

这才是它的危险性。

三、浏览器为什么会成为攻击执行环境？

传统安全模型里，浏览器通常被看作“访问入口”。

用户打开网页，浏览器展示内容。危险主要来自恶意脚本、钓鱼页面、浏览器漏洞、恶意扩展、下载木马等。

但现代浏览器已经不只是“网页查看器”。

它正在变成一个轻量应用平台。

今天的浏览器可以访问摄像头、麦克风、剪贴板、通知、位置、蓝牙、USB、MIDI、本地文件、离线存储、Service Worker、WebAssembly、WebGPU 等能力。

这些能力让 Web 应用更接近原生应用，也让攻击面发生变化。

File System Access API 就是典型例子。

Chrome 官方文档明确说明，在用户授权后，Web 应用可以直接读取或保存本地设备上的文件和文件夹，并且可以打开目录、枚举目录内容。

对于正常应用，这带来了便利。

但对于恶意站点，这意味着浏览器本身可以成为执行环境。

攻击者不一定需要落地 EXE，也不一定需要绕过杀软。只要用户在可信错觉下授予权限，恶意逻辑就可以运行在浏览器进程内部。

这会带来一个检测难点：

传统 EDR 或杀毒更擅长发现陌生可执行文件、恶意脚本落地、进程注入、提权、注册表持久化、异常子进程等行为。

但如果危险动作发生在浏览器内部，并且文件操作来自用户授权后的浏览器 API，那么它在表面上可能更像“浏览器正在正常处理文件”。

四、它不是万能攻击，也有明显限制

这类风险不能夸大。

它不是打开网页就能无条件加密全盘。

根据 Check Point Research 和 Chrome 官方文档，这类攻击有几个重要限制。

第一，用户必须参与授权。File System Access API 的文件选择器需要用户手势触发，用户可以取消选择；如果要修改已有文件，浏览器也会请求写入权限。

第二，它不能任意访问整个系统磁盘。Check Point Research 指出，Chromium 会对一些敏感位置做限制，例如系统目录、应用目录、浏览器数据目录、部分用户主目录、AppData 等路径会受到阻止或约束。

第三，它主要影响暴露 picker-based File System Access API 的浏览器。Chrome 官方文档称，该 API 支持多数 Chromium 浏览器，覆盖 Windows、macOS、ChromeOS、Linux 和 Android。

第四，iOS 上风险明显不同。Check Point Research 指出，iOS 上 Safari 不向网站暴露同样的 File System Access 原语；Chrome on iOS 也使用 WebKit，因此不实现同样的 File System Access API。

第五，目前没有证据表明这种浏览器原生勒索模式已经在真实攻击中大规模使用。The Hacker News 对该研究的报道也提到，没有证据显示该 browser-native ransomware 模式已被在野滥用。

所以，更准确的结论是：

这不是一个“立即大规模爆发”的勒索威胁。

但它是一个值得提前关注的攻击路径。

因为攻击者最喜欢的就是这种“看似正常、权限合法、检测困难、用户容易误点”的流程。

五、为什么 Android 场景尤其值得关注？

Check Point Research 特别强调了 Android 场景。

原因很直接：手机里的照片目录非常敏感。

在 PC 上，Pictures 目录可能只是图片文件夹之一。但在移动端，照片库往往保存着大量个人和工作敏感数据，例如身份证照片、银行卡截图、合同、票据、聊天截图、恢复码、医疗记录、家庭照片、工作现场图片等。

Check Point Research 指出，Chrome 132 在 Android 上引入 File System Access 支持后，网页在用户授权后可以读取和保存选定文件及文件夹的更改；其测试显示，在部分 Android 设备上，可以选择照片目录，包括 DCIM 目录。

这就让钓鱼场景变得更自然。

用户打开一个“AI 图片增强”网页。

网页要求选择照片。

用户选择照片后，网页提示需要访问某个目录以保存处理结果。

用户点击允许。

整个流程看起来符合预期。

但在后台，页面可能并不是在做图片增强，而是在对授权目录中的图片进行读取、外传、覆盖或破坏。

这类攻击的社工点很强，因为用户不会把“打开网页 + 选择图片目录”理解为“正在运行勒索软件”。

这也是未来 AI 工具类钓鱼页面需要重点关注的原因。

六、AI 品牌正在成为新的钓鱼外衣

过去，钓鱼页面常伪装成：

• 快递查询；
• 发票下载；
• 网盘分享；
• 会议邀请；
• 安全验证；
• 在线文档；
• 视频播放器；
• 浏览器更新；
• 登录门户。

现在，新的诱饵正在变成：

• AI 图片修复；
• AI 头像生成；
• AI 简历优化；
• AI 文档总结；
• AI 视频增强；
• AI PPT 生成；
• AI 文件转换；
• AI 证件照处理；
• AI 批量图片压缩。

这些工具天然需要用户上传文件、选择目录、授权访问、等待处理、下载结果。

也就是说，AI 工具的正常使用流程，和恶意文件访问诱导流程非常接近。

这会降低用户警惕。

Check Point Research 也提醒，攻击者越来越多地把恶意流程伪装成 AI 工具，例如头像增强、照片优化、生产力工具等；一个精美的 AI 页面并不等于安全。

这就是浏览器原生勒索风险的核心社工逻辑：

不是让用户运行木马，而是让用户相信“这个网页确实需要访问我的文件夹”。

七、对企业安全运营意味着什么？

从企业安全运营视角看，这类风险有几个重要启发。

1. 浏览器权限需要进入安全管理范围

很多企业对浏览器的管理还停留在：

• 禁止访问恶意网站；
• 安装安全插件；
• 配置代理；
• 管控扩展；
• 开启下载扫描；
• 禁止弱口令保存；
• 统一浏览器版本。

但浏览器里的权限管理越来越重要。

摄像头、麦克风、剪贴板、通知、位置、本地文件访问，都不应完全交给用户随意点击。

特别是 File System Access API 这种能力，本质上已经接近“网页对本地文件系统的授权读写”。

Chrome Enterprise 已经提供相关策略，例如 DefaultFileSystemReadGuardSetting 可以控制网站是否能请求读取文件和目录；DefaultFileSystemWriteGuardSetting 可以控制网站是否能请求写入文件和目录。对应策略可以设置为阻止或允许网站请求用户授权。

对于 Microsoft Edge，微软官方策略文档也提供了类似的 DefaultFileSystemWriteGuardSetting，企业可设置为不允许任何站点请求写入文件和目录，或允许站点向用户请求写入权限。

这说明企业并不是完全没有控制手段。

如果业务不依赖浏览器直接读写本地目录，可以考虑默认阻断，再对可信业务站点做白名单放行。

2. WAF 不一定看得到真正的风险动作

WAF 可以识别恶意页面、钓鱼域名、异常请求、文件上传下载、已知攻击载荷等。

但在这种场景里，真正关键的动作发生在用户浏览器本地：

用户点击授权。

浏览器拿到文件句柄。

网页读取目录。

网页修改文件。

这些动作未必经过企业 WAF。

如果文件内容被外传，可能会经过网络出口或代理；但如果只是本地覆盖或破坏，边界设备可能根本看不到完整过程。

所以，不能指望 WAF 单独解决这类问题。

更合理的防护位置包括：

• 浏览器企业策略；
• 终端安全策略；
• 安全浏览器或零信任浏览器；
• DNS/代理拦截；
• DLP；
• EDR 行为监控；
• 企业网盘和数据备份；
• 用户权限提示教育。

3. EDR 要关注“浏览器进程的异常文件行为”

传统勒索检测一般关注异常进程批量改写文件、创建加密后缀、删除卷影副本、终止服务、横向移动等行为。

但如果批量文件访问来自浏览器进程，就需要调整检测思路。

安全团队可以关注：

• 浏览器进程短时间内大量读取图片、文档、压缩包；
• 浏览器进程对同一目录大量写入或覆盖；
• 浏览器访问陌生 AI 工具站点后出现文件批量变化；
• 浏览器进程与不明外部地址发生大规模上传；
• 用户授权文件访问后出现异常网络流量；
• 终端上敏感目录被非办公软件批量改写。

这类行为不能直接等同于恶意，因为浏览器确实可能运行在线编辑器、图片工具、云盘同步类 Web 应用。

因此需要结合站点信誉、访问上下文、文件类型、写入规模、外联目的地、用户行为等因素做关联判断。

4. 代理和 DNS 日志要关注“AI 工具钓鱼化”

对于企业来说，很多风险不一定从漏洞入口进入，而是从员工访问陌生工具站点开始。

建议重点关注：

• 新注册 AI 工具域名；
• 仿冒知名 AI 产品的域名；
• 使用免费托管平台的图片处理站点；
• 要求浏览器访问本地文件夹的在线工具；
• 声称“免费批量增强”“免费证件照修复”“免费照片恢复”的站点；
• 与上传、图像处理、文件转换相关但信誉不明的域名。

这类站点不一定一开始就投放恶意代码，也可能先正常运行，积累访问量后再替换逻辑。

八、用户侧应该如何判断？

对普通用户来说，最关键的是改变一个习惯：

不要把浏览器文件夹授权提示当作普通弹窗。

如果一个网页要求访问某个文件夹，应先问四个问题：

第一，这个网站是谁？是否可信？

第二，它为什么需要访问整个文件夹，而不是单个文件？

第三，它是否需要写入权限，还是只需要读取？

第四，这个文件夹里有没有身份证、银行卡、工作资料、恢复码、合同、截图等敏感内容？

如果只是试用一个陌生 AI 图片工具，最稳妥的方式不是直接授权相册或主图片目录，而是新建一个临时空目录，只放少量测试图片。

对于重要照片、证件材料、工作文件，最好不要直接交给来路不明的在线 AI 工具处理。

此外，备份仍然是应对勒索和误删的基础措施。无论攻击来自本地木马、浏览器权限滥用，还是用户误操作，只要存在可靠的离线备份或云端版本历史，攻击者的勒索空间就会明显下降。

九、浏览器安全模型需要重新被理解

这起研究最有价值的地方，是提醒我们重新理解浏览器安全边界。

过去我们常说：

浏览器有沙箱，网页不能随便碰本地文件。

这句话大体没错。

但现代 Web 平台正在把越来越多原生能力开放给网页，只是通过权限提示、用户手势、站点隔离、敏感目录限制等机制来控制风险。

也就是说，浏览器安全边界不是一堵完全封死的墙。

它更像是一组“带门禁的能力开关”。

而攻击者最擅长的，就是让用户自己把门打开。

File System Access API 的设计初衷是为了提升 Web 应用能力，让在线 IDE、编辑器、创作工具更接近桌面软件体验。Chrome 官方文档也强调，这个 API 设计时考虑了用户控制、透明性和权限提示等原则。

但安全问题往往发生在“合法功能被用于恶意目的”的交界处。

权限提示并不等于安全。

用户能理解这个提示，才是安全。

用户能判断这个站点是否应该拥有这个权限，才是安全。

企业能集中管控这些权限，才是安全。

十、结语：AI 没有发明勒索，但它正在发现新的组合方式

浏览器原生勒索目前还不是大规模在野攻击。

Check Point Research 也明确表示，研究中的原始样本不完整，没有可靠实现完整攻击流程；但它展示了现代 LLM 如何把一个不现实的恶意想法，与真实浏览器能力连接起来，并把理论风险推向可操作攻击思路。

这才是 AI 时代安全风险变化的重点。

AI 不一定会凭空创造新漏洞。

但它会帮助攻击者更快地把已有能力组合起来。

一个非专业攻击者，未必知道 File System Access API 是什么，也未必理解浏览器权限模型。但他只要描述一个恶意目标，模型就可能在庞大的知识中找到一条看似可行的路径。

这会改变攻击技术的产生方式。

过去，新的攻击路径主要来自安全研究员、漏洞挖掘者、恶意软件作者的经验和创造力。

现在，AI 可能成为“攻击路径发现器”。

它可能生成很多错误、荒诞、不完整的东西。

但只要其中一个点是真的，就足够危险。

浏览器里能不能跑勒索？

严格说，不是浏览器自己变成勒索软件，而是浏览器提供的合法文件访问能力，可能在社工诱导下被滥用为勒索流程的一部分。

真正的警告是：

未来的安全防护不能只盯漏洞和木马。

还要盯合法 API、权限提示、用户授权、浏览器策略，以及 AI 如何把这些能力重新组合成攻击链。

在 AI 时代，攻击者不一定需要更高的技术水平。

他们只需要更低成本地试错。

而防守方必须提前把这些“看似正常”的能力纳入风险管理。

资料来源：Check Point Research：Browser-Only Ransomware: From LLM Hallucinations to a Practical Attack Technique，说明 AI 生成样本、File System Access API 滥用思路和限制条件。

资料来源：The Hacker News：对 Check Point browser-native ransomware 研究的报道，提及目前没有证据显示该模式已被在野大规模滥用。

资料来源：Chrome Developers：File System Access API 官方文档，说明用户授权后 Web 应用读取、保存和处理本地文件的设计目标与能力边界。

资料来源：Chrome Enterprise Policy：DefaultFileSystemReadGuardSetting 和 DefaultFileSystemWriteGuardSetting 策略说明，用于管控站点请求文件读写权限。

资料来源：Microsoft Learn：Microsoft Edge DefaultFileSystemWriteGuardSetting 策略说明，用于管控站点请求写入本地文件和目录。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：NowSec JacobWang JacobWang《浏览器里也能跑勒索？Chromium 文件访问 API 风险》