简易自动填充bookmarklet的安全风险与优化方案咨询

基础背景 #

工作场景中需频繁登录人力资源、差旅预订等多套内部门户系统，不同门户对应独立登录凭据。因终端策略禁用浏览器扩展，无法使用商用密码管理器，为避免密码复用、明文记录等不安全行为，自行编写了简易自动填充bookmarklet：通过硬编码JavaScript对象按站点映射存储6组账号密码，运行时校验当前站点信息，匹配成功后自动填充对应凭据。
当前功能运行正常，但存在明文存储、脚本注入页面的安全顾虑，核心疑问如下：

• 未开启书签云同步的前提下，是否存在物理访问风险？当前设备无其他共用用户，其他用户登录设备的独立Windows账户时，是否能读取用户目录下的书签内容？
• 每次触发bookmarklet时，包含全量密码的完整脚本会注入当前页面，站点方是否可以通过技术手段捕获全量密码对象并回传服务端？该风险和脚本使用全局/局部作用域是否有关？
• 当前实现是否有更安全的替代方案？此前尝试过将凭据存在独立文本文件、由bookmarklet读取填充的方案，但需要手动触发文件选择，流程过长，是否有更便捷的可行思路？

脱敏后的实现代码如下（方括号为脱敏占位内容）：

javascript: (() => {
  Object.entries(
    {
      "[document.title]": {
        "[username input element ID]": "[username]",
        "[password input element ID]": "[password]",
      }, //[Other entries...]
    }[document.title]
  ).forEach(([k, v]) => (document.getElementById(k).value = v));
})();

具体答复 #

物理访问风险相关 #

• 默认配置下，独立Windows普通账户无法读取你的书签数据。主流浏览器的书签存储在对应用户目录的AppData路径下，NTFS权限默认仅对账户所有者、系统管理员组开放，无管理员权限的普通本地账户没有读取权限。
• 仅两种场景存在风险：一是设备加入域环境，域管理员默认具备所有本地用户目录的读取权限；二是你的Windows账户未设置强密码、或开启了默认共享且存在弱口令，可能被跨账户横向访问拿到数据。普通非管理员独立账户正常情况下无法获取你的书签内容。

页面窃密风险相关 #

• 该风险真实存在，和脚本使用全局/局部作用域无本质关联。Bookmarklet触发后脚本直接运行在当前页面的JS执行上下文中，页面自带的脚本可以通过劫持原生方法（比如重写document.getElementById、监听表单元素value变更、钩子Object实例化逻辑）等方式捕获脚本运行过程中的所有数据，无论你把密码对象放在IIFE局部作用域还是挂载到全局，只要数据进入页面上下文，站点方有意抓取就一定能拿到。
• 你当前的代码逻辑会先初始化全量站点的凭据映射对象，再读取当前页面对应的条目，也就是说哪怕你当前只在A系统页面，B、C等其他所有系统的密码都会被加载到当前页面上下文，站点方可以直接获取全量凭据，风险比你预想的更高。另外你现在用document.title做匹配键可靠性很差，换成location.hostname做映射键可以避免误匹配。

替代方案相关 #

• 优先推荐使用浏览器原生密码管理功能，绝大多数企业终端管控策略不会禁用浏览器自带的密码存储能力，该功能为浏览器原生实现，不需要安装扩展，数据在本地加密存储，填充时不会向页面暴露全量凭据，安全性远高于自定义bookmarklet。
• 如果必须用bookmarklet方案，可以做本地对称加密改造：书签内仅存储经主密码加密后的凭据密文，触发时弹出输入框要求输入主密码，本地完成解密后再填充，全程不发起网络请求，既不会触发扩展管控规则，就算书签被他人获取，没有主密码也无法解出明文凭据。
• 可以优化本地文件方案的体验：用系统自带能力写一个仅监听127.0.0.1回环地址的极简本地服务，bookmarklet触发时仅向本地端口请求当前域名对应的单条凭据，本地服务完成域名校验后只返回当前站点的账号密码，不需要手动选择文件，也不会把全量凭据暴露给页面，注意服务不要绑定公网地址即可避免外部访问风险。

内容的提问来源于stack exchange，提问作者raiksey