# Demo Runbook

> **Status: BUILT, not yet deployed to the GCP host.** All four screens and three
> attack endpoints exist in `backend/` and `frontend/` and were functionally verified
> locally (backend via `uvicorn` + `curl`, frontend via `vite dev` + a browser, talking
> to each other through the same `/api/*` path Caddy proxies in prod — including
> confirming the XSS payload actually executes and the traversal payload actually reads
> a file outside `boarding_passes/`). Not yet shipped with `./deploy.sh` — that must run
> from a real host terminal, not an AI coding-agent sandbox (see CLAUDE.md).

Goal of the demo: type an attack into a believable flight-booking UI, watch Imperva
block it, then show the corresponding event in the Imperva portal. Three attacks, three
*distinct* portal classifications.

## Attack matrix

| # | Attack          | Endpoint                    | Sample payload                     | Expected Imperva portal classification         |
|---|-----------------|-----------------------------|------------------------------------|------------------------------------------------|
| 1 | SQL Injection   | `/api/v1/users?q=`          | `' OR '1'='1`                      | SQL Injection                                  |
| 2 | Reflected XSS   | `/api/v1/search?term=`      | `<script>alert(1)</script>`        | Cross-Site Scripting (XSS)                     |
| 3 | Path Traversal  | `/api/v1/download?file=`    | `../../../../etc/passwd`           | Illegal Resource Access / Directory Traversal  |
| — | (bonus) Cred stuffing | `/api/v1/login`       | repeated login attempts            | Requires a **custom rate policy**, not a signature — not in core demo |

Attacks 1–3 are blocked by Imperva's **default signatures** — no custom rules needed.
The bonus is intentionally excluded from the core demo because it needs a rate policy
configured in Imperva and doesn't produce a clean single-payload block (see
DECISIONS.md D7).

## Frontend screen → attack mapping

Each attack has a natural home in the UI so the demo looks like poking a real product:

- **Passenger / admin lookup** → SQLi search box (`users?q=`)
- **Flight search results** → XSS search field (`search?term=`)
- **Boarding-pass download** → path-traversal file param (`download?file=`)
- **Login** → existing endpoint, kept as the credential-stuffing bonus

## Demo flow (target)

1. Show the app working normally (a legitimate search, a legitimate lookup).
2. For each of the three attacks: enter the payload in its screen → show the request is
   blocked by Imperva (block page / rejected response).
3. Switch to the Imperva portal security dashboard → show the three distinct event
   types logged, one per attack.
4. Reinforce the isolation point: the origin only accepts Imperva CIDRs, so these
   attacks *cannot* reach the app except through the WAF — which is why every one of
   them appears in the portal.

## Pre-demo checklist

- `https://flytoouter.space/` loads with Imperva's trusted edge cert.
- All three endpoints reachable *through* Imperva (legit requests return 200).
- Origin firewall confirmed Imperva-CIDR-only (`allow-imperva-waf`, `tcp:443`).
- DNS for `flytoouter.space` points at Imperva, not the raw origin IP.
- Portal logged-in and on the security events view, filtered to the demo site.

## Notes on portal specifics

Exact event labels and menu paths vary by Imperva account/version. Confirm the live
labels in your portal before presenting and update the classification column above to
match what your account actually shows.