编辑
Shane Weeden，IBM
何安，IBM
抽象
会话劫持是在线欺诈和帐户接管的日益增长的初始攻击媒介。由于 FIDO 身份验证降低了其他更简单形式的入侵（例如撞库和网络钓鱼）的有效性，因此网络犯罪分子转向盗窃和重复使用不记名令牌。持有者令牌是一种凭据形式，包括连接到网站的浏览器使用的会话 cookie 和其他厚客户端应用程序类型（如本机移动应用程序）使用的 OAuth 访问令牌。当这些凭据是长期存在的，并且可以从创建它们的机器中“提升和转移”，以便不良行为者从另一台机器上使用时，它们的可交易价值就很大了。新兴技术，例如用于浏览器的设备绑定会话凭据 （DBSC） 和用于 OAuth 应用程序的演示拥有证明 （DPoP），旨在减少会话劫持的威胁。本文介绍了这些技术如何解决会话劫持问题，以及它们如何补充在线生态系统中强大的防网络钓鱼身份验证。
观众
本白皮书面向首席信息安全官 （CISO） 和技术人员，他们的职责是保护在线身份和访问管理的安全性和生命周期免受在线欺诈。
1. 引言
身份验证和授权是身份生命周期不可或缺的一部分，尤其是对于在线凭证生态系统而言。在线身份欺诈的威胁日益严重，代价高昂的安全事件和违规行为，促使企业寻找方法来保护其员工免受网络钓鱼、撞库和会话劫持等不同攻击媒介的帐户接管。在身份验证方面，使用密钥的 FIDO 身份验证为用户提供了“更安全、更安全、更快速的在线体验”，而通行密钥采用的增加有助于减少通过中间人 （MITM） 网络钓鱼攻击完成的凭据网络钓鱼、撞库和会话劫持等攻击媒介的成功率。但是，认证仪式之后会发生什么？
身份验证后，浏览器和应用程序客户端通常会获得其他凭据。企业应用程序通常分为两大类：基于 Web 浏览器并使用会话 cookie 进行状态管理的应用程序，以及使用 OAuth 访问令牌的厚客户端应用程序（包括一些基于浏览器的单页应用程序和大多数本机移动应用程序）。这两种类型的凭据（会话 cookie 和访问令牌）在其基本用途中都被视为“持有者”令牌。如果你有令牌（会话 Cookie 或访问令牌），则可以在该令牌的生存期内作为对该令牌进行身份验证和拥有的用户继续进行交易。本白皮书探讨了解决不记名令牌的“直接迁移”攻击媒介的相邻技术，以及这些技术如何补充基于 FIDO 的身份验证机制。本文特别关注提议的 Web 标准 设备绑定会话凭据 （DBSC）， 用于保护浏览器会话 cookie 和 OAuth 2.0 证明 用于保护 OAuth 赠款的占有证明 （DPoP）。
2. 术语
会话劫持：利用通常为会话 cookie 管理的 Web 会话控制机制。
撞库：将被盗的用户名和密码对（凭据）自动注入网站登录表单中，以欺诈性地获取对用户帐户的访问权限。
1. 密钥 – https://fidoalliance.org/passkeys/
2. 设备绑定会话凭据 – https://github.com/w3c/webappsec-dbsc
3. OAuth 2.0 证明占有证明 （DPoP） – RFC9449： https://datatracker.ietf.org/doc/html/rfc9449
4. 会话劫持攻击 https://owasp.org/www-community/attacks/Session_hijacking_attack
5. 撞库 https://owasp.org/www-community/attacks/Credential_stuffing
访问令牌：客户端应用程序用于代表用户调用 API 调用的凭据。
session cookie：由浏览器管理的凭据，用于维护浏览器和网站之间的会话状态。
持有者令牌：令牌（在本白皮书的上下文中可能指访问令牌或会话 cookie）之所以如此称呼，是因为持有令牌的人可以使用它来访问资源。不记名令牌本身可以“提升和转移”以在另一个计算设备上使用。
发送方约束令牌：受一种机制保护的令牌，该机制旨在最大限度地降低在身份验证过程中建立令牌的客户端以外的任何设备都可以在服务器端资源的后续请求中使用该令牌的风险。
设备绑定会话凭据 （DBSC）：W3C Web 标准的提案，定义了用于建立和维护发件人约束 cookie 的协议和浏览器行为。该机制使用拥有非对称加密密钥的证明来帮助缓解会话 cookie 劫持。OAuth 2.0 演示行列证明 （DPoP）：一种用于实现发送方约束访问令牌的机制，要求客户端在使用令牌时证明拥有非对称加密密钥。
OAuth 2.0 演示行列证明 （DPoP）：一种用于实现发送方约束访问令牌的机制，要求客户端在使用令牌时证明拥有非对称加密密钥。
3. 安全生态系统的相邻/互补技术
虽然 FIDO 身份验证技术可以有效消除登录过程中发生的网络钓鱼和撞库攻击，但增加解决方案来减轻与不记名令牌盗窃相关的威胁也同样重要。在登录过程中攻击被挫败的不良行为者将追踪链中下一个最薄弱的环节，并试图窃取身份验证后持有者令牌。本节探讨其中两种用于保护持有者令牌的技术：设备绑定会话凭据 （DBSC） 保护基于浏览器的会话 Cookie，演示所有权证明 （DPoP） 保护 OAuth 授权。还讨论了保护不记名代币的替代方法。
由于没有一种技术可以防范所有威胁，因此需要多种技术的组合才能获得足够的保护。
表 1：提高安全性的技术组合
| 技术 | 身份验证威胁 | 身份验证后威胁 | |
| 远程网络钓鱼 | 撞库 | 代币盗窃 | |
| 通行密钥 | ✅ | ✅ | ❌ |
| DBSC/DPoP | ❌ | ❌ | ✅ |
| 密钥 + DBSC/DPoP | ✅ | ✅ | ✅ |
3.1 浏览器会话 Cookie 安全
在讨论设备绑定会话凭据 （DBSC） 之前，您需要了解有关浏览器会话 cookie 的问题。通过 cookie 盗窃进行会话劫持允许拥有被盗 cookie 的攻击者绕过最终用户身份验证，包括任何强身份验证或多因素身份验证 （MFA）。当浏览器创建长期会话 cookie（这是一种不记名令牌）时，这尤其成问题，因为这些 cookie 可以作为用户主要身份验证凭据的替代品进行交易，然后从攻击者的计算机上使用。这可能会导致未经授权访问敏感数据、财务损失以及组织声誉受损。
攻击者通过各种方法进行 cookie 盗窃，例如对用户现有的 MFA 登录过程进行中间人网络钓鱼（当不使用 FIDO 等防网络钓鱼身份验证时）、客户端恶意软件，偶尔还通过服务器端基础设施或软件中的漏洞进行。无论 cookie 盗窃是如何实施的，一旦成功，这些攻击不仅危险，而且难以隔离和检测。设备绑定会话凭据 （DBSC） 等补充技术使被盗 Cookie 无法从身份验证期间颁发的计算机以外的任何计算机上使用，从而最大限度地降低了与浏览器 Cookie 盗窃相关的风险。
3.2 设备绑定会话凭据 – DBSC
DBSC 是指目前在 W3C 的 Web 应用程序安全工作组内制定的拟议 Web 标准[2]。DBSC 的目标是打击和破坏被盗的网络会话 cookie 市场。这是通过定义 HTTP 消息传递协议以及所需的浏览器和服务器行为来实现的，以导致将应用程序会话 cookie 的使用绑定到用户的计算设备。DBSC 使用非对称密钥对，在浏览器实现中，攻击者应无法提取私钥 – 例如，存储在可信平台模块 （TPM）、安全元素或类似的基于硬件的加密模块中。
在高层次上，API 与用户的浏览器和安全密钥存储功能相结合，允许以下功能：
- 服务器向浏览器传达建立新 DBSC 会话的请求。这包括服务器提供的质询。
- 浏览器生成一个非对称密钥对，然后将公钥连同签名的质询一起发送到服务器。此过程称为 DBSC 注册。DBSC 的浏览器实现应使用作系统 API，以促进安全、硬件绑定的存储和私钥的使用。
- 服务器通过发出一个短期的、可刷新的auth_cookie将公用密钥绑定到浏览器会话，然后需要在后续的浏览器请求中传输到 Web 服务器。
由于auth_cookie会定期过期，因此浏览器需要一种机制来异步刷新auth_cookie到主应用程序 Web 流量。刷新过程需要使用 DBSC 注册期间创建的相同私钥对服务器发出的新质询进行签名，从而（定期）重新证明客户端浏览器仍然拥有相同的私钥。
将auth_cookie的生存期限制在很短的时间内（例如，几分钟）会扰乱长期会话 cookie 的交易市场。攻击者只能在短时间内使用窃取的会话 cookie（包括 auth_cookie），并且无法执行刷新作，因为执行刷新作所需的私钥无法从客户端计算机中提取。
DBSC 可以引入现有部署，只需对应用程序进行最小的更改。这很重要，因为 DBSC 可以很容易地作为 Web 插件模块合并到现有的服务器端技术中（例如，Apache 模块、Servlet 过滤器或反向代理功能）。这允许企业分阶段推出 DBSC 部署，而无需对所有当前基础设施进行彻底检修，并且公司可以首先确定某些关键端点或资源的优先级。
DBSC 服务器端实现也可以以允许语义的方式编写，例如：“如果浏览器支持 DBSC，则使用它，否则回退到常规会话特征。这使得用户在使用支持 DBSC 的浏览器时可以获得 DBSC 的安全优势，而无需要求所有用户先升级他们的浏览器。
有关 DBSC 协议和标准的更多详细信息，请参阅 设备绑定会话凭据说明器 ，包括向 DBSC 密钥对添加证明的企业特定扩展的提案。
3.2.1 是什么让 DBSC 成为 FIDO 的补充技术？
DBSC 标准草案允许登录过程与 DBSC API 紧密集成。FIDO 是一种使身份验证更安全且防网络钓鱼的机制，而 DBSC 是一种使持有者凭证（会话 cookie）在身份验证后更安全的机制。它们通过降低帐户接管和滥用的风险来相辅相成，使应用程序会话的整个生命周期更加安全。
3.2.2 替代解决方案
DBSC 并不是第一个建议将会话 cookie 绑定到客户端设备的标准。令牌绑定是结合了 IETF RFC 8471、 8472 和 8473 的替代方法。通过 HTTP 的令牌绑定是通过传输层安全性 （TLS） 扩展实现的，并使用加密证书将令牌绑定到 TLS 会话。令牌绑定的浏览器采用有限，并且实施起来很复杂，因为它需要在应用程序层和 TLS 安全堆栈中进行更改。基于 HTTP 标准的令牌绑定尚未被广泛采用，目前只有一种主要浏览器提供支持。
3.2.3 建议
DBSC 标准依赖于本地设备安全和作系统 API 来存储和使用绑定到浏览器会话的私钥。虽然这些私钥无法导出到另一台设备，但该密钥在本地系统上可用，并且可以由驻留在用户设备上的恶意软件执行。同样，浏览器内恶意软件仍然可以完全了解常规会话 cookie 和短期auth_cookies。DBSC 不能替代客户端恶意软件防护，并且 DBSC 的威胁模型不提供针对持久性客户端恶意软件的保护。最终，用户必须信任浏览器。
随着时间的推移，随着浏览器开始支持 DBSC，服务器能够使用支持和不支持该技术的浏览器组合使用将非常重要。一些企业可能会规定公司颁发的机器包括已知支持 DBSC 的浏览器，但许多企业不会。服务器端实现有必要考虑到这一点，在浏览器响应注册请求时使用 DBSC，并在浏览器不响应时容忍未绑定的会话 cookie。在构建或选择商业解决方案时，请确保考虑此方案，并包括在高度控制或受监管的环境或特定应用程序中实施严格要求 DBSC 的访问控制策略的能力。
在撰写本文时，DBSC 处于早期发展阶段。它是否会被浏览器供应商广泛采用还有待观察。希望通过 W3C 孵化和开发该标准将导致比以前的提案更广泛地采用，类似于采用 WebAuthn API 将密钥身份验证引入所有主要浏览器实现的方式。
4. OAuth 赠款
上一节介绍了 DBSC 作为防止 Web 浏览器中会话 cookie 被盗的一种手段。厚应用程序客户端（包括移动应用程序和单页 Web 应用程序）通常使用利用 OAuth 授权而不是会话 cookie 的无状态 API 调用。可以通过多种方式建立 OAuth 授权， 对于厚客户端，推荐的模式 是最初使用系统浏览器对用户进行身份验证，并授予应用程序代表他们执行作的访问权限。从概念上讲，这与基于浏览器的会话非常相似，包括在可能的情况下使用 FIDO 身份验证进行最终用户身份验证的能力和建议。在此流的基于浏览器的身份验证部分结束时，控制权将返回到厚客户端应用程序或单页 Web 应用程序，其中建立了用于编程 API 调用的令牌。
从这一点开始发生的挑战与浏览器所描述的几乎相同 – OAuth 令牌是持有者令牌，如果暴露给不良行为者，则可用于从远程计算机而不是合法应用程序调用应用程序 API。
本节介绍 DPoP 的使用，这是一种保护受 OAuth 保护的 API 调用中使用的凭据的“直接迁移”的技术，就像 DBSC 一样，它使用非对称密钥对和私钥的持续拥有证明。
4.1 证明占有证明 （DPoP）
OAuth 2.0 演示拥有证明 （DPoP） 是现有 OAuth 2.0 标准的扩展，用于实现设备绑定（或发件人限制）OAuth 访问和刷新令牌。它是一种应用程序级机制，允许与 OAuth 授权关联的令牌（即刷新令牌和访问令牌）使用公钥和私钥对与请求的客户端绑定。这要求客户端在执行访问令牌刷新作时向授权服务器证明其私钥的所有权，并在使用访问令牌调用 API 时向资源服务器证明其私钥的所有权。
6. 适用于原生应用程序的 OAuth 2.0 https://datatracker.ietf.org/doc/html/rfc8252
高保证 OpenID 规范（例如 金融级 API （FAPI 2.0））要求使用发件人约束令牌，而 DPoP 是实现此要求的推荐方法，当双向 TLS （mTLS） 不可用时。
从高层次上讲，DPoP 要求：
- 客户端生成一个每次授权的公钥/私钥对，用于构建 DPoP 证明。最佳实践实现应使用作系统 API 来确保私钥不可提取。
- 在初始授权建立时（例如，将 OAuth 授权代码交换为授权的第一个访问令牌和刷新令牌），使用 DPoP 证明（由客户端的私钥签名的 JWT，其中包含公钥的副本等）将公钥绑定到授权。
- 使用以这种方式获得的访问令牌向资源服务器发出的请求还必须包括 DPoP 证明标头，以持续证明拥有授权建立期间使用的私钥。这是针对每个 API 请求完成的。资源服务器需要检查访问令牌是否受发送方限制，确认公钥，并在每次 API 调用时验证 DPoP 证明标头。
- 对于公共客户端，到授权服务器令牌端点的后续refresh_token流还必须包含使用初始授权建立期间使用的相同密钥签名的 DPoP 证明。这一点尤为重要，因为刷新令牌通常是长期的，并且也是一种持有者令牌（也就是说，如果你有它，你可以使用它）。授权服务器必须强制对这些刷新令牌流使用 DPoP 证明，并确保通过初始授权建立期间注册的同一公钥进行签名验证。
与任何持有者都可以使用的普通持有者访问令牌不同，基于 DPoP 的访问令牌绑定到最初建立 OAuth 授权的客户端，因为只有该客户端才能使用私钥签署 DPoP 证明。这种方法最大限度地降低了与恶意行为者交易泄露的访问令牌相关的风险。
有关详细信息，请参阅 DPoP RFC 9449 – OAuth 2.0 演示拥有证明 （DPoP）。
4.2 是什么让 DPoP 成为 FIDO 的补充技术？
在建立 OAuth 授权期间，FIDO 可用于防网络钓鱼的最终用户身份验证。客户端在此身份验证后获得的刷新和访问令牌应受到保护，以防止“直接迁移”攻击，就像基于浏览器的应用程序中的会话 cookie 一样。DPoP 是保护这些 OAuth 令牌免遭未经授权的身份验证后使用的推荐解决方案。用于最终用户身份验证的 FIDO 和用于将 OAuth 令牌绑定到客户端设备的 DPoP 相辅相成，以改善厚客户端应用程序中使用的身份的整体安全状况。
4.2.1 DPoP 替代解决方案？
RFC8705 – OAuth 2.0 互向 TLS 客户端身份验证和证书绑定访问令牌描述了一种机制，该机制提供传输器层解决方案，将访问令牌绑定到客户端证书。虽然它已被批准在 FAPI 2.0 中用于开放银行解决方案，但它并不特别适合本机移动应用程序等公共客户。
RFC9421 – HTTP 消息签名定义了用于对 HTTP 消息部分进行签名的应用程序级机制。此规范未定义客户端和验证者之间的密钥建立和共享，尽管这可以在初始授权建立期间以与 DPoP 类似的方式以 信任 方式执行。没有已知的公共规范将 HTTP 消息签名的使用映射到 OAuth 客户端应用程序中发件人约束的持有者令牌的用例。在没有这样的公共规范的情况下，该用例不太可能被广泛采用。
4.2.2 建议
发送方约束令牌是一个好主意，在某些部署中，它们是一项监管要求。例如，许多主权开放银行计划现在都强制要求使用 OAuth 的 FAPI 配置文件。DPoP 是实现此要求的一种相对简单的方法，并且足够灵活，可以涵盖广泛的应用程序客户端类型。也就是说，仍然必须注意遵守 DPoP 的安全考虑。请密切关注 RFC9449的第 11 节，并根据方案对本机或基于浏览器的单页应用程序应用其他应用程序安全策略。请记住，DPoP 仅专注于解决与代币外泄相关的威胁，其中包括恶意行为者的交易和使用。它应被视为 OAuth 应用程序深度防御策略的一部分。
5. 总结
本文的目的是激发人们对不同 Web 安全标准如何组合在一起以及这些标准如何与用户使用 FIDO 身份验证的关系进行思考。标准和标准机构如此之多，以至于通常很难理解哪些在同一领域竞争，哪些相互增强，成为在线应用程序中身份欺诈保护的全面纵深防御战略的一部分。
本文解决了一个特定的、普遍的应用程序安全问题——恶意交易和使用被盗的 cookie 和访问令牌。本文还展示了 DBSC 和 DPoP 等技术如何减轻与令牌盗窃相关的威胁，以及这些技术如何与 FIDO 身份验证相辅相成。DBSC 和 DPoP 与 FIDO 配合使用，可为您的应用程序提供更好的整体身份欺诈保护。
