Uploaded image for project: 'PUBLIC - OAuth2'
  1. PUBLIC - OAuth2
  2. OAUTH2-42 REQ029 Authorization Code Flow: Prevent Impersonation of Resource Owner
  3. OAUTH2-97

REQ029.UC002 PREVENT Authorization Code Redirection URI Manipulation (open redirect)

    Details

    • Type: Sub-Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Completed
    • Affects Version/s: None
    • Fix Version/s: 1.0-portal_7.1.0
    • Component/s: None
    • Labels:

      Description

      Undesirable postconditions:

      • Legitimate application user account is attacker’s
      • OAuth2 service user account is victim’s
      • Attacker can impersonate the victim on the OAuth2 service API at any time (until victim disconnects the Legitimate Application using the OAuth2 service user account management) through the legitimate application

       

      Spec reference:

       

      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.

       

      Preconditions:

      • An attacker has an user account at a legitimate app

       

      Event flow:

      1. The attacker initiates 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 client's redirection URI with a URI under the control of the attacker
      2. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client
      3. 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
      4. The victim is then redirected to an endpoint under the control of the attacker with the authorization code
      5. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client
      6. 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)

       

      It is worth noting that the victim will be left hanging or redirected back to the Legitimate Application without access after step 4. So they may get suspicious if they are tech savvy.

       

      Expected outcome:

      • The authorization server should refuse to send the authorization code to the URL under the control of the attacker

       

      Mitigation @ OAuth2 provider:

      • 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
        • How will this help? In the steps above the redirect_uri would point to the attacker’s URL in both cases
        • The protection comes from the fact that the attacker cannot change the hardcoded redirect_uri used by the legitimate website to exchange for an access token
        • However this still doesn’t prevent the attacker from simply exchanging the code for the token using code s/he controls?

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Packages

                  Version Package
                  1.0-portal_7.1.0