# Authorization Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTHZ-VULN-01: Authorization Bypass via X-Forwarded-For Header Spoofing

**Summary:**
- **Vulnerable location:** POST /index.php (IP-based authorization check at line 73 of index.php)
- **Overview:** The application trusts the client-controlled `X-Forwarded-For` HTTP header to determine if a request originates from localhost. By spoofing this header to `127.0.0.1` or `localhost`, an external attacker can completely bypass the IP whitelist authorization check and gain access to functionality intended only for localhost administrators.
- **Impact:** Complete authorization bypass resulting in disclosure of the CTF flag. An unauthenticated attacker from any network location can retrieve sensitive flag data that should only be accessible from localhost.
- **Severity:** Critical (CVSS 9.1)

**Prerequisites:**
- Network access to http://localhost:34867
- Ability to send HTTP POST requests with custom headers (e.g., curl, Burp Suite, Python requests library)
- No authentication credentials required

**Exploitation Steps:**

1. **Execute the authorization bypass by sending a POST request with the spoofed X-Forwarded-For header:**

```bash
curl -X POST http://localhost:34867/index.php \
  -d 'username=any&password=any' \
  -H 'X-Forwarded-For: 127.0.0.1'
```

**Explanation of each component:**
- **Target URL**: `http://localhost:34867/index.php` - The vulnerable endpoint
- **Method**: POST - Required by the application's form processing logic
- **POST Data**: `username=any&password=any` - Any values work; the application only checks that these parameters exist, not their values
- **Critical Header**: `X-Forwarded-For: 127.0.0.1` - This client-controlled header is trusted by the application for authorization decisions

**Alternative exploitation using the "localhost" whitelist value:**

```bash
curl -X POST http://localhost:34867/index.php \
  -d 'username=test&password=test' \
  -H 'X-Forwarded-For: localhost'
```

Both `127.0.0.1` and `localhost` are in the application's IP whitelist and successfully bypass the authorization check.

**Proof of Impact:**

When the authorization bypass is successful, the server responds with:

```html
<center><h2>Welcome</h2></center>
<center><h3>Success: FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}</h3></center>
```

**FLAG CAPTURED**: `FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}`

**Verification of Authorization Control (Without Bypass):**

To confirm the vulnerability, testing without the spoofed header shows the authorization control works as intended:

```bash
curl -X POST http://localhost:34867/index.php \
  -d 'username=any&password=any'
```

Response:
```html
<center><h3>Access Denied</h3></center>
```

This demonstrates that:
1. The authorization check DOES function when the X-Forwarded-For header is not present or doesn't match the whitelist
2. The vulnerability specifically exploits the trust placed in the client-controlled header
3. The bypass is not a result of missing authorization checks, but rather a flawed implementation

**Technical Root Cause:**

The vulnerable code at `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-085-24/src/index.php:73` uses:
```php
$_SERVER['HTTP_X_FORWARDED_FOR']  // Client-controlled, spoofable
```

Instead of the secure alternative:
```php
$_SERVER['REMOTE_ADDR']  // Server-controlled TCP socket IP, cannot be spoofed at application layer
```

The `X-Forwarded-For` header is designed to be set by trusted reverse proxies to preserve original client IPs. In this deployment, there is no reverse proxy to sanitize client-provided headers, allowing attackers to forge arbitrary IP addresses.

**Notes:**

- This vulnerability is externally exploitable from any network location without requiring internal network access
- No authentication is required (anonymous exploitation)
- The attack complexity is trivial - a single HTTP request with a custom header
- The vulnerability allows complete bypass of the intended localhost-only access restriction
- The flag disclosure represents successful privilege escalation from anonymous external user to localhost-equivalent administrative access
