OWASP WSTG-ATHZ-05 ~ OAuth weaknesses
Last updated
Last updated
Common terms:
OAuth provider: The third-party service that implementing OAuth that a user wishes to integrate/authenticate with (eg. Google, Github).
Resource Owner: An entity that can grant access to a protected resource (eg. an end-user).
Client: Application requesting access to a protected resource on behalf of the Resource Owner (eg. a web application).
Resource Server: A server hosting protected resource (eg. API to access).
Authorization Server (AS): A server that authenticates the Resource Owner and issues Access Tokens after a proper authorization process.
Authorization Code: A string value used to request for an Access Token.
Access Tokens: A string value used to validate a user's access to protected resource
2.1 The application redirects the user to an Authorization Server (/authorize endpoint).
This process is often displayed as a small pop-up window or redirect initiated by the OAuth provider.
The authorization server URL may look like:
With the following list of parameters:
response_type (eg. code)
state: CSRF token
client_id: uniquely identifies the client application
redirect_uri: the URL that AS will redirect the user
scope: level of access requested
Take note of the
statevalue, as this is an important parameter involved in various CSRF-based attacks discussed below.
2.2 The user will be prompted to login (to verify his/her identity with the protected resource). Following that, a consent screen will be displayed to inform the user of the scope of permissions that the Client application is requesting access to.
If the user accepts the permissions displayed in the consent screen (eg. click the "Authorize" button)
3.1 The Authorization Server will handle the consent internally
This may include a request to an internal endpoint with the state and relevant scope(s).
Example internal request:
3.2 The Authorization Server then redirects the user to the redirect_uri specified earlier, with a generated Authorization Code and the state provided by the client application in the first request.
Example redirect:
The Client application must validate the state to ensure that it matches the one sent in the initial request. This ensures that the response is linked to the Client's initial request
Note: The
stateparameter is important in preventing server-side CSRF vulnerabilities (OWASP WSTG-ATHZ-05 — 05.1-Testing for OAuth server weaknesses)
Refer to the Testing for Consent Page Cross-Site Request Forgery header in the main link above (OWASP WSTG-05.1-Testing for OAuth server weaknesses)
Testing for weaknesses in the Authorization Server:
Improper or missing validation of the state parameter by the Authorization Server.
Predictable or reusedstate parameter value.
The goal of this CSRF-based attack is to trick an Authorization Server into generating an Authorization Code with permissions/scopes defined by an attacker. Typically, the scopes defined will provide the attacker access to sensitive information about a target user.
Steps involved:
The attacker will initiate an OAuth request from within a malicious Client application (eg. /oauth/authorize endpoint).
The attacker will then create a CSRF payload (eg. auto-submitting HTML element using a POST request) containing a malicious URL with the following format:
Not all Authorization Server implementations expose
/oauth/consentas a public endpoint. Some may process it internally.
Parameters in the URL:
a. state: A random/predictable value
b. scope: Desired scope
Note the following:
The attacker is required to start an OAuth request to trick the Authorization Server into believing that an active OAuth process is happening for the malicious Client application.
This URL is similar to the one shown in part 3.1 in the General OAuth flow section above.
The scope defined may contain highly sensitive permissions about the target user
The attacker will trick a target user into visiting the malicious Client application containing the CSRF payload via a web browser — this can be through a social engineering attack.
However, for the attack to work, the target user's browser must be authenticated with the OAuth provider — a valid authenticated session must be established through an OAuth process prior to the attack.
This is due to the nature of web browsers, which sends relevant information regarding the established session with the OAuth provider (eg. cookies, etc.) to identify the current user session
The CSRF attack occurs because the Authorization Server associates the scope processing with the session of the target user, instead of the attacker. This is due to the web browser sending session information about this particular user
Within the Authorization Server logic, without proper validation of the state parameter (see Prevention section below for more information), the server will treat this as a valid OAuth request, and continue the OAuth process by redirecting the user back to the redirect_uri (defined by the attacker in the initial request) with the Authorization Code passed as the parameter.
Since the redirect URI is controlled by the attacker, he/she can retrieve the Authorization Code.
The attacker will be able to use this code to request for an Access Token, and perform actions for the target user within the Client application (controlled by the attacker) with the privileged scopes.
The Authorization Server should validate the following conditions for thestate parameter:
Linked to an existing active OAuth process
Matches the user session.
Uses a cryptographically secure and random algorithm.
This prevents an attacker from hijacking the OAuth flow.
OWASP reference: copy and paste this link on a chromium-based browser to directly view the relevant paragraph.
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#:~:text=When%20a%20client%20issues%20a%20request
Final notes
This attack is categorized as a server-side vulnerability as the vulnerability (lack of state validation, etc.) lies within the Authorization Server itself.
Testing for weaknesses in the Client application:
Missing state parameter in the OAuth authorization server URL.
Improper validation of the state parameter by the Client application.
Predictable or reused state parameter value.
The goal of this CSRF-based attack is to trick a Client application into accepting an Authorization Code tied to an attacker-controlled account, causing the victim's session to be linked to the attacker's OAuth identity.
Steps involved:
The attacker will initiate an OAuth request to retrieve an Authorization Code linked to a malicious account.
The attacker will then craft a CSRF payload (eg. email) with an URL. The format of the URL will be similar to the redirect URI used in an OAuth process.
Example of malicious URL
Note : this URL is similar to the one shown in part 3.2 in the General OAuth flow section above.
A target user will be tricked into sending a GET request to the malicious URL via a web browser (eg. via social engineering)
However, for the attack to work, the target user's browser must be authenticated with the OAuth provider — a valid authenticated session must be established through an OAuth process prior to the attack.
If successful, the Client application will link the victim's session to the attacker's OAuth account.
As a result:
Any subsequent actions performed on the Client application will be linked to the attacker's account instead
This may allow the attacker to view sensitive information about the target user.
The Client application should validate the following conditions for the state parameter:
Linked to an existing active OAuth process.
Matches the one defined in the initial request (eg. /oauth/authorize endpoint).
Uses a cryptographically secure and random algorithm.
Final notes
This attack is categorized as a client-side vulnerability as the vulnerability (lack of state validation, etc.) lies within the Client application itself.
Refer to TryHackMe task 7 for OAuth Vulnerabilities room:
