security - 什么是 "Code substitution (OAuth Login)"威胁？

Question

来自 OAuth 2.0 Threat Model and Security Considerations draft :

4.4.1.13. Threat: Code substitution (OAuth Login)

An attacker could attempt to login to an application or web siteusing a victim's identity. Applications relying on identity dataprovided by an OAuth protected service API to login users arevulnerable to this threat. This pattern can be found in so-called"social login" scenarios.

As a pre-requisite, a resource server offers an API to obtainpersonal information about a user which could be interpreted ashaving obtained a user identity. In this sense the client istreating the resource server API as an "identity" API. A clientutilizes OAuth to obtain an access token for the identity API. Itthen queries the identity API for an identifier and uses it to lookup its internal user account data (login). The client asssumes thatbecause it was able to obtain information about the user, that theuser has been authenticated.

If the client uses the grant type "code", the attacker needs togather a valid authorization code of the respective victim from thesame identity provider used by the target client application. Theattacker tricks the victim into login into a malicious app (which mayappear to be legitimate to the Identity Provider) using the sameidentity provider as the target application. This results in theIdentity Provider's authorization server issuing an authorizationcode for the respective identity API. The malicious app then sendsthis code to the attacker, which in turn triggers a login processwithin the target application. The attacker now manipulates theauthorization response and substitutes their code (bound to theiridentity) for the victim's code. This code is then exchanged by theclient for an access token, which in turn is accepted by the identityAPI since the audience, with respect to the resource server, iscorrect. But since the identifier returned by the identity API isdetermined by the identity in the access token (issued based on thevictim's code), the attacker is logged into the target applicationunder the victim's identity.

Impact: the attacker gains access to an application and user-specificdata within the application.

Countermeasures:

• All clients must indicate their client id with every request toexchange an authorization code for an access token. Theauthorization server must validate whether the particularauthorization code has been issued to the particular client. Ifpossible, the client shall be authenticated beforehand.

• Clients should use appropriate protocol, such as OpenID (cf.[openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) toimplement user login. Both support audience restrictions onclients.

这让我很困惑:“攻击者需要从目标客户端应用程序使用的同一身份提供者那里收集相应受害者的有效授权代码”。什么是“相应的受害者”以及“身份提供者”在此和后续使用中的含义是什么？
整个攻击描述是模糊的。我开始将其理解为“不应使用 OAuth 2.0 来实现用户登录”，但这是否意味着 Facebook 等主要平台容易受到攻击？并且易受什么影响，究竟是什么？
我可能只需要澄清本段中使用的一些术语。

Answer 1

我自己找到了答案。本节中的措辞有点困惑，但攻击非常简单。 “身份提供者”是用于验证用户身份的资源服务器的名称。

基本上，这是使用为客户端应用程序颁发的身份验证代码来获取不同应用程序的访问 token 的情况。我试图以更清晰的方式概述这些步骤。

攻击者注册恶意客户端(例如注册到 Facebook 的应用程序)。

受害者用户被诱骗使用“通过第三方登录”按钮(例如“登录 Facebook”)登录恶意客户端，从而触发 OAuth 2.0 授权码流。

恶意客户端获取授权码。

攻击者将刚刚获得的授权码用于另一个应用程序，并以受害者用户的身份获得对该应用程序的访问权限。

只有在 authorization_codes 未绑定(bind)到特定客户端时，才能执行第 4 步。颁发给客户端的身份验证代码只能由同一客户端用于获取访问 token 。

当然，Facebook 并不容易受到攻击，因为这只需要授权服务器的基本检查即可失败。