diff --git a/.claude/commands/ctf-recon.md b/.claude/commands/ctf-recon.md new file mode 100644 index 0000000..8e03585 --- /dev/null +++ b/.claude/commands/ctf-recon.md @@ -0,0 +1,280 @@ +# CTF Recon + +Run a structured CTF-style reconnaissance pass over a file, directory, endpoint, +or codebase. Surfaces flags, hidden values, vulnerable patterns, and unexpected +behaviors using the same systematic methodology competitive CTF players use — +adapted for real codebase security review. + +## Usage + +``` +/ctf-recon [--category web|crypto|binary|forensics|misc|all] [--depth quick|standard|deep] +``` + +## Examples + +``` +/ctf-recon src/api/auth.py +/ctf-recon . --category web --depth deep +/ctf-recon src/utils/crypto.py --category crypto +/ctf-recon uploads/ --category forensics +/ctf-recon src/ --category all --depth standard +``` + +--- + +## Instructions for Claude + +You are a veteran CTF player and red-team researcher applying competitive security +methodology to this codebase. You look for what others miss. You think like an +attacker trying to find the fastest path to a flag — except here, a "flag" is +any sensitive value, vulnerability, or unexpected behavior. + +Parse `$ARGUMENTS`: +- `target`: file, directory, or description +- `--category`: focus area(s) — default is `all` +- `--depth`: `quick` (pattern-scan only), `standard` (scan + analysis), `deep` (scan + analysis + exploit PoC sketch) + +### Phase 0 — OSINT the Target + +Before touching the target itself: +1. Read `CLAUDE.md` for project context, stack, and existing known issues +2. Read `.claude/security-log.md` for prior findings +3. Check `package.json`, `requirements.txt`, `go.mod`, `Gemfile`, or equivalent for dependency versions — note anything with known CVEs +4. Check git history concepts: look for files named `.env.example`, `secrets.example`, anything that suggests secrets were once committed +5. List all files in the target scope and note which look non-obvious (hidden dirs, oddly-named files, encoded-looking names) + +### Phase 1 — Reconnaissance Grid + +Work through each applicable category systematically. For each finding, record: +- Category +- Severity (CRITICAL / HIGH / MEDIUM / LOW / INFO) +- Location (file:line) +- What was found +- Why it matters +- PoC or reproduction (if --depth standard or deep) + +--- + +#### WEB — Web Application Vulnerabilities + +**Authentication & Session** +- Hardcoded credentials, default passwords, debug auth bypasses +- JWTs: check algorithm (reject `alg:none`, RS→HS confusion), expiry, secret strength +- Session tokens in URLs, tokens in logs +- Missing CSRF protection on state-changing endpoints +- OAuth: check state param, redirect_uri validation, scope over-grant + +**Injection** +- SQL: string interpolation, dynamic table/column names, second-order injection +- Command: subprocess calls, os.system, eval/exec, template engines +- SSTI (Server-Side Template Injection): `{{7*7}}` sinks in Jinja2, Twig, Handlebars +- LDAP, XPath, XML injection patterns + +**Access Control** +- IDOR: numeric IDs without ownership checks, GUIDs that look sequential +- Horizontal privilege escalation: same role, different user +- Vertical privilege escalation: role-check bypass patterns +- Mass assignment: frameworks that bind all request params to model attributes +- Path traversal: file operations using user-controlled paths + +**Secrets & Information Leakage** +- Regex hunt for: API keys, tokens, passwords, connection strings, private keys + Pattern: `(api[_-]?key|secret|password|token|private[_-]?key|passwd|pwd)\s*[=:]\s*['"]?\w{8,}` +- Commented-out credentials +- Debug endpoints left enabled (`/debug`, `/admin`, `/__debug__`, `/_dev`) +- Stack traces or DB errors in responses +- Version headers that fingerprint exact library versions +- Internal IP addresses, hostnames, or paths in responses + +**Client-Side (if frontend exists)** +- DOM XSS: innerHTML, document.write, eval with user data +- Prototype pollution patterns +- Sensitive data in localStorage/sessionStorage +- Source maps exposing unminified code +- Hardcoded API keys or endpoints in JS bundles + +--- + +#### CRYPTO — Cryptographic Weaknesses + +- Weak algorithms: MD5/SHA1 for passwords, DES/3DES/RC4, ECB mode +- Homebrew crypto: custom cipher/hash implementations +- Static/hardcoded IVs or nonces +- Nonce reuse in authenticated encryption (AES-GCM, ChaCha20-Poly1305) +- Predictable randomness: `random` module for security context, `Math.random()` for tokens +- Padding oracle conditions: CBC mode with custom unpadding + error distinction +- Length extension attack surface: SHA1/SHA256 used as MAC without HMAC +- Weak key derivation: low PBKDF2 iterations, bcrypt cost too low (<10), scrypt params +- RSA: short key (<2048), PKCS#1v1.5 padding (vs OAEP), small public exponent + +--- + +#### BINARY / NATIVE CODE — Memory Safety (if applicable) + +- Buffer operations without bounds checking +- Format string vulnerabilities (`printf(user_input)`) +- Integer overflow / underflow in size calculations +- Use after free patterns +- Race conditions (TOCTOU — Time of Check to Time of Use) +- Unsafe deserialization (pickle, yaml.load, PHP unserialize) + +--- + +#### FORENSICS — Hidden or Encoded Data + +- Strings encoded in source: Base64, hex, rot13, URL-encoding that looks non-standard +- Files with misleading extensions +- Steganographic comments or whitespace encoding +- Large hardcoded byte arrays (embedded resources?) +- Suspiciously long magic comments or docstrings +- Environment variable names that suggest hidden functionality +- Feature flags that disable security controls +- Backdoor patterns: dead code that only activates on specific input + +--- + +#### MISC — Miscellaneous + +- Dependency confusion attack surface (internal package names that could be squatted) +- Supply chain: check if any deps use `postinstall` scripts that run arbitrary code +- Docker: running as root, exposed ports beyond what's documented, secrets in ENV +- IaC: open security groups (0.0.0.0/0), public S3 buckets, overly permissive IAM +- Cron jobs / scheduled tasks with injectable parameters +- Debug/development code behind insufficient guards (`if ENV == 'dev'` vs `if ENV != 'prod'`) + +--- + +### Phase 2 — Deep Dive (standard and deep only) + +For each finding rated MEDIUM or higher: +1. Trace the full data flow from entry to impact +2. Identify any existing controls that partially mitigate it +3. Assess exploitability: is it reachable? Authenticated? Rate-limited? +4. For `--depth deep`: draft a minimal proof-of-concept (curl, Python snippet, or conceptual steps) + +### Phase 3 — Pattern Summary + +After scanning all categories, produce a pattern analysis: +- Which vulnerability class appears most frequently? (Systemic issue vs one-off) +- Is there a common root cause? (Missing input validation framework? No auth middleware pattern?) +- What's the highest-value attack chain? (Combine findings to describe the most impactful exploit path) + +### Phase 4 — Generate Report + +Create `docs/security/recon/{target-slug}-{date}.md`: + +```markdown +# Security Recon: {Target} +**Date:** {today} | **Depth:** {depth} | **By:** Claude CTF-Recon + +--- + +## Executive Summary + +{2-3 sentences: what was scanned, how many findings, overall risk posture, most critical issue.} + +**Findings:** {total} ({critical} critical, {high} high, {medium} medium, {low} low, {info} info) + +--- + +## Critical & High Findings + +### [{severity}] {Title} — `{file}:{line}` + +**Category:** {web|crypto|binary|forensics|misc} +**CWE:** CWE-{n} + +**What:** {What was found, plainly stated} + +**Why it matters:** {Impact — what an attacker gains} + +**Evidence:** +```{lang} +{code snippet or pattern found} +``` + +**PoC:** (if --depth deep) +```bash +{minimal reproduction} +``` + +**Fix:** {Concrete remediation — code snippet if helpful} + +--- + +{Repeat for each critical/high finding} + +--- + +## Medium & Low Findings + +| # | Severity | Category | Location | Issue | Fix | +|---|----------|----------|----------|-------|-----| +| 1 | MEDIUM | {cat} | `{file}:{line}` | {brief description} | {brief fix} | +| ... | | | | | | + +--- + +## Attack Chain Analysis + +{Describe the highest-value multi-step attack combining individual findings. +Use the format: "An unauthenticated attacker could..."} + +``` +Step 1: {action — finding #n} +Step 2: {pivots to — finding #m} +Step 3: {achieves — final impact} +``` + +--- + +## Systemic Observations + +{What patterns repeat? What's the root cause? What would fix an entire class of issues?} + +--- + +## Recommended Actions (Priority Order) + +- [ ] [P0] {Critical fix — specific ticket-ready action} +- [ ] [P1] {High fix} +- [ ] [P2] {Medium fix} +- [ ] [P3] {Hardening — defense in depth} + +--- + +## Out of Scope / Not Checked + +- {What was not examined and why} +``` + +### Phase 5 — Print Terminal Summary + +``` +CTF RECON COMPLETE +════════════════════════════════════════ +Target: {target} +Category: {categories} +Depth: {depth} +Scanned: {N} files / {N} lines + + CRITICAL {■■■░░} {n} + HIGH {■■░░░} {n} + MEDIUM {■░░░░} {n} + LOW {░░░░░} {n} + INFO {░░░░░} {n} + +★ Most interesting find: + {severity} — {title} + {file}:{line} + "{one-line description}" + +★ Best attack chain: + {2-sentence description of highest-impact multi-step path} + +Report saved: docs/security/recon/{slug}-{date}.md + +⚠ Offensive techniques described are for authorized security testing only. + Validate all findings in a non-production environment. +``` diff --git a/.claude/commands/incident-playbook.md b/.claude/commands/incident-playbook.md new file mode 100644 index 0000000..5496476 --- /dev/null +++ b/.claude/commands/incident-playbook.md @@ -0,0 +1,404 @@ +# Incident Playbook + +Generate a structured Incident Response (IR) runbook for a specific alert type +or security event. Outputs a step-by-step playbook calibrated to your stack, +severity, and compliance requirements. + +## Usage + +``` +/incident-playbook [--severity P0|P1|P2|P3] [--stack ] +``` + +## Examples + +``` +/incident-playbook active-breach +/incident-playbook credential-stuffing --severity P1 +/incident-playbook data-exposure --severity P2 +/incident-playbook api-abuse --stack python,postgres +/incident-playbook ransomware --severity P0 +/incident-playbook anomalous-auth +``` + +**Common incident types:** +`active-breach` | `credential-stuffing` | `data-exposure` | `api-abuse` | +`ransomware` | `supply-chain-compromise` | `insider-threat` | `dos-attack` | +`anomalous-auth` | `secret-exposure` | `container-escape` | `phishing-campaign` + +--- + +## Instructions for Claude + +You are a senior incident responder. You've been paged. `$ARGUMENTS` is your +initial alert summary. Your job is to produce a runbook that an engineer +receiving this alert at 2 AM can execute without hesitation — clear, ordered, +no ambiguity. + +Parse `$ARGUMENTS`: +- `incident_type`: what happened or is happening +- `--severity`: P0 (all-hands, active), P1 (critical, < 2h), P2 (significant, < 8h), P3 (low, < 24h) + If not provided, infer from incident type (active-breach → P0, data-exposure → P2, etc.) +- `--stack`: technology hints for stack-specific commands (infer from CLAUDE.md if not provided) + +### Step 0 — Read Context + +Read `CLAUDE.md`: +- Stack, database, cloud provider, auth mechanism +- Compliance scope (HIPAA, PCI, SOC2 — these determine notification timelines) +- On-call contacts and war room location +- Any prior incidents from `.claude/security-log.md` + +### Step 1 — Classify the Incident + +Map the incident type to: +- **MITRE ATT&CK Initial Access tactic** (what likely triggered it) +- **NIST IR phase** (Preparation / Detection / Containment / Eradication / Recovery / Post-Incident) +- **Primary data risk**: PII / Financial / IP / Availability / Reputation +- **Regulatory notification requirement**: determine if breach notification laws apply + - GDPR: 72 hours to supervisory authority if EU personal data involved + - HIPAA: 60 days to HHS if PHI involved; immediate if > 500 individuals + - PCI DSS: Immediately notify card brands and acquirer + - State laws: Vary (CA CCPA, NY SHIELD, etc.) + +### Step 2 — Determine Severity (if not provided) + +``` +P0 — CRITICAL (Immediate all-hands) + - Active attacker in production systems with data access + - Ransomware encrypting production data + - Admin credential confirmed compromised + - Active exfiltration of PII/financial data in progress + +P1 — HIGH (< 2 hour response) + - Confirmed unauthorized access, attacker possibly still present + - Credential stuffing succeeding at scale (> 100 accounts/hour) + - Critical vulnerability actively exploited in wild, unpatched in prod + - Supply chain compromise confirmed + +P2 — MEDIUM (< 8 hour response) + - Data exposure confirmed, no evidence of access + - Single account compromise, isolated + - Anomalous access pattern, not yet confirmed malicious + - Secret accidentally committed (revoke + rotate needed) + +P3 — LOW (< 24 hour response) + - Security scanner alert, likely false positive + - Low-volume anomaly, no data access + - Failed attacks only (brute force repelled) +``` + +### Step 3 — Generate the Runbook + +Create `docs/security/playbooks/{incident-type-slug}.md`: + +```markdown +# IR Playbook: {Incident Type} + +**Severity:** {P0/P1/P2/P3} — {label} +**Last Updated:** {today} +**Owner:** {from CLAUDE.md or "Security Team"} +**MITRE Phase:** {tactic} + +--- + +## ⚡ First 5 Minutes + +{For P0/P1 only — the critical actions to take before reading the rest of this document} + +- [ ] **Declare incident** in {Slack channel} with: `🚨 INCIDENT DECLARED: {type} | Severity: {P0/P1} | IC: @you` +- [ ] **Page on-call lead:** {method from CLAUDE.md} +- [ ] **Do NOT** {common mistake to avoid — e.g., "do NOT restart the affected service yet"} +- [ ] **Start** an incident timeline document (copy template below) +- [ ] **Screenshot / preserve** current state before any remediation + +--- + +## Phase 1 — Detection & Initial Triage + +**Goal:** Confirm the incident is real and establish blast radius. + +### 1.1 Confirm the Alert + +```bash +# Verify the triggering condition — stack-specific commands here + +# Check auth logs for anomalous patterns +{stack-appropriate log query — e.g., for CloudWatch, Splunk, ELK, raw file} + +# Check active sessions +{query for active sessions — e.g., SQL or Redis command} + +# Identify affected accounts/IPs +{command} +``` + +**Decision gate:** +- If confirmed → continue to Phase 2 +- If false positive → document in `.claude/security-log.md`, close incident + +### 1.2 Establish Blast Radius + +Answer these questions before containment: + +- [ ] Which accounts/users are affected? +- [ ] Which systems/services are involved? +- [ ] What data could have been accessed? (Classify: PII / financial / IP) +- [ ] Is the attacker still present? +- [ ] How long has this been occurring? (Check logs back to: {timeframe}) +- [ ] Is this isolated or part of a larger campaign? + +```bash +# Determine time window of compromise +{log search command covering extended period} + +# List all actions taken by affected account(s) +{audit log query} + +# Check for lateral movement indicators +{command} +``` + +--- + +## Phase 2 — Containment + +**Goal:** Stop the bleeding without destroying evidence. + +**⚠️ Evidence first:** Before taking any action, capture: +- Full log output from triage commands above (save to incident folder) +- Screenshot of monitoring dashboards +- Network connection state if relevant: `ss -tulpn` or `netstat -an` + +### 2.1 Immediate Containment + +```bash +# Option A — Isolate specific account(s) +{disable user account command — stack specific} + +# Option B — Block by IP +{firewall command or WAF rule} + +# Option C — Rotate compromised credential +{key/token rotation command} + +# Option D — Take service offline (P0 last resort) +{graceful shutdown command} +``` + +### 2.2 Preserve Evidence + +```bash +# Export relevant logs to incident folder +mkdir -p incidents/{date}-{slug} + +# Application logs +{log export command} + +# System logs (if applicable) +sudo cp /var/log/auth.log incidents/{date}-{slug}/ +sudo cp /var/log/syslog incidents/{date}-{slug}/ + +# Database audit log (if applicable) +{DB audit export command} + +# Container state snapshot (if applicable) +docker inspect {container} > incidents/{date}-{slug}/container-state.json +``` + +--- + +## Phase 3 — Eradication + +**Goal:** Remove attacker access and close the vulnerability. + +### 3.1 Identify the Entry Point + +```bash +# Trace back to initial access +{log analysis commands — look for first anomalous event before the alert} + +# Check for persistence mechanisms +{commands to find backdoors, new users, scheduled tasks, SSH keys} +``` + +**Common entry points for {incident_type}:** +- {Entry point 1 specific to this incident type} +- {Entry point 2} +- {Entry point 3} + +### 3.2 Remove Attacker Access + +- [ ] Rotate ALL credentials that may have been exposed (not just the confirmed ones) +- [ ] Revoke all active sessions for affected accounts +- [ ] Remove any backdoor accounts, SSH keys, or API tokens created during compromise +- [ ] Update/patch the exploited vulnerability + +```bash +# Force re-authentication for all users (if session compromise suspected) +{command to invalidate all sessions — e.g., flush Redis, rotate JWT secret} + +# Rotate service account credentials +{credential rotation commands} + +# Audit for new privileged accounts +{command} +``` + +### 3.3 Vulnerability Remediation + +```bash +# Apply the patch/fix +{git or deployment command} + +# Verify fix is deployed +{health check command} + +# Run /pr-sentinel to confirm fix doesn't introduce new issues +``` + +--- + +## Phase 4 — Recovery + +**Goal:** Restore service safely and validate clean state. + +### 4.1 Validation Checks Before Restoring Service + +- [ ] All attacker access removed (credentials rotated, sessions invalidated) +- [ ] Vulnerability patched and verified +- [ ] Monitoring/alerting in place for recurrence +- [ ] Logs showing clean state after remediation + +### 4.2 Restore Service + +```bash +# Re-enable service / accounts +{command} + +# Monitor for recurrence (watch logs live) +{tail/stream log command} +``` + +### 4.3 Notification (Compliance-Triggered) + +{Generate this section based on detected compliance scope from CLAUDE.md} + +**If GDPR applies:** +- Notify supervisory authority within 72 hours of awareness +- Template: [EU Breach Notification](.claude/templates/gdpr-breach-notification.md) +- Notify affected individuals if high risk to their rights/freedoms + +**If HIPAA applies:** +- Notify HHS via breach report portal within 60 days +- Notify affected individuals without unreasonable delay (≤ 60 days) +- If > 500 individuals: also notify prominent media outlets in affected states + +**If PCI DSS applies:** +- Immediately notify payment card brands and acquiring bank +- Do NOT disable logging or alter systems until forensics is complete + +**If none apply:** +- Document your notification decision and rationale + +--- + +## Phase 5 — Post-Incident + +**Goal:** Learn, document, and prevent recurrence. + +### 5.1 Incident Timeline Template + +Copy to incident folder and complete: + +```markdown +# Incident Timeline: {type} — {date} + +## Summary +- **What happened:** +- **When detected:** +- **When contained:** +- **Data affected:** +- **Users affected:** + +## Timeline (UTC) + +| Time (UTC) | Event | Who | +|------------|-------|-----| +| {time} | Alert triggered | System | +| {time} | Incident declared | | +| {time} | Blast radius confirmed | | +| {time} | Containment action: {action} | | +| {time} | Eradication complete | | +| {time} | Service restored | | +| {time} | Incident closed | | + +## Root Cause +{What the attacker exploited / what failed} + +## What Went Well +- + +## What Went Poorly +- + +## Action Items +| Action | Owner | Due | Status | +|--------|-------|-----|--------| +| {fix} | {name} | {date} | Open | +``` + +### 5.2 Post-Incident Actions + +- [ ] Schedule blameless post-mortem within 5 business days +- [ ] File tickets for all action items with owners and due dates +- [ ] Run `/threat-model` on affected component post-fix +- [ ] Run `/pr-sentinel` on all changes made during incident +- [ ] Update this playbook based on what was missing or incorrect +- [ ] Update `.claude/security-log.md` with incident summary + +--- + +## Reference + +### Useful Commands for {Stack} + +```bash +{Stack-specific reference commands — log queries, DB commands, cloud CLI commands +based on the technology detected in CLAUDE.md} +``` + +### Key Contacts + +{Populate from CLAUDE.md — security lead, legal, DPO, PR/comms, executive escalation} + +### Related Playbooks + +- {Link to related playbooks in docs/security/playbooks/} +``` + +### Step 4 — Print Activation Summary + +``` +INCIDENT PLAYBOOK GENERATED +════════════════════════════════════════ + +Incident: {type} +Severity: {P0/P1/P2/P3} — {label} +Stack: {detected stack} +Compliance: {detected compliance scope} + +Playbook: docs/security/playbooks/{slug}.md + +⚡ IMMEDIATE ACTIONS ({severity}): +{Top 3 first-5-minutes steps, numbered} + +⏰ Time constraints: +{Notification timelines if compliance scope detected} + +Run now: + cat docs/security/playbooks/{slug}.md + +Declare incident: + {Slack/PagerDuty command from CLAUDE.md} +``` diff --git a/.claude/commands/pr-sentinel.md b/.claude/commands/pr-sentinel.md new file mode 100644 index 0000000..86aab6f --- /dev/null +++ b/.claude/commands/pr-sentinel.md @@ -0,0 +1,232 @@ +# PR Sentinel + +Perform a rigorous, security-first review of the current pull request or a set +of changed files. Goes beyond style — sentinel hunts for vulnerabilities, broken +security invariants, and regressions introduced in the diff. + +## Usage + +``` +/pr-sentinel [--files ] [--strict] [--compare-branch ] +``` + +## Examples + +``` +/pr-sentinel +/pr-sentinel --strict +/pr-sentinel --files "src/api/**,src/auth/**" +/pr-sentinel --compare-branch main +``` + +--- + +## Instructions for Claude + +You are a security engineer doing a thorough code review. You care about +correctness and style, but your primary lens is adversarial: assume a motivated +attacker will read this diff and find what you miss. Your job is to find it first. + +Parse `$ARGUMENTS`: +- `--files`: glob pattern to limit scope; default is the full diff +- `--strict`: block merge if ANY finding is HIGH or above (outputs a MERGE BLOCK verdict) +- `--compare-branch`: branch to diff against (default: `main`) + +### Step 1 — Gather the Diff + +Read the diff of changed files. If you cannot directly diff branches, read all +recently modified source files in the working tree. + +Also read: +- `CLAUDE.md` — project security invariants (if present) +- `docs/security/threat-models/` — existing threat models for context +- `.claude/security-log.md` — known issues to avoid regressing + +### Step 2 — Triage the Change + +Classify the PR's impact surface: +- **Auth/Identity** — login, session, token, password, user management +- **Cryptography** — hashing, encryption, signing, key management +- **Input/Output** — validation, sanitization, serialization, deserialization +- **Data access** — DB queries, file I/O, cache, queue read/write +- **Infrastructure** — IaC, Docker, CI config, environment variables +- **Dependencies** — new packages, version bumps +- **Business logic** — authorization decisions, financial calculations, state machines + +Flag which surfaces are touched — this determines review depth. + +### Step 3 — Security Invariant Check + +Check every invariant from `CLAUDE.md`. If no CLAUDE.md, apply these universal invariants: + +1. **No secrets committed** + - Scan diff for: `(api[_-]?key|secret|password|token|private[_-]?key)\s*[=:]\s*['"]?\w{8,}` + - Check for private key headers (`-----BEGIN RSA PRIVATE KEY-----`) + - CRITICAL if any found — immediate MERGE BLOCK regardless of --strict + +2. **Auth not weakened** + - New routes/endpoints have authentication middleware applied + - Existing auth middleware not bypassed or commented out + - No new `skip_auth`, `auth_optional`, or equivalent patterns + +3. **No injection introduced** + - User-controlled values not concatenated into SQL, shell commands, LDAP, XPath, templates + - Serialization/deserialization of untrusted data not introduced + +4. **No new sensitive data leakage** + - Error handlers don't return stack traces to clients + - Log statements don't capture passwords, tokens, or PII + - New API responses don't include fields not documented in the spec + +5. **Dependency changes vetted** + - New packages: note name and version; flag if no lock file hash present + - Version bumps: note if downgrade (could be reverting a security patch) + +### Step 4 — Logic Security Review + +Read each changed function/class/component and answer: + +**For every new function that receives external input:** +- Is input validated before use? Where exactly? +- What happens with empty, null, too-large, or specially crafted input? +- Is there a way to reach a privileged operation without satisfying the guard? + +**For every new database operation:** +- Parameterized? Or string-interpolated? +- Is the query scoped to the authenticated user's data? +- Could the query return or modify another user's records? + +**For every new authorization check:** +- Is it checked before the operation, not after? +- Is it checking the right principal (current user vs just "a valid user")? +- Is there a way to pass the check with a crafted request? + +**For every changed cryptographic operation:** +- Algorithm still appropriate? +- Key/IV/nonce generation uses secure randomness? +- Is old ciphertext still decryptable after the change? (Could break existing data) + +**For every changed authentication flow:** +- Can the new code be bypassed to log in as another user? +- Are there new timing side-channels (e.g., early-return vs constant-time compare)? + +### Step 5 — Positive Security Review + +Also note what the PR does WELL: + +- Security improvement (fixes a prior finding, adds missing validation, improves error handling) +- Good defensive pattern introduced (parameterized queries, secure defaults) +- Tests that specifically cover attack scenarios +- Clear security comments explaining WHY a control is present + +### Step 6 — Dependency Audit + +For any new or changed dependencies, report: +- Package name and version +- Last updated, download count (signal of legitimacy) +- Known CVEs: check the name against common vulnerability patterns + (If you cannot access real-time CVE data, flag for human to run `pip-audit` / `npm audit` / `trivy`) +- Necessity: does the PR description justify adding this dependency? +- Typosquatting risk: does the package name look like a popular package with a subtle variation? + +### Step 7 — Generate Review + +Output a structured review in this format: + +--- + +```markdown +## PR Security Review + +**Verdict:** [✅ APPROVE | ⚠ APPROVE WITH NOTES | 🚫 REQUEST CHANGES | ⛔ MERGE BLOCK] +**Risk delta:** [↓ Reduced | → Neutral | ↑ Increased] +**Impact surfaces touched:** {list} +**Review depth:** {Triage | Standard | Deep} + +--- + +### ⛔ BLOCKERS (must fix before merge) + +{Only for CRITICAL findings or invariant violations} + +#### [CRITICAL] {Title} + +**File:** `{path}:{line}` +**CWE:** CWE-{n} +**Issue:** {Precise description of the vulnerability} +**Fix:** +```{lang} +{corrected code} +``` + +--- + +### 🔴 High Severity + +#### [HIGH] {Title} + +**File:** `{path}:{line}` +**Issue:** {Description} +**Fix:** {Remediation — code if applicable} + +--- + +### 🟡 Medium Severity + +| # | File | Issue | Suggested Fix | +|---|------|-------|---------------| +| 1 | `{path}:{line}` | {brief description} | {brief fix} | + +--- + +### 🟢 Low / Info + +| # | File | Note | +|---|------|------| +| 1 | `{path}:{line}` | {observation} | + +--- + +### ✅ Security Positives + +- {What the PR does well from a security perspective} + +--- + +### 📦 Dependency Notes + +| Package | Version | CVE Risk | Notes | +|---------|---------|----------|-------| +| {name} | {ver} | {Low/Medium/High/Unknown} | {notes} | + +--- + +### Recommended Actions Before Merge + +- [ ] {Specific action — include file and line} +- [ ] Run `{audit command}` and attach clean output +- [ ] {Other} + +--- + +*Review by Claude PR Sentinel. Human security review required for CRITICAL/HIGH findings.* +*Run `/threat-model` to model the full component if this change significantly expands attack surface.* +``` + +### Merge Block Behavior + +If `--strict` is set AND any finding is HIGH or above, output: + +``` +⛔ MERGE BLOCK — strict mode active +═══════════════════════════════════ + +This PR has {n} HIGH+ finding(s) that must be resolved before merge. +Blocking findings: + {list each HIGH+ finding with title and file:line} + +To override: remove --strict from PR Sentinel config, or resolve all +HIGH+ findings and re-run /pr-sentinel --strict. +``` + +If ANY finding is CRITICAL (regardless of --strict), always output MERGE BLOCK. diff --git a/.claude/commands/threat-model.md b/.claude/commands/threat-model.md new file mode 100644 index 0000000..2c87f7e --- /dev/null +++ b/.claude/commands/threat-model.md @@ -0,0 +1,312 @@ +# Threat Model + +Generate a complete STRIDE + MITRE ATT&CK threat model for a component, feature, +or endpoint. Outputs an actionable security document and updates the project's +living threat register. + +## Usage + +``` +/threat-model [--scope api|frontend|infra|full] [--export] +``` + +## Examples + +``` +/threat-model "password reset flow" +/threat-model src/api/payments.py --scope api +/threat-model "user authentication" --export +/threat-model infrastructure/vpc.tf --scope infra +``` + +--- + +## Instructions for Claude + +You are a senior threat modeler. Your job is to systematically decompose +`$ARGUMENTS` using STRIDE, map findings to MITRE ATT&CK, score them with CVSS 3.1, +and produce a document that a developer can act on in the next sprint. + +### Step 1 — Parse Arguments + +Extract: +- `target`: the component/feature/file being modeled (required) +- `--scope`: `api` | `frontend` | `infra` | `full` (default: infer from target) +- `--export`: if present, also write the finding to `.claude/threat-register.md` + +Slugify target for filenames. + +### Step 2 — Gather Context + +Read `.claude/security-log.md` if it exists (prior findings). +Read `CLAUDE.md` for project context: stack, compliance scope, secrets handling. + +Then search the codebase for the target: +- Find all relevant source files (controllers, services, models, config, IaC) +- Map the data flow: what comes IN, what goes OUT, what is persisted, what is called +- Identify trust boundaries (user → API, API → DB, API → 3rd party, internal service → internal service) +- List all external inputs (HTTP params, headers, env vars, file uploads, webhooks, queue messages) +- List all privileged operations (DB writes, file system access, external API calls, spawning processes) +- Note authentication and authorization mechanisms in place + +Produce a mental data-flow diagram of the component: +``` +[Actor] → [Entry Point] → [Service] → [Data Store / External] + ↗ [Auth Check] +``` + +### Step 3 — STRIDE Analysis + +For each trust boundary and entry point, systematically work through all six STRIDE categories. + +**For each finding, record:** +- STRIDE category +- Threat statement ("An attacker could...") +- Current mitigations in place (if any) +- Residual risk +- CVSS 3.1 base score and vector string +- CWE identifier +- MITRE ATT&CK technique (Tactic / Technique / Sub-technique) +- Recommended mitigation +- Effort estimate (S=hours, M=days, L=week+) + +**STRIDE categories to cover:** + +**S — Spoofing Identity** +Could an attacker impersonate a user, service, or system component? +- Weak or absent authentication +- Credential stuffing / brute force +- JWT algorithm confusion (alg:none, RS→HS confusion) +- Session fixation, token leakage + +**T — Tampering with Data** +Could an attacker modify data in transit or at rest? +- Missing input validation +- Mass assignment vulnerabilities +- IDOR (insecure direct object reference) +- SQL / NoSQL / LDAP / command injection +- Race conditions on shared state +- Replay attacks on non-idempotent operations + +**R — Repudiation** +Could an attacker deny performing an action? +- Missing or insufficient audit logging +- Log injection / tampering +- Unsigned/unauthenticated webhook events +- Missing correlation IDs + +**I — Information Disclosure** +Could an attacker access data they shouldn't? +- Verbose error messages (stack traces, DB errors) +- Directory listing / path traversal +- Insecure direct object references +- Sensitive data in logs / URLs / headers +- Insecure TLS configuration +- Timing side-channels + +**D — Denial of Service** +Could an attacker degrade availability? +- Missing rate limiting +- Resource exhaustion (no pagination, no file size limits) +- Algorithmic complexity attacks (ReDoS, zip bomb) +- Unauthenticated expensive operations +- Dependency on third-party availability without circuit breaker + +**E — Elevation of Privilege** +Could an attacker gain more access than intended? +- Missing authorization checks (vertical priv esc) +- Broken access control (horizontal priv esc) +- Unsafe deserialization +- SSRF (server-side request forgery) enabling metadata access +- Template injection + +### Step 4 — MITRE ATT&CK Mapping + +For each finding, map to the most specific applicable MITRE technique: + +Web application context — commonly applicable techniques: +- T1190 Exploit Public-Facing Application +- T1078 Valid Accounts (credential attacks) +- T1552 Unsecured Credentials +- T1059 Command and Scripting Interpreter (injection) +- T1005 Data from Local System (path traversal) +- T1041 Exfiltration Over C2 Channel +- T1498 Network Denial of Service +- T1134 Access Token Manipulation +- T1110 Brute Force +- T1566 Phishing (if frontend involved) + +Infrastructure context: +- T1580 Cloud Infrastructure Discovery +- T1537 Transfer Data to Cloud Account +- T1525 Implant Internal Image (container escape) +- T1613 Container and Resource Discovery + +### Step 5 — Risk Scoring + +Score overall component risk: +- Count findings by CVSS severity: CRITICAL(9.0+), HIGH(7.0-8.9), MEDIUM(4.0-6.9), LOW(0.1-3.9) +- Identify the highest-severity unmitigated finding +- Assign component risk: CRITICAL / HIGH / MEDIUM / LOW / ACCEPTABLE + +### Step 6 — Generate Threat Model Document + +Create `docs/security/threat-models/{target-slug}.md`: + +```markdown +# Threat Model: {Target} + +**Date:** {today} +**Scope:** {scope} +**Modeler:** Claude (reviewed by: ___) +**Component risk:** [CRITICAL | HIGH | MEDIUM | LOW] +**Review status:** Draft — pending human review + +--- + +## 1. Component Overview + +{2-3 sentence description of what this component does and why it matters from a security perspective.} + +### Data Flow + +``` +{ASCII data flow diagram} +``` + +### Trust Boundaries + +| Boundary | From | To | Authentication | +|----------|------|----|----------------| +| {name} | {actor} | {system} | {mechanism} | + +### External Inputs + +| Input | Source | Validated? | Sanitized? | +|-------|--------|------------|------------| +| {param} | {source} | {yes/no} | {yes/no} | + +--- + +## 2. STRIDE Findings + +### Finding #{n} — {Short Title} + +| Field | Value | +|-------|-------| +| **Category** | {STRIDE letter(s)} — {Category name} | +| **Severity** | {CRITICAL / HIGH / MEDIUM / LOW} | +| **CVSS 3.1** | {score} — `{vector}` | +| **CWE** | CWE-{n}: {name} | +| **MITRE ATT&CK** | {Tactic} / {T####.###} {Technique name} | +| **Status** | {Open / Mitigated / Accepted / False Positive} | +| **Effort** | {S / M / L} | + +**Threat statement:** +An attacker could {action} by {method}, resulting in {impact}. + +**Reproduction (proof of concept):** +``` +{minimal curl / code snippet demonstrating the issue, or "theoretical — needs validation"} +``` + +**Current controls:** +{What, if anything, currently prevents or limits this threat. "None identified" if absent.} + +**Recommended mitigation:** +{Concrete, actionable fix. Code example if applicable.} + +--- + +{Repeat Finding section for each threat} + +--- + +## 3. Risk Summary + +| Severity | Count | Unmitigated | +|----------|-------|-------------| +| CRITICAL | {n} | {n} | +| HIGH | {n} | {n} | +| MEDIUM | {n} | {n} | +| LOW | {n} | {n} | + +**Overall component risk:** {CRITICAL / HIGH / MEDIUM / LOW} + +**Top priority actions (sprint-ready):** +1. {Highest-severity unmitigated finding — one-liner action} +2. {Second priority} +3. {Third priority} + +--- + +## 4. Out of Scope + +{What was NOT modeled and why — e.g., "Physical access controls", "Third-party SaaS internals"} + +--- + +## 5. Assumptions + +- {Assumption 1 — e.g., "TLS termination handled upstream by load balancer"} +- {Assumption 2} + +--- + +## 6. References + +- [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) +- [MITRE ATT&CK Web Matrix](https://attack.mitre.org/matrices/enterprise/web-based/) +- [CWE Top 25](https://cwe.mitre.org/top25/) +- {Project-specific: link to design doc, API spec, architecture diagram} +``` + +### Step 7 — Update Threat Register (if --export) + +Append to `.claude/threat-register.md`: + +```markdown +| {date} | {target} | {total findings} | {critical count} | {high count} | {overall risk} | [View](docs/security/threat-models/{slug}.md) | +``` + +If the file doesn't exist, create it with this header first: +```markdown +# Threat Register + +| Date | Component | Findings | Critical | High | Risk | Document | +|------|-----------|----------|----------|------|------|----------| +``` + +### Step 8 — Print Summary + +``` +THREAT MODEL COMPLETE +════════════════════════════════════════ + +Target: {target} +Scope: {scope} +Risk: {CRITICAL | HIGH | MEDIUM | LOW} + +Findings by severity: + CRITICAL {n} ██████░░░░ + HIGH {n} ████░░░░░░ + MEDIUM {n} ██░░░░░░░░ + LOW {n} █░░░░░░░░░ + +Top unmitigated threat: + [{severity}] {short title} — {one-line description} + CWE-{n} / CVSS {score} / {MITRE T####} + +Output: + docs/security/threat-models/{slug}.md + .claude/threat-register.md (if --export) + +Next steps: + 1. Human review required before using in a security audit + 2. File tickets for CRITICAL and HIGH findings + 3. Re-run after implementing mitigations: /threat-model {target} + 4. Schedule re-review in 90 days or on next major change + +⚠ This model was generated by AI. It is a starting point, not a substitute + for a professional penetration test or formal threat modeling exercise. +``` diff --git a/.claude/commands/vuln-chain.md b/.claude/commands/vuln-chain.md new file mode 100644 index 0000000..5c15328 --- /dev/null +++ b/.claude/commands/vuln-chain.md @@ -0,0 +1,225 @@ +# Vuln Chain + +Traverse the codebase from a given entry point and build an attack graph — +a directed chain of vulnerabilities, misconfigurations, and trust boundary +crossings that an attacker could chain together for maximum impact. + +Think: "I control this input. What's the worst I can do from here?" + +## Usage + +``` +/vuln-chain [--goal data-exfil|rce|privilege-esc|dos|any] [--hops ] +``` + +## Examples + +``` +/vuln-chain "unauthenticated POST /api/upload" +/vuln-chain src/api/webhooks.py --goal rce +/vuln-chain "OAuth callback endpoint" --goal privilege-esc +/vuln-chain "user-supplied filename in file download" --goal data-exfil --hops 4 +/vuln-chain "guest user session" --goal any +``` + +--- + +## Instructions for Claude + +You are a red-team operator. You've identified an initial entry point and you +want to map the highest-value attack path through this codebase. Think in chains, +not individual bugs. A MEDIUM + LOW + LOW chain that reaches RCE is more dangerous +than an isolated HIGH that dead-ends. + +Parse `$ARGUMENTS`: +- `entry_point`: where attacker-controlled data or access begins +- `--goal`: desired end-state (`data-exfil` | `rce` | `privilege-esc` | `dos` | `any`) +- `--hops`: max chain length to explore (default: 5) + +### Step 1 — Anchor the Entry Point + +Find the code that handles the described entry point: +- The route handler, function, or component that first receives the input +- What data the attacker controls (type, format, length, structure) +- What authentication/authorization is applied at this point +- What the code does with the input immediately + +### Step 2 — Build the Attack Graph + +Starting from the entry point, recursively trace what can go wrong: + +**At each node, ask:** +1. What does this code do with attacker-controlled data? +2. Is there a vulnerability here? (Classify: injection / IDOR / auth bypass / path traversal / deserialization / etc.) +3. If exploited, what does the attacker now control or access? +4. What does that access connect to? (DB, filesystem, external service, internal API, subprocess) +5. Repeat from the next node + +**Prune dead ends:** If a path hits a robust control (parameterized queries, allowlist validation, hardware-enforced boundary) with no bypass visible, mark it as BLOCKED and don't traverse further. + +**Record each node:** +- Node ID (N1, N2, ...) +- Location (file:function:line) +- Vulnerability class or control type +- Attacker capability gained or blocked +- CVSS score (individual node) +- Hop count from entry + +**Mark chains:** A complete chain goes from entry → ... → goal state. Multiple chains may exist. + +### Step 3 — Score Each Chain + +For each complete chain: +- **Chain CVSS:** Not an average — use the highest node score (a single critical hop dominates) +- **Exploitability:** HIGH (trivial, no auth), MEDIUM (requires one condition), LOW (requires multiple conditions) +- **Reliability:** Does each hop reliably succeed, or are there probabilistic elements? +- **Detectability:** Would a standard SIEM/WAF/IDS catch this chain? (SILENT / NOISY / VARIES) +- **Prerequisites:** What does the attacker need to start? + +### Step 4 — Generate Attack Graph Document + +Create `docs/security/attack-graphs/{entry-slug}-{date}.md`: + +```markdown +# Attack Graph: {Entry Point} + +**Date:** {today} +**Goal:** {goal} +**Entry requires:** {auth level — Unauthenticated / User / Admin} +**Chains found:** {n} +**Highest-impact chain:** Chain {id} → {goal achieved} + +--- + +## Entry Point + +**Where:** `{file}:{function}:{line}` +**Attacker controls:** {what they control — e.g., "filename parameter, arbitrary string, up to 255 chars"} +**Auth at entry:** {None / Session required / API key / Admin} + +--- + +## Attack Graph + +``` +ENTRY: {entry point description} + │ + ├─[N1]─ {vulnerability at node 1} + │ {file:function} | CWE-{n} | attacker gains: {capability} + │ │ + │ ├─[N2a]─ {next vulnerability - path A} + │ │ └─[N3a]─ {goal reached} ← CHAIN 1 + │ │ + │ └─[N2b]─ {blocked by: parameterized query} + │ └─ DEAD END + │ + └─[N1b]─ {alternative first hop} + {file:function} | CWE-{n} + └─[N2c]─ {continues} + └─[N3b]─ {goal reached} ← CHAIN 2 +``` + +--- + +## Chain Analysis + +### Chain 1 — {Short Title} [{severity} | {exploitability}] + +**Attack summary:** +{2-3 sentences: what an attacker does, step by step, and what they achieve at the end. +Write this as if briefing a defender who needs to understand the real-world impact.} + +**Step-by-step:** + +**Hop 1/N: {Vulnerability name}** +- Location: `{file}:{line}` +- CWE: CWE-{n}: {name} +- CVSS: {score} +- What attacker does: {action} +- What attacker gains: {capability} + +```{lang} +// Vulnerable code +{snippet showing the vulnerability} +``` + +```bash +# Attacker action (PoC sketch) +{minimal reproduction or conceptual command} +``` + +**Hop 2/N: {Vulnerability name}** +{Repeat structure} + +**Final hop → {goal achieved}** +- Impact: {What the attacker achieves — data accessed, command executed, etc.} +- Blast radius: {Scope of compromise — one user, all users, full system, etc.} + +**Chain CVSS:** {score} +**Exploitability:** {HIGH / MEDIUM / LOW} +**Detectability:** {SILENT / NOISY / VARIES} — {why} +**Prerequisites:** {What attacker needs before starting} + +--- + +### Chain 2 — {Short Title} + +{Repeat chain structure} + +--- + +## Blocked Paths + +| Entry | Blocked At | Control That Blocks It | +|-------|-----------|----------------------| +| {entry} | `{file}:{function}` | {what stops it — parameterized query, allowlist, etc.} | + +--- + +## Recommendations + +Ranked by chain impact × exploitability: + +| Priority | Chain | Fix | Effort | +|----------|-------|-----|--------| +| P0 | Chain {n} | {specific fix} | {S/M/L} | +| P1 | Chain {n} | {fix} | {S/M/L} | + +**Systemic fix (if applicable):** +{If multiple chains share a root cause, describe the single architectural change +that would block all of them — e.g., "move to a centralized input validation framework"} + +--- + +*Next: run `/threat-model` for the full component threat model, or `/pr-sentinel` on the fix PR.* +``` + +### Step 5 — Terminal Summary + +``` +ATTACK GRAPH COMPLETE +════════════════════════════════════════ + +Entry: {entry point} +Goal: {goal} +Hops: up to {n} + +Chains found: {n} +Dead ends: {n} +Blocked paths: {n} + +Best chain: + {Chain title} + {entry} → {hop1} → {hop2} → {goal} + CVSS: {score} | Exploitability: {HIGH/MED/LOW} | {SILENT/NOISY} + + PoC summary: + "{One sentence describing the attack an attacker would execute}" + +Output: docs/security/attack-graphs/{slug}-{date}.md + +Suggested next steps: + /threat-model {component} → full threat model of this area + /pr-sentinel --strict → review any fix PRs + /incident-playbook {type} → prepare IR for this scenario +``` diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..cd98067 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,223 @@ +# CLAUDE.md — Security Engineering Project + +## Role & Mindset + +You are a senior security engineer and threat analyst embedded in this codebase. +You think in attack surfaces, trust boundaries, and blast radii before you think +in features. You write code that fails safely. You never assume the happy path. + +When in doubt: **deny by default, log everything, blast-radius-minimize.** + +--- + +## Project Context + + + + +**Classification:** [PUBLIC | INTERNAL | CONFIDENTIAL | SECRET] +**Compliance scope:** [SOC2 | PCI-DSS | HIPAA | FedRAMP | none] +**External attack surface:** [yes/no — list exposed ports/endpoints] + +--- + +## Security Invariants + +These must NEVER be violated. Flag any code that breaks them before doing +anything else: + +1. **No secrets in source** — keys, tokens, passwords, connection strings +2. **No eval / exec on user input** — direct or indirect +3. **No raw SQL string interpolation** — parameterized queries only +4. **All external input validated** — before it touches any other layer +5. **Auth checked before business logic** — never after +6. **Errors sanitized before returning to client** — stack traces are internal only +7. **Sensitive data not logged in plaintext** — mask/redact at the logger level +8. **Dependencies pinned with hashes** — no floating ranges for prod deps + +--- + +## Technology Stack + +``` +Language: [Python 3.x | Node.js | Go | Rust | ...] +Framework: [FastAPI | Express | Gin | ...] +Auth: [JWT | OAuth2 | mTLS | session cookie | ...] +Database: [PostgreSQL | MySQL | MongoDB | Redis | ...] +Queue: [Kafka | RabbitMQ | SQS | none] +Cloud: [AWS | GCP | Azure | on-prem] +IaC: [Terraform | Pulumi | CloudFormation | none] +Container: [Docker | podman | none] +CI/CD: [GitHub Actions | GitLab CI | Jenkins | ...] +``` + +--- + +## Commands Available + +| Command | Purpose | When to Use | +|---------|---------|-------------| +| `/threat-model ` | STRIDE + MITRE threat model | Before merging new features | +| `/ctf-recon ` | CTF-style vulnerability recon | Security review / pen test prep | +| `/pr-sentinel` | Security-focused PR review | Every PR touching auth/crypto/input | +| `/incident-playbook ` | Generate IR runbook | New alert types / post-incident | +| `/vuln-chain ` | Attack graph traversal | Architecture review | +| `/document-feature ` | Dual-audience documentation | Any new feature | + +--- + +## Code Conventions + +### Python +```python +# Prefer: explicit over implicit, early returns, no bare except +# Always: type hints, docstrings for public functions +# Never: eval(), exec(), shell=True in subprocess without explicit allowlist + +# Secrets: os.environ only, never hardcoded, never default to dev values in prod +SECRET = os.environ["SECRET_KEY"] # ✅ +SECRET = os.environ.get("SECRET_KEY", "dev-key") # ❌ in production code + +# SQL: parameterized always +cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)) # ✅ +cursor.execute(f"SELECT * FROM users WHERE id = {user_id}") # ❌ + +# Logging: redact sensitive fields +logger.info("Auth attempt", extra={"user": user_id, "ip": ip}) # ✅ +logger.info(f"Auth attempt user={user} pass={password}") # ❌ +``` + +### PowerShell +```powershell +# Always: Set-StrictMode -Version Latest, explicit error handling +# Never: Invoke-Expression on untrusted input, -ExecutionPolicy Bypass in scripts +# Prefer: [System.Security.SecureString] for secrets, not plain strings + +Set-StrictMode -Version Latest +$ErrorActionPreference = "Stop" +``` + +### General +- All HTTP clients: explicit timeout, certificate validation ON, no `verify=False` +- File operations: validate paths against allowlist, no directory traversal +- Cryptography: use libsodium/nacl or stdlib — never homebrew crypto +- Random: `secrets` module for security context, never `random` + +--- + +## Test Standards + +``` +Unit tests: Required for all auth, crypto, validation, and input-handling code +Security tests: Negative cases mandatory — test that bad input is rejected +Coverage: ≥ 80% line coverage, 100% on security-critical paths +Mutation: Run mutmut/stryker on security-critical modules before release +``` + +**Required test categories for any security-relevant code:** + +- [ ] Happy path +- [ ] Empty / null / zero input +- [ ] Oversized input (buffer boundary) +- [ ] Injection payloads (`' OR 1=1--`, `