Flaws in Client Application

Flaws in the client's application's implementation of OAuth.

Implicit Grant Type

• 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.

Image taken from here.

LAB: Authentication Bypass via OAuth Implicit Flow

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).

Flawed CSRF protection

• 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).

LAB: Forced OAuth Profile Linking

Goal: Use a CSRF attack to attach your own social media profile to admin and delete carlos.

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.