🛠️ OAuth 2.0
OAuth 2.0 is a widely used framework across websites on the internet. It provides authorization.
Example: it allows a third-party application to access a user's resource (name, age, location, etc.).
Over time, OAuth 2.0 also started to provide authentication (check OpenID Connect).
Example: it allows a user to connect to a third-party website using its social media accounts.
Before understanding the attack vectors, one must understand the basics of OAuth 2.0's mechanism. In order to keep this note short and handy for pentesters, the details will be left out (links to relevant articles will be provided).
The exploitation will depend on the misconfiguration. The next image shows a road that can be followed:
🛠️ Image here.
The misconfiguration types can be better understood with this table:
🛠️ To continue.
For each misconfiguration described below, check the countermeasures presented in the OAuth 2.0 Security Best Current Practice. Even if some misconfigurations are present, the information retrieved from them may not be usable due to countermeasures applied.
In some cases, clients are allowed to use pattern matching in the definition of their redirect URI. The authorization server then verifies that URI. When the URI pattern is not defined properly, and the validation is insufficient, it can lead to an attacker stealing the authorization code or access token.
Upon getting a
client_id, it's possible to test this misconfiguration by providing the authorization server with a fake URI. Depending on the server's HTTP response, misconfiguration is present.In the case where the client is confidential (requiring authentication with the client's secret), one can bypass it by using the Authorization Code Injection attack.
Implicit Grant
To test the redirect URI validation misconfiguration with the implicit grant, the client application needs to hold an open redirect vulnerability. The implicit grant is handy for targeting wildcards on query parameters.
Upon getting a
client_id, it's possible to test this misconfiguration by abusing the open redirect vulnerability and providing the authorization server with a fake URI. Depending on the server's HTTP response, misconfiguration is present.The
referer header could leak important information such as the authorization code, the state, or the access token.When a client gets to a page as a result of a successful authorization request, the tester has to check whether the page:
- contains links to other pages under an attacker's control,
- a third-party content (iframes, images...) that can be loaded.
In a similar way, the tester has to check the same points as the OAuth client, but in the authorization server endpoint.
If an attacker has an access to a victim's browser, it can search for authorization codes and access tokens present in the history of visited URLs.
The goal here is to impersonate a victim by injecting a stolen authorization code into the attacker's own session with the client. Confidential clients are targeted by this attack.
This attack is not possible if:
- The client sends a
code_challengein the Authorization request, which means it's using PKCE to prevent some of the OAuth attacks. - The client in an OpenID Connect layer uses a
nonceto prevents replay attacks.
If the
state parameter is not used in the authentication request, a CSRF attack is possible.
Last modified 3mo ago