Isoline 指南

如何交接浏览器工作,而不分享原始凭证

只分享完成任务必需的权限,并把有效期限制在必要时长。优先使用服务内具名访问和限定委派;即使无人看到 Cookie 值,已登录配置文件仍承载敏感权限。

团队常说需要“共享登录”,实际需求却可能更窄:审核草稿、更新获授权店铺、重现地区性缺陷,或继续处理支持工单。从任务出发,比从密码出发能找到更多选择。

什么算原始凭证

明显的例子包括密码、恢复码、一次性密码种子、私钥和代理密码。浏览器工作还涉及不太显眼的凭证:

  • 身份验证 Cookie 与会话标识。
  • OAuth 访问令牌与刷新令牌。
  • 密码管理器记录和自动填充数据。
  • 通行密钥私钥材料,或对持有私钥的验证器的访问。
  • 受信任设备与恢复状态。
  • 包含上述任何内容的配置文件封存包。

NIST 会话指南将浏览器会话连续性建立在持有会话机密之上。OWASP 会话管理指南指出了实际后果:令牌有效期间,可能等同于创建会话时最强的身份验证。

客户端加密的配置文件包,只有在存储服务商不持有解密密钥时,才能向服务商隐藏凭证值;它也能减少偶然旁观者看到内容的机会。获授权接收者的设备解密并启动后,浏览器仍能使用会话权限。即使接收者从未读取 Cookie,这次交接也已经转移了权限。

将任务与权限分开描述

选择共享机制前,写一份简短访问声明:

具名操作人员 A,可以从批准设备 D,对资源 C 执行操作 B,许可至时间 E,有关批准和稽核遵循规则 F。

这句话能暴露多余权限。如果任务是“批准这份草稿”,完整管理员会话就过大。如果目标服务已有审核者角色,再共享浏览器状态只会增加风险,没有增加能力。

NIST 的零信任架构建议按会话授予单个资源访问,并只提供完成任务需要的最小权限。不必采用叫作“零信任”的产品,也能应用这一原则。它适合检查任何浏览器交接设计。

按以下顺序优先选择

1. 目标服务中的具名访问

网站或应用提供团队、组织、角色、委派或审批功能时,优先使用。每个人通过自己的账号和验证器登录,目标服务即可执行权限、把操作归因到具体人员、应用自身风险控制,并单独撤销一人而不改变所有人的凭证。

这通常是最有力的模式,因为理解操作含义的系统负责授权。浏览器管理器无法可靠地把某网站的共享管理员会话,变成网站层面的审核者角色。

共享和群组账号会削弱责任追溯。NIST SP 800-53 第 5 版建议限制使用,并在允许前定义明确条件。

2. 目标服务提供的限定委派

服务支持 OAuth 或其他委派协议时,只向客户端或执行者授予必要资源、操作和有效期。RFC 9700建议把访问令牌权限限制在最小需要范围,并将受众限定为目标资源服务器。

优先采用短期、可撤销、受众受限的授权。发送者约束令牌可以降低令牌泄露后的重放风险,但攻击者同时获得令牌和绑定密钥材料时,仍无法防护。客户端设备与软件始终处于威胁边界内。

委派尤其适合自动化:脚本可以获得某项明确操作的许可,而不需要人的密码或通用浏览器会话。稽核事件应标明发起人、被委派执行者、资源、范围与结果。

3. 通过受控工具使用已保存机密

部分旧服务只支持共享凭证。受控凭证代理或密码管理器,可以让批准的浏览器流程使用机密,而不在聊天、工单、文档或普通应用输出中显示,从而减少复制。

这改善了保管、轮替和访问复核,却不能修复目标服务的账号模型。登录后,所有人员可能仍以同一网站身份操作。产生的会话仍敏感,需要自己的超时、撤销与设备控制。

OWASP 机密管理指南建议细粒度访问、尽量减少人员接触机密值、管理生命周期,并记录谁请求和使用了机密。浏览器产品应尽可能通过不暴露内容的引用集成,而不是再成为一个通用机密仓库。

4. 受保护的浏览器会话交接

只有目标服务缺少合适委派、且获授权流程确实需要会话连续性时,才使用共享的已登录配置文件。这是常规交接中风险最高的方式,因为接收者获得了通过活动账号执行操作的能力。

