Goal:
- 🔍 Understand OAuth account linking vulnerabilities
- 🎯 Exploit missing state parameter validation
- 🔓 Perform CSRF attack on OAuth flow
- 💥 Link victim's OAuth account to attacker's profile
- 👤 Access admin panel and delete
carlos - 🎉 Complete lab
🧠 Concept Recap
Forced OAuth Profile Linking exploits applications that don't properly validate the OAuth state parameter during account linking. When an attacker can trick a victim into completing an OAuth flow initiated by the attacker, the victim's social media account becomes linked to the attacker's application account, allowing the attacker to log in as the victim.
📊 The Vulnerability
OAuth Account Linking Flow:
Normal Account Linking Process:
User with existing account → Wants to link social media
↓
Initiates OAuth flow
↓
Authorizes at OAuth provider
↓
Callback returns to application
↓
Social account linked to user's profile
↓
User can now login with social media
Purpose:
├── Convenience: Single sign-on capability
├── Security: Leverage trusted OAuth providers
└── User experience: Fewer passwords to remember
Security Mechanism (Should exist):
└── State parameter: Prevents CSRF attacks
└── Random token tied to user's session
└── Validated on callback to ensure same userThe Attack Flow:
VULNERABLE FLOW (Missing state validation):
┌────────────────────────────────────────────────────┐
│ 1. Attacker initiates OAuth linking │
│ └── Starts linking their social account │
│ └── GET /auth?client_id=... │
│ └── No state parameter! 🚨 │
└────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────┐
│ 2. Attacker captures OAuth callback URL │
│ └── Intercepts before completing flow │
│ └── URL: /oauth-linking?code=xyz789 │
│ └── Drops request (preserves code) │
└────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────┐
│ 3. Attacker crafts malicious page │
│ └── iframe pointing to /oauth-linking?code=xyz │
│ └── Victim visits attacker's page │
└────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────┐
│ 4. Victim's browser makes request │
│ └── GET /oauth-linking?code=xyz789 │
│ └── Uses victim's session cookie │
└────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────┐
│ 5. Application links accounts (VULNERABLE) │
│ └── No state validation! │
│ └── Attacker's social account │
│ └── Linked to victim's profile! 💥 │
└────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────┐
│ 6. Attacker logs in with social media │
│ └── Uses their own social account │
│ └── Now logged in as admin! 🎯 │
└────────────────────────────────────────────────────┘Why This Works:
Root Cause: Missing CSRF Protection on OAuth Callback
Secure OAuth Flow (Should have):
GET /oauth-linking?code=xyz789&state=random_token_123
Server validates:
├── 1. Is 'state' present?
├── 2. Does 'state' match session?
└── 3. Is 'code' fresh and unused?
If all pass:
└── Link social account to current user ✓
Vulnerable Flow (This lab):
GET /oauth-linking?code=xyz789
Server only validates:
└── Is 'code' valid?
Missing validations:
├── ✗ No state parameter check
├── ✗ No CSRF token validation
└── ✗ Trusts any authenticated request🛠️ Step-by-Step Attack
🔧 Step 1 — Access Lab and Login
- 🌐 Click "Access the lab"
- 👤 Click "My account" in top-right corner
- ✏️ Login with blog credentials:
- Username:
wiener - Password:
peter
4. ✅ Successfully logged in to the blog website
What you see:
My Account Page:
┌──────────────────────────────────────┐
│ Email: wiener@normal-user.net │
│ │
│ [Attach a social profile] │
│ │
│ This feature is currently in beta! │
│ Link your social media account for │
│ a more seamless login experience. │
└──────────────────────────────────────┘
Key observation:
└── "Attach a social profile" button available
└── This is the vulnerable feature!Note: There are two sets of credentials in this lab:
- Blog website:
wiener/peter - Social media profile:
peter.wiener/hotdog
📡 Step 2 — Analyze Account Linking Flow
First, complete the full OAuth linking flow to understand it:
- 🔗 Click "Attach a social profile"
- 🌐 You are redirected to the social media OAuth provider
- ✏️ Login with social media credentials:
- Username:
peter.wiener - Password:
hotdog
4. ✅ Authorize — you'll be redirected back to the blog
5. 🔍 Open Burp Suite → Proxy → HTTP history and study the flow
Look for this request in history:
GET /auth?client_id=xxxxxxxxxxxx&redirect_uri=https://YOUR-LAB-ID.web-security-academy.net/oauth-linking&response_type=code&scope=openid%20profile%20email HTTP/1.1
Host: oauth-YOUR-OAUTH-ID.oauth-server.net
Note: No 'state' parameter! 🚨
└── This is the vulnerability indicator!Key finding:
✓ Authorization URL has NO state parameter
✓ redirect_uri sends code to /oauth-linking (not /oauth-callback!)
✓ This means the callback endpoint is /oauth-linking?code=...
✓ No CSRF protection — exploitable!🎯 Step 3 — Intercept and Capture the /oauth-linking Request
Now intercept the flow to steal the authorization code:
- 🛠️ Open Burp Suite → Proxy → Intercept
- 🔴 Turn Intercept ON
- 🌐 Click "Attach a social profile" again
- 🔄 Keep forwarding requests until you intercept this one:
GET /oauth-linking?code=h8Kd9fJ2mN5pQ7rS4tU6vW1xY3zA0bC8 HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Cookie: session=wiener_session_token⚠️ STOP HERE! Do NOT forward this request!
- 🖱️ Right-click on this request → "Copy URL"
- 📝 Paste the URL somewhere safe — you'll need it shortly
- 🗑️ Click "Drop" to drop the request
- 🔴 Turn Intercept OFF
Why drop it:
Authorization code is single-use:
└── If we forward it → our social account links to our account
└── Code gets consumed
└── Can no longer be used to exploit the victim!
By dropping it:
└── Code remains valid and unused
└── We'll make the victim's browser consume it
└── Linking our social account to their (admin) profile!The copied URL looks like:
https://YOUR-LAB-ID.web-security-academy.net/oauth-linking?code=h8Kd9fJ2mN5pQ7rS4tU6vW1xY3zA0bC8💀 Step 4 — Craft Exploit on Exploit Server
Log out of the blog website first:
- 🚪 Click "Log out"
Access exploit server:
2. 🌐 Click "Go to exploit server" button in lab
Create the exploit payload using the URL you copied:
<iframe src="https://YOUR-LAB-ID.web-security-academy.net/oauth-linking?code=h8Kd9fJ2mN5pQ7rS4tU6vW1xY3zA0bC8"></iframe>How it works:
Exploit mechanism:
└── Victim (admin) visits exploit page
└── iframe silently loads /oauth-linking?code=...
└── Victim's browser sends their session cookie automatically
└── Server receives: attacker's code + admin's session
└── Links attacker's social ID → admin's account! 💥
The application is vulnerable because:
└── No state parameter to validate
└── Server blindly links whatever code arrives
└── To whoever's session cookie is presentPaste this in the Body field of the exploit server:
<iframe src="https://YOUR-LAB-ID.web-security-academy.net/oauth-linking?code=YOUR_AUTHORIZATION_CODE"></iframe>3. 💾 Click "Store"
🚀 Step 5 — Deliver Exploit to Victim
- 🎯 Click "Deliver exploit to victim"
- ⏳ Wait a few seconds
What happens behind the scenes:
Victim (administrator) is logged in on the blog.
1. Victim receives the exploit link and opens it
└── Their browser loads the exploit page
2. iframe loads /oauth-linking?code=ATTACKER_CODE
└── Admin's session cookie sent automatically
└── Cookie: session=admin_session_token
3. Application processes the callback:
└── Exchanges code → gets attacker's social profile (peter.wiener)
└── Links peter.wiener's social ID → admin's account
└── CSRF attack complete! ✓🎉 Step 6 — Log In as Administrator
- 👤 Click "My account" on the blog
- 🔗 Click "Log in with social media" option
- ✏️ Login with social media credentials:
- Username:
peter.wiener - Password:
hotdog
4. ✅ Authorize
What happens:
Social login flow:
1. OAuth provider confirms identity: peter.wiener
└── Returns social ID
2. Blog application looks up social ID in database
└── Finds: peter.wiener → administrator's account
└── (Because of our exploit!)
3. Session created for administrator ✓
└── You're logged in as admin! 🎯🏆 Step 7 — Delete Carlos and Solve Lab
- 🌐 Navigate to Admin panel (top navigation)
- 🗑️ Find carlos in the user list
- ❌ Click "Delete" next to carlos
- ✅ Lab solved!
┌─────────────────────────────────────┐
│ ✅ Congratulations! │
│ │
│ You successfully exploited │
│ forced OAuth profile linking │
│ to access the administrator │
│ account and deleted carlos! │
│ │
│ Lab: Forced OAuth profile linking │
│ Status: SOLVED ✓ │
└─────────────────────────────────────┘🔗 Complete Attack Chain
Step 1: Login to blog as wiener (wiener:peter)
└── Understand the account linking feature
↓
Step 2: Complete full OAuth flow once to study it
└── Social media credentials: peter.wiener:hotdog
└── Confirm /auth URL has NO state parameter 🚨
└── Confirm callback goes to /oauth-linking?code=...
↓
Step 3: Turn on Burp Intercept → Click "Attach a social profile"
└── Forward until you see GET /oauth-linking?code=XXXXX
└── Right-click → Copy URL
└── DROP the request (keep code unused!)
↓
Step 4: Log out of blog
└── Go to exploit server
└── Create: <iframe src="/oauth-linking?code=XXXXX">
└── Store exploit
↓
Step 5: Deliver exploit to victim
└── Admin's browser loads iframe
└── Admin's session cookie sent
└── Admin's account links to peter.wiener's social ID ✓
↓
Step 6: Click "Log in with social media"
└── Login with peter.wiener:hotdog
└── Logged in as administrator! 🎯
↓
Step 7: Admin panel → Delete carlos → Lab solved! 🎉⚙️ Understanding the Vulnerability
OAuth State Parameter
Purpose of state parameter:
State Parameter Fundamentals:
Definition:
└── Cryptographically random value
└── Tied to user's session
└── Prevents CSRF attacks on OAuth flow
How it works (SECURE):
1. Application generates random state
└── state = generate_random_token()
2. Store in user's session
└── session['oauth_state'] = state
3. Include in authorization URL
└── GET /auth?client_id=...&state=a7f3d9c2e5b8k1m4n6p9q2r5
4. OAuth provider returns state in callback
└── GET /oauth-linking?code=xyz&state=a7f3d9c2e5b8k1m4n6p9q2r5
5. Application validates state
└── if request_state == session['oauth_state']:
# Proceed with linking
else:
# CSRF attack detected!
abort(403)
Security guarantee:
└── Only the user who initiated OAuth flow
└── Can complete the flow
└── Attackers can't force victims to use attacker's codesThis lab's vulnerability:
Missing state validation:
Authorization URL:
GET /auth?client_id=xxx&redirect_uri=.../oauth-linking
└── No state parameter! ✗
Callback URL:
GET /oauth-linking?code=xyz
└── No state parameter! ✗
Server-side (VULNERABLE):
def oauth_linking(code):
profile = exchange_code(code)
current_user = get_current_user() # from session cookie
# ✗ CRITICAL FLAW: No CSRF protection!
link_profile(current_user, profile)
Attack succeeds because:
├── No state parameter to validate
├── Server trusts any authenticated request
├── Authorization code can come from anyone
└── Attacker's code + Victim's session = Account takeover!Attack Prerequisites
Required conditions:
1. Account linking feature exists
└── "Attach social profile" or similar
2. Missing state parameter
└── Authorization URL has no state
└── OR state not validated on callback
3. Authorization code usable in any session
└── Code from attacker's OAuth flow
└── Can be consumed by victim's session
4. Victim is authenticated
└── Admin must be logged in to have account to link to
5. Attacker can deliver payload to victim
└── Exploit server iframe
Attack fails if:
├── State parameter properly validated ✗
├── Code tied to specific session ✗
├── CSRF tokens required ✗
└── SameSite=Strict cookie attribute ✗Key Indicators of Vulnerability
Vulnerability indicators:
1. Authorization URL analysis:
GET /auth?client_id=xxx&redirect_uri=.../oauth-linking&response_type=code
└── ✗ No state parameter → VULNERABLE!
2. Callback endpoint is /oauth-linking (not /authenticate):
GET /oauth-linking?code=xxx
└── ✗ No state parameter → VULNERABLE!
3. Code works across different sessions:
└── No session-binding on code → VULNERABLE!🛡️ How to Fix (Secure Code)
Fix 1: Implement Proper State Validation
# ✅ COMPLETE SECURE IMPLEMENTATION
import secrets
import time
from flask import Flask, session, request, redirect, abort
@app.route('/oauth-linking')
def initiate_oauth_linking():
# ✅ Generate cryptographically secure random state
state = secrets.token_urlsafe(32)
session['oauth_state'] = state
session['oauth_timestamp'] = time.time()
params = {
'client_id': CLIENT_ID,
'redirect_uri': REDIRECT_URI,
'response_type': 'code',
'scope': 'openid profile email',
'state': state # ✅ Include state!
}
return redirect(f"{OAUTH_PROVIDER}/auth?{urlencode(params)}")
@app.route('/oauth-linking')
def oauth_linking_callback():
code = request.args.get('code')
state = request.args.get('state')
# ✅ VALIDATION: Check state exists and matches session
if not state or state != session.get('oauth_state'):
abort(403, 'CSRF detected: State mismatch')
# ✅ Check not expired
if time.time() - session.get('oauth_timestamp', 0) > 600:
abort(400, 'OAuth session expired')
# ✅ Clear one-time use state
session.pop('oauth_state', None)
session.pop('oauth_timestamp', None)
# Exchange code and link profile
token = exchange_code_for_token(code)
user_info = get_user_info(token['access_token'])
link_social_profile(get_current_user(), user_info)
return redirect('/my-account?success=account_linked')Fix 2: Additional Security Headers
# ✅ SECURITY HEADERS
@app.after_request
def set_security_headers(response):
# ✅ Prevent clickjacking (defeats iframe attacks)
response.headers['X-Frame-Options'] = 'DENY'
response.headers['Content-Security-Policy'] = "frame-ancestors 'none'"
return response
# Configure session cookie securely
app.config.update(
SESSION_COOKIE_SECURE=True,
SESSION_COOKIE_HTTPONLY=True,
SESSION_COOKIE_SAMESITE='Lax', # Blocks cross-site iframe requests
)👏 If this helped you — clap it up (you can clap up to 50 times!)
🔔 Follow for more writeups — dropping soon
🔗 Share with your pentest team
💬 Drop a comment