Found how to get Oauth2 client_id along matching secret but redirect_uri is whitelisted as requirement. Is it still safe?

Question

If you get an OAuth 2.0 client_id along with a matching secret, you can in theory impersonate the target website.

1. You trick the victim into visiting your URL;
2. Through the client_id and the matching OAuth 2.0 secret you log them in silently in the background; The OAuth 2.0 system redirects to the OAuth 2.0 provider from the first web page, then the OAuth 2.0 provider redirects to the redirect_uri parameter's value (which usually redirects back to the website which initiated the log in). The process sets a session cookie that is used both for authenticating on the website and interacting with the OAuth 2.0 provider's API.
   Depending on the situation, if the user is already logged in on both the real web site and the OAuth 2.0 provider, he/she can be connected to the attacker's website without having to enter any credentials or click on anything. So this works silently like an XSS attack from the user's perspective.
3. Because the user trusts the real website with stolen OAuth 2.0 credentials, he/she gave the website authorization to access OAuth 2.0 provider data. But since the attacker can technically impersonate the target website through a session cookie, the attacker can reuse the authorization trusted on the scope parameter.

But in my case, the OAuth 2.0 provider requires to set up a whitelist for the redirect_uri parameter, so it's impossible to redirect back directly.

While leveraging a full open redirect on the real website might lead to an actual threat, I'm wondering if things remain secure as long as such second vulnerability isn't leveraged according to the rfc6749 specification.

Answer 1

Assuming there are no further logic flaws in the OAuth 2.0 implementation (the implementation is compliant with the specification), without chaining your finding with another issue such as cross-site scripting on the white-listed host that allows you to steal the OAuth token, you are right to assume this scenario is not exploitable.

Section 10.6. of the RFC covers this attack scenario in great detail.

In order to prevent such an attack [authorization code redirection URI manipulation 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.