> 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-2.md).
# lab-2
## Forced OAuth Profile Linking
**Difficulty:** Practitioner
### Lab Description
This lab gives you the option to attach a social media profile to your account so you can log in via OAuth instead of a username and password. Due to an insecure implementation of the OAuth flow, an attacker can manipulate this functionality to gain access to other users' accounts.
**Objective:** Use a CSRF attack to attach your own social media profile to the admin user's account, then access the admin panel and delete `carlos`.
**Credentials:**
* Blog website: `wiener:peter`
* Social media profile: `peter.wiener:hotdog`
### Root Cause
The client application failed to implement CSRF protection during the OAuth account-linking flow by omitting the `state` parameter. Because the callback request was not tied to the user's original OAuth session, the application could not verify that the authorization response belonged to the user who initiated the flow. As a result, it accepted any valid authorization code — even one generated by a different user.
Vulnerable flow:
```
Attacker starts OAuth
│
Gets Authorization Code
│
Victim loads callback URL
│
Application accepts code
│
Attacker's social account is linked
to victim's account
```
### Exploitation
1. Log in with your own account.
2. Start the **Attach Social Profile** OAuth flow.
3. Intercept the callback request:
```
GET /oauth-linking?code=ATTACKER_CODE
```
4. Copy the full callback URL, then **drop** the request so the authorization code remains unused.
5. Log out.
6. Embed the callback URL in an exploit page and deliver it to the victim:
```html
```
7. The victim's browser requests the callback while authenticated to their account. Because no `state` validation exists, the application links the attacker's social media account to the victim's account.
8. The attacker selects **Log in with social media** and is authenticated as the victim.
9. Access the admin panel and delete `carlos`.
### Lesson Learned
* Always generate a cryptographically random `state` parameter for every OAuth request.
* Store the `state` value in the user's session and verify it when processing the callback.
* Reject OAuth callbacks with a missing, invalid, or mismatched `state`.
* Never assume that a valid authorization code belongs to the current user's session — authorization codes should only be accepted if they are associated with the same session that initiated the OAuth flow.
---
# 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-2.md?ask=&goal=
```
`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.