最低控制应包括:

  • 明确所有者与获准接收者。
  • 说明任务、资源与到期时间。
  • 单一活动写入者,或经过测试的冲突模型。
  • 任何云端上传之前进行客户端加密。
  • 接收设备授权与本地保护。
  • 防止同时操作责任不清的锁。
  • 授权、下载、打开、敏感操作、关闭、撤销和恢复的稽核事件。
  • 正常接口返回遮蔽后的状态,而不是 Cookie 或令牌。
  • 目标服务的会话撤销计划。

这种模式可减少凭证值被随手复制,并在密钥不由存储服务商持有时保护云端内容。但它不能让目标服务区分使用同一账号的两个人,也不能防止恶意软件、恶意扩展或滥用授权的接收者操作会话。

5. 原始凭证转移

将密码、Cookie、恢复码、通行密钥或配置文件封存包复制进消息、表格、工单、脚本或未保护导出,会产生长期存在、副本不明且难以撤销的机密。应避免这种做法。

特殊旧流程确实要求转移时,应遵循组织批准的凭证流程,尽量减少接收者和有效期,并在之后轮替或撤销。消息加密不能代替个人责任,也不能代替对每份副本的记录。

比较权限,而不只比较方便程度

模式 目标服务能识别操作人员吗 范围能否匹配任务 撤销边界 主要剩余风险
目标服务具名成员 通常可以 通常最强 移除单个成员或角色 目标服务权限过大
限定范围的委派令牌 可表示执行者与客户端 范围和受众较窄时较强 撤销授权或令牌 令牌、客户端或密钥被入侵
受控的共享登录 登录后通常不能 受共享账号限制 轮替机密并终止会话 共享网站身份与活动会话
加密浏览器会话 目标服务通常不能 配置文件级,往往较广 撤销共享及目标会话 接收设备能行使完整会话权限
原始凭证副本 无可靠个人身份 通常较广 寻找副本、轮替并终止会话 副本不明、责任追溯薄弱

因此,“没人能看见密码”不是完整成功标准。关键是接收者能行使多少权限、持续多久,以及哪个系统能撤销它。

通行密钥改善验证,但共享仍需谨慎

WebAuthn 创建以依赖方为范围的公钥凭证。WebAuthn Level 3 规范说明,私钥由验证器持有,网站脚本得到签名结果,而非私有凭证本身。正确部署时,这能提供抗网络钓鱼验证。

通行密钥不会自动创建团队角色。目标服务可以为每位具名成员注册独立凭证,保留个人访问。通行密钥服务也可能支持同步或共享验证密钥。NIST SP 800-63B-4认可这种模式,同时指出未经授权使用、跨设备扩散、同步体系入侵和难以撤销等风险。

获授权团队应优先让每个人使用独立的具名服务账号和验证器。如果共享通行密钥是唯一受支持模式,应将其视为共享验证器,记录谁能接收、可用于哪些受管理设备,并验证服务如何展示、撤销与恢复共享密钥。目标服务仍可能把所有操作记在同一账号下。

把浏览器交接定义为明确约定

移动配置文件状态前,受控交接应回答:

  1. 谁在操作? 使用具名组织身份,不用泛化的“操作员”标签。
  2. 谁批准? 记录所有者或策略决定,不存储审批机密。
  3. 共享什么? 标明配置文件和任务,避免列出原始 Cookie 或凭证。
  4. 接收者能做什么? 区分启动、编辑、导出、自动化、共享和管理权限。
  5. 能在哪里运行? 限于适合数据要求、已注册且可信的设备。
  6. 持续多久? 设置到期时间,关闭闲置会话。
  7. 可否同时写入? 除非冲突处理经过刻意设计与测试,否则只允许一个活动写入者。
  8. 记录什么? 记录执行者、设备、配置文件引用、操作、结果与时间,默认排除机密值和页面内容。
  9. 如何撤销? 同时覆盖浏览器共享授权与目标服务会话。
  10. 如何恢复? 保留已知正常版本,避免意外恢复已撤销权限。

加密是约定的一部分,保护存储或传输中的数据;授权决定谁能获得解密路径;设备信任与本地隔离保护实际使用;稽核支持责任追溯和调查。这些控制不能彼此替代。

不让自动化接触不必要的机密

API、SDK、命令行工具与代理程序经常需要启动配置文件或执行批准的生命周期操作,却很少需要 Cookie 值、密码、通行密钥、代理凭证或原始封存包。

范围狭窄的接口可以接收不暴露内容的配置文件或机密引用,并返回:

  • 操作是否获授权。
  • 就绪、锁定、过期或已撤销等不含敏感内容的状态。
  • 有期限的进程或会话引用。
  • 结构化错误与恢复步骤。
  • 稽核事件引用。

不能仅因为调用方能启动配置文件,就向其返回凭证。导出、批量共享或其他携带机密的操作,需要独立策略,并在适用时明确批准。

网站内容与自动化输入也始终不可信。网页指令不能诱使代理通过日志、工具输出、截图或支持渠道泄露会话材料。

撤销分为两层

从浏览器工作区移除协作者,会停止其未来通过该工作区获得授权访问,但不能证明目标服务会话已经失效。设备可能已持有解密状态,复制过或仍在运行的会话也可能继续。

正常结束访问时:

  1. 撤销团队授权并关闭配置文件租约。
  2. 按保留政策移除加密本地材料。
  3. 目标服务支持时,终止相关会话。
  4. 移除该人员的目标服务成员资格或委派授权。
  5. 在批准期限内保留已遮蔽敏感信息的稽核证据。

怀疑被入侵时,还应隔离受影响版本,撤销活动会话与令牌,移除未经授权的验证器,轮替暴露的共享机密,并审查稽核事件。恢复旧快照可能带回旧会话机密,因此恢复必须尊重当前撤销状态。

谨慎交接后仍有的限制

  • 客户端加密保护存储与传输中的数据,但获授权端点必须解密浏览器所需内容。
  • 浏览器锁控制产品层面的并发,不控制目标服务的每项操作。
  • 无论浏览器产品的稽核多细,共享会话通常仍只向目标服务呈现一个账号身份。
  • 被入侵设备或扩展无需提取可读密码,也能通过有效会话操作。
  • 撤销工作区授权和撤销网站会话是两项操作。
  • 目标服务条款、客户合同和适用法律,仍决定流程能否委派。
  • 某些服务没有独立访问的安全替代方案,此时缩小范围或拒绝交接可能更负责任。

RFC 6265 将 Cookie 描述为一种随请求附带的权限:即使发起请求的一方不知道 Cookie 值,浏览器也能把它附到请求中。这正是会话共享的核心限制。隐藏凭证减少的是泄露,不是浏览器能行使的权限。

关于本指南

AI 辅助
本文由 AI 根据英文原文翻译。Isoline 对发布内容负责。目前尚无人工语言审核记录。

来源

来源支持下列主题。访问日期说明引用材料最近何时经过核查。

  1. NIST SP 800-63B-4:身份验证与验证器管理 National Institute of Standards and Technology
    支持的主题
    验证器共享、可同步验证器风险、恢复与具名访问考量。
    访问日期
  2. NIST SP 800-63B-4:会话管理 National Institute of Standards and Technology
    支持的主题
    浏览器会话连续性、会话机密持有、Cookie 保护与会话终止。
    访问日期
  3. NIST SP 800-207:零信任架构 National Institute of Standards and Technology
    支持的主题
    按会话授予资源访问、最小权限与明确授权决定。
    访问日期
  4. NIST SP 800-53 第 5 版:安全与隐私控制 National Institute of Standards and Technology
    支持的主题
    共享账号限制、个人责任、访问控制、稽核与撤销控制。
    访问日期
  5. W3C Web Authentication Level 3 World Wide Web Consortium
    支持的主题
    以依赖方为范围的公钥凭证,以及验证器持有私钥的边界。
    访问日期
  6. RFC 9700:OAuth 2.0 安全最佳现行实践 Internet Engineering Task Force
    支持的主题
    访问令牌的权限、资源、受众、有效期与发送者约束指南。
    访问日期
  7. RFC 6265:HTTP 状态管理机制 Internet Engineering Task Force
    支持的主题
    Cookie 作为浏览器随请求附带的权限,以及隐藏会话值仍无法消除的共享限制。
    访问日期
  8. 支持的主题
    会话令牌敏感性、生命周期、保护、更新、撤销与日常处理。
    访问日期
  9. 支持的主题
    细粒度机密访问、生命周期控制、轮替、稽核与减少人员接触机密值。
    访问日期

内容更正

  1. 澄清:只有存储服务商无法取得解密密钥时,加密才能向其隐藏配置文件内容。
建议更正