什么是“代码替换(OAuth 登录)"?威胁? [英] What's "Code substitution (OAuth Login)" threat?

问题描述

来自 OAuth2.0 威胁模型和安全注意事项草案:

4.4.1.13.威胁:代码替换(OAuth 登录)

攻击者可能会尝试登录应用程序或网站使用受害者的身份.依赖身份数据的应用程序由 OAuth 保护的服务 API 提供给登录用户容易受到这种威胁.这种模式可以在所谓的社交登录"场景.

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

作为先决条件，资源服务器提供了一个 API 来获取有关用户的个人信息，可以解释为已获得用户身份.在这个意义上，客户是将资源服务器 API 视为身份"API.一个客户利用 OAuth 获取身份 API 的访问令牌.它然后在身份 API 中查询标识符并使​​用它来查找向上其内部用户帐户数据(登录).客户认为因为它能够获取有关用户的信息，所以用户已通过身份验证.

As a pre-requisite, a resource server offers an API to obtain personal information about a user which could be interpreted as having obtained a user identity. In this sense the client is treating the resource server API as an "identity" API. A client utilizes OAuth to obtain an access token for the identity API. It then queries the identity API for an identifier and uses it to look up its internal user account data (login). The client asssumes that because it was able to obtain information about the user, that the user has been authenticated.

如果客户端使用授权类型code"，攻击者需要从受害者那里收集相应受害者的有效授权码目标客户端应用程序使用的相同身份提供者.这攻击者诱骗受害者登录恶意应用程序(可能对身份提供者来说似乎是合法的)使用相同的身份提供者作为目标应用程序.这导致身份提供者的授权服务器发出授权相应身份 API 的代码.恶意应用程序然后发送将此代码发送给攻击者，从而触发登录过程在目标应用程序中.攻击者现在操纵授权响应并替换他们的代码(绑定到他们的身份)用于受害者的代码.此代码然后由交换访问令牌的客户端，该令牌又被身份接受API 因为观众，相对于资源服务器，是正确的.但是由于身份 API 返回的标识符是由访问令牌中的身份确定(基于受害者的代码)，攻击者登录到目标应用程序在受害者的身份下.

If the client uses the grant type "code", the attacker needs to gather a valid authorization code of the respective victim from the same identity provider used by the target client application. The attacker tricks the victim into login into a malicious app (which may appear to be legitimate to the Identity Provider) using the same identity provider as the target application. This results in the Identity Provider's authorization server issuing an authorization code for the respective identity API. The malicious app then sends this code to the attacker, which in turn triggers a login process within the target application. The attacker now manipulates the authorization response and substitutes their code (bound to their identity) for the victim's code. This code is then exchanged by the client for an access token, which in turn is accepted by the identity API since the audience, with respect to the resource server, is correct. But since the identifier returned by the identity API is determined by the identity in the access token (issued based on the victim's code), the attacker is logged into the target application under the victim's identity.

影响:攻击者获得对应用程序和用户特定的访问权限应用程序中的数据.

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

对策:

• 所有客户端必须在每个请求中指明他们的客户端 ID交换访问令牌的授权码.这授权服务器必须验证特定的授权码已发给特定客户.如果可能的情况下，应事先对客户端进行身份验证.

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

客户端应使用适当的协议，例如 OpenID(参见[openid]) 或 SAML(参见 [OASIS.sstc-saml-bindings-1.1])到实现用户登录.两者都支持观众限制客户.

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

这让我很困惑:«攻击者需要从目标客户端应用程序使用的同一身份提供者那里收集相应受害者的有效授权代码».什么是各自的受害者"，身份提供者"在本次和后续使用中的含义是什么?

This is rather confusing to me: «the attacker needs to gather a valid authorization code of the respective victim from the same identity provider used by the target client application». What's "the respective victim" and what does "identity provider" mean in this and subsequent uses?

整个攻击描述是模糊的.我开始理解为不应该使用OAuth 2.0来实现用户登录"，但这不意味着Facebook等主要平台容易受到攻击吗?究竟易受什么伤害?

The whole attack description is obscure. I came to understand it as "one shouldn't use OAuth 2.0 to implement user login", but wouldn't that mean that major platforms such as Facebook are vulnerable? And vulnerable to what, exactly?

我可能只需要澄清本段中使用的一些术语.

I probably only need a clarification of some of the terms used in this paragraph.

推荐答案

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

I found the answer by myself. The wording in this section is a bit confusing, but the attack is quite simple. "Identity provider" is the name for the resource server used to verify the identity of an user.

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

Basically it's a case of using an authentication code issued for a client application to obtain an access token by a different application. I try to outline the steps in a clearer way.

1. 攻击者注册恶意客户端(例如，注册到 Facebook 的应用).
2. 受害者用户被诱骗使用使用第三方登录"按钮(例如登录 Facebook")登录恶意客户端，从而触发 OAuth 2.0 授权代码流.
3. 恶意客户端获取authorization_code.
4. 攻击者将刚刚获得的 authorization_code 与另一个应用程序结合使用，并以受害者用户的身份获得对该应用程序的访问权限.

仅当 authorization_codes 未绑定到特定客户端时，才能执行第 4 步.颁发给客户端的验证码只能由该客户端使用以获取访问令牌.

Step 4 is only possible if authorization_codes aren't bound to a specific client. Auth codes issued to a client can only be used by that same client to obtain an access token.

当然，Facebook 并不容易受到攻击，因为这只需从授权服务器进行基本检查即可破解.

Of course Facebook is not vulnerable, as this requires only a basic check from the authorization server to defeat.

这篇关于什么是“代码替换(OAuth 登录)"?威胁?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！