If you get an OAuth 2.0
client_id along with a matching
secret, you can in theory impersonate the target website.
- You trick the victim into visiting your URL;
- Through the
client_idand the matching OAuth 2.0
secretyou 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_uriparameter'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.
- 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.