validate-browser-finding

name	validate-browser-finding
description	Run browser-based security validations (CSRF, XSS, clickjacking) against containerized labs using Playwright. Separate from validate-findings which targets K8s operators/containers.

validate-browser-finding

Browser-native validation using an onion-layer methodology: prove the exploit at the innermost layer (app with simple auth), then progressively add real-world defenses (OAuth, proxy, ingress) to confirm each layer's contribution.

Validation Layers (Onion Model)

Layer	What's Running	Proves
1 — Bare app	Target + attacker + Playwright. Simple/no auth.	Exploit works when last line of defense is absent
2 — App + auth	Add real login (form, basic, token).	Exploit survives authenticated sessions
3 — App + auth + middleware	Add oauth-proxy, CSRF tokens, SameSite policy.	Which middleware layer actually blocks the attack
4 — Full stack	Add IdP (Keycloak/Dex), TLS, ingress.	Real-world exploitability with production auth flow

Start at Layer 1. If confirmed, move outward — each layer either blocks the attack (refuted at that layer) or passes it through (confirmed, move to next layer).

Escalation Policy

Finding Severity	Required Validation	Infrastructure
Critical / High	Layer 1-2 (local) + Layer 3-4 (OCP cluster)	docker-compose → deploy to ephemeral OCP in AWS
Medium / Low	Layer 1-2 only	docker-compose (Playwright + containers)

• High/Critical confirmed at Layer 1 → must escalate to OCP to prove real-world exploitability
• Medium/Low confirmed at Layer 1 → sufficient evidence, no cluster needed
• Any severity refuted at Layer 1 → close the finding

Layer 3-4 on OCP (High/Critical only)

For high/critical findings that confirm at Layer 1-2, deploy the target to OCP:

• Same attack plan, different targets.yaml (origins point to cluster Routes)
• OCP provides real oauth-proxy, TLS, ingress, cross-site hostnames
• Use security-testing-clusters for ephemeral provisioning
• No mocking needed — the platform IS the middleware stack

Why Layers Matter

• Layer 1 confirmation + Layer 3 refutation = "the app is vulnerable but middleware saves it" — still worth hardening the app
• Layer 1 confirmation + Layer 4 confirmation = "exploitable in production" — critical
• Layer 1 refutation = "app handles it natively" — close the finding

When to Use

• Web vulnerability requires browser automation (CSRF, XSS, session fixation, clickjacking, CORS)
• Target runs in a container (docker-compose lab)
• Evidence requires screenshots, HAR captures, cookie inspection
• validate-findings or validate-core-ocp reported inconclusive/refuted on HTTP-surface findings due to missing cookie/session round-trip

When NOT to Use

• K8s operator or container-only finding → use validate-findings
• Static analysis sufficient → no live validation needed
• Finding is purely API-level (no browser behavior involved) → use validate-findings with port-forward+http

Current Scope (Layer 1–2)

Auth strategies supported today:

• Form-fill login (username/password fields + submit)
• No-auth targets (public endpoints)

Not yet supported (Layer 3–4 follow-up):

• OAuth/OIDC redirect flows (app → oauth-proxy → IdP → redirect chain)
• Double-submit CSRF token extraction + header replay
• Multi-hop TLS with ingress/route termination

Invocation

cd hybrid-platforms-sec/ai-security-harness/harnessing/validate-browser-finding
python run.py <validation-dir> [--destructive] [--out <dir>]

Prerequisites

1. Lab running: podman compose up -d in the validation directory
2. Python deps from repo root: pip install -r requirements.txt (includes playwright + pyyaml)
3. Playwright browser: playwright install chromium (or use remote container)

Validation Directory Layout

validations/<name>/
├── *-attack-plan.yaml      # Steps to execute
├── *-security-audit.json   # Source finding (optional)
├── targets.yaml            # Scope: origins, credentials, allowed verbs
├── docker-compose.yaml     # Lab: app + attacker + playwright
├── exploit-page/           # HTML PoCs
└── artifacts/              # Output: screenshots, HARs, logs

Output

• <name>-validation.json — structured report (same schema as validate-findings)
• validation-audit.jsonl — append-only execution log
• artifacts/ — screenshots, HAR files, response captures

Adding a New Validation

1. Create validations/<jira-slug>/ with docker-compose, targets, attack plan
2. Write exploit HTML in exploit-page/
3. Run: podman compose up -d && python run.py validations/<jira-slug>/
4. Review artifacts and validation JSON
5. If confirmed at Layer 1, duplicate docker-compose with middleware additions for Layer 2+