10.6. 授权码重定向URI伪造(10.6. Authorization Code Redirection URI Manipulation)

10.6. 授权码重定向URI伪造

当使用授权码许可类型请求授权时,客户端可以通过“redirect_uri”参数指定重定向URI。 如果攻击者能够伪造重定向URI的值,这可能导致授权服务器向攻击者控制的URI重定向带有授权码的资源所有者用户代理。

攻击者可以在合法客户端上创建一个帐户,并开始授权流程。当攻击者的用户代理被发送到授权服务器来许可访问权限时,攻击者抓取合法客户端提供的授权URI并用攻击者控制下的URI替换客户端的重定向URI。 攻击者然后欺骗受害者顺着仿冒的链接来对合法客户端授权访问权限。

一旦在授权服务器——受害者被唆使代表一个合法的被信任的客户端使用正常有效的请求——授权该请求时。受害者然后带着授权码重定向到受攻击者控制的端点。通过使用客户端提交的原始重定向URI向客户端发送授权码,攻击者完成授权流程。客户端用授权码交换访问令牌并与将它与攻击者的客户端账号关联,该账户现在能获得受害者授权的(通过客户端)对访问受保护资源的访问权限。

为了防止这种攻击,授权服务器必须确保用于获得授权码的重定向URI与当用授权码交换访问令牌时提供的重定向URI相同。授权服务器必须要求公共客户端,并且应该要求机密客户注册它们的重定向URI。如果在请求中提供一个重定向URI,授权服务器必须验证对注册的值。如果在请求中提供了重定向URI,授权服务器必须对比已注册的。

 

10.6. Authorization Code Redirection URI Manipulation



   When requesting authorization using the authorization code grant
   type, the client can specify a redirection URI via the "redirect_uri"
   parameter.  If an attacker can manipulate the value of the
   redirection URI, it can cause the authorization server to redirect
   the resource owner user-agent to a URI under the control of the
   attacker with the authorization code.

   An attacker can create an account at a legitimate client and initiate
   the authorization flow.  When the attacker's user-agent is sent to
   the authorization server to grant access, the attacker grabs the
   authorization URI provided by the legitimate client and replaces the



Hardt                        Standards Track                   [Page 56]

 
RFC 6749                        OAuth 2.0                   October 2012


   client's redirection URI with a URI under the control of the
   attacker.  The attacker then tricks the victim into following the
   manipulated link to authorize access to the legitimate client.

   Once at the authorization server, the victim is prompted with a
   normal, valid request on behalf of a legitimate and trusted client,
   and authorizes the request.  The victim is then redirected to an
   endpoint under the control of the attacker with the authorization
   code.  The attacker completes the authorization flow by sending the
   authorization code to the client using the original redirection URI
   provided by the client.  The client exchanges the authorization code
   with an access token and links it to the attacker's client account,
   which can now gain access to the protected resources authorized by
   the victim (via the client).

   In order to prevent such an attack, the authorization server MUST
   ensure that the redirection URI used to obtain the authorization code
   is identical to the redirection URI provided when exchanging the
   authorization code for an access token.  The authorization server
   MUST require public clients and SHOULD require confidential clients
   to register their redirection URIs.  If a redirection URI is provided
   in the request, the authorization server MUST validate it against the
   registered value.