# Injection Exploitation Evidence

## Classification Summary

All vulnerabilities in the injection exploitation queue have been analyzed and classified. No vulnerabilities could be exploited through external network access to https://inou.com as required by the engagement scope.

## Out of Scope Vulnerabilities (Internal Access Required)

### INJ-VULN-01: Path Traversal in File Upload Processing

**Summary:**
- **Vulnerable location:** POST /dossier/{id}/upload → POST /dossier/{id}/process-imaging
- **Overview:** Sanitization applied to wrong variable (fileName vs relPath) allows arbitrary file write via path traversal
- **Potential Impact:** Arbitrary file write to server filesystem (e.g., `/etc/cron.d/`, `/tmp/`)
- **Severity:** Critical (if exploitable with server access)
- **Classification:** OUT_OF_SCOPE_INTERNAL

**Why This Cannot Be Exploited Externally:**

This vulnerability involves writing files to the server's local filesystem using `os.WriteFile()`. The attack flow is:

1. Upload file with malicious `path` parameter containing `../../../../tmp/malicious.txt`
2. Value stored as `relPath` in database without sanitization
3. Trigger processing endpoint
4. Application retrieves `relPath` from database and uses in `filepath.Join(tempDir, relPath)`
5. File written to traversed path via `os.WriteFile(outPath, content, 0644)`

**The fundamental problem:** The impact occurs entirely on the server's filesystem, not in HTTP responses. To prove this vulnerability works externally, we would need:

- **Option A:** Server filesystem access (SSH/console) to verify files were written to traversed paths
- **Option B:** A secondary vulnerability to read arbitrary files and confirm our payload location
- **Option C:** Observable side effects (e.g., cron execution) that require internal monitoring

**What we CAN observe externally:**
- ✅ HTTP 200 response from upload endpoint
- ✅ HTTP 200 response from processing endpoint
- ✅ File metadata in database (if accessible via API)

**What we CANNOT observe externally:**
- ❌ Whether `../../../../etc/cron.d/backdoor` was actually written
- ❌ Contents of files written to filesystem
- ❌ Whether path traversal succeeded or was blocked by OS permissions
- ❌ Confirmation that arbitrary file write occurred

**Evidence from Code Analysis:**

```go
// File: /repos/inou-portal/portal/upload.go:182-186
// User input accepted without proper validation
relPath := r.FormValue("path")
if relPath == "" {
    relPath = fileName
}
// CRITICAL: filepath.Base() applied to fileName, not relPath
fileName = filepath.Base(fileName)

// File: /repos/inou-portal/portal/upload.go:222
// Unsanitized relPath stored in database
data := UploadData{
    RelPath: relPath,  // <-- UNSANITIZED
    ...
}

// File: /repos/inou-portal/portal/upload.go:451-462
// Retrieved relPath used in file operation
relPath := row.RelPath  // Retrieved from database
outPath := filepath.Join(tempDir, relPath)  // VULNERABLE
if err := os.WriteFile(outPath, content, 0644); err != nil {
    ...
}
```

**Attempted Exploitation Approach (Why It Fails Scope Requirements):**

If we had server access, exploitation would be:

1. Authenticate to application (using backdoor code 250365)
2. POST to `/dossier/{id}/upload` with:
   - `path=../../../../tmp/proof_of_traversal.txt`
   - File content: "Path traversal successful"
3. POST to `/dossier/{id}/process-imaging` to trigger processing
4. **[REQUIRES SERVER ACCESS]** SSH to server and run: `cat /tmp/proof_of_traversal.txt`
5. **[REQUIRES SERVER ACCESS]** Verify file contains expected content

**Why External-Only Testing Cannot Prove This:**

The HTTP responses from both endpoints return success (200 OK) regardless of whether path traversal succeeded:
- Application logs success after calling `os.WriteFile()`
- No error returned to client even if OS blocked write due to permissions
- No API endpoint exists to read arbitrary filesystem paths
- File upload status endpoints only show database metadata, not filesystem state

**Conclusion:**

This is a **valid and critical vulnerability** in the codebase, but it **requires internal server access** (filesystem read/write verification) to demonstrate exploitation. Per the engagement scope requirement that "ALL exploitation attempts MUST be performed against https://inou.com from external network," this vulnerability is classified as **OUT_OF_SCOPE_INTERNAL**.

**Recommendation for Follow-Up:**

If server access becomes available or if the scope expands to include internal testing, this vulnerability should be prioritized for immediate exploitation as it enables:
- Writing to `/etc/cron.d/` for persistent access
- Overwriting configuration files
- Planting web shells in application directories
- Arbitrary code execution via cron jobs

---

## Methodology Notes

**Injection Types Analyzed:**
1. ✅ SQL Injection - All queries use parameterized statements (safe)
2. ✅ Command Injection - Go's exec.Command uses array execution (safe)
3. ✅ Path Traversal - One vulnerability found (OUT_OF_SCOPE_INTERNAL)
4. ✅ Server-Side Template Injection - Templates pre-loaded, no dynamic parsing (safe)
5. ✅ Unsafe Deserialization - Go's JSON library is safe (safe)

**External Testing Limitations:**

Per engagement scope, only vulnerabilities demonstrable through HTTP requests to https://inou.com qualify as exploitable. Vulnerabilities requiring:
- Server filesystem access
- Database console access
- Internal network access
- SSH/shell access

...are classified as OUT_OF_SCOPE_INTERNAL even if they represent critical security issues in the codebase.

**Total Vulnerabilities Analyzed:** 1
**Externally Exploitable:** 0
**Out of Scope (Internal Access Required):** 1