matt
4d60fdd139
Flight-booking app scaffolded from the source running on the GCP host, plus the four-screen frontend and three OWASP attack endpoints (SQLi, reflected XSS, path traversal) built and locally verified against a live uvicorn/vite dev pair. Includes deploy.sh (local build -> ship over ssh -> swap on host) and docs/ carried over from the handoff.
62 lines
3.5 KiB
Markdown
62 lines
3.5 KiB
Markdown
# 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.
|