Flaws in Client Application
Last updated
Last updated
Flaws in the client's application's implementation of OAuth.
The implicit grant type sends access tokens via the browser as a URL fragment.
If the app wants to maintain the session after the user closes the page, it needs to store the current user data, i.e., user ID and access token. It will often submit this data to the server in a POST
request and then assign the user a session cookie.
The problem arises due to the fact that the server does not have any secrets/passwords to compare with the submitted data -> it is implicitly trusted. This request is exposed to attackers via their browser and can be leveraged for user impersonation.
Goal: Log into the application as
carlos
.
The access token provided (Step 3) is not tied with a specific user. If we change the email address, which in this case is used as the user identification, we can authenticate as any other user (Step 5).
The optional, but highly recommended, state
parameter should contain the hash of something tied to the user's session when the OAuth flow is initiated.
If the authorization request does not contain the state
parameter, it means that an attacker can potentially initiate an OAuth flow themselves before tricking a user's browser into completing it (similar to a classic CSRF attack).
Goal: Use a CSRF attack to attach your own social media profile to
admin
and deletecarlos
.
The authorization request has not state
parameter and redirects to /oauth-linking
. After copying the URL, we need to drop the request so the code will remain valid for use.
When the admin loads the iframe
payload, it will complete the OAuth flow resulting in attaching their account to wiener
's social media profile. Thus, when wiener
's social profile is used to log into the application, the account will have elevated privileges.