Web Exploit Triage

Web Exploit Triage

Scope-only discipline: this skill classifies and assesses impact at pattern level. Ready-to-run exploits against production targets without explicit RoE authorization do not belong here. When a PoC is needed, build it in your own lab or in a customer-provided sandbox, not against live infra.

When to use

This skill sits between detection (what did you see?) and remediation (how do you fix it?). It classifies a web vuln candidate into an attack class, verifies exploit assumptions at pattern level, estimates impact, and hands off to the framework skill that delivers the fix.

Triggers on:

• A question like "is this JWT config exploitable", "could this be prototype pollution", "review this OAuth flow for bypass paths", "what is the impact of deserialization on this endpoint", "DOM XSS vs reflected XSS".
• A finding from recon-agent (hypothesis candidate), dast-workflow (scanner output), or security-review (unclear-is-this-exploitable).
• An incoming bug-bounty submission that needs technical triage before a payout decision.
• A post-disclosure CVE with suspected reach into your own stack.

When NOT (handoff)

• Crafting new payloads or assembling chains → payload-crafter, exploit-chain. This skill verifies whether something is exploitable; those build concrete exploits.
• AD-specific vulns (Kerberos, NTLM, delegation) → ad-attacks.
• Dep-vuln triage → cve-triage. Overlap when a dep vuln is a web class (e.g. Jackson deserialization); this skill classifies, that one weighs fix priority.
• Code-level remediation → the framework skill (django-security, spring-security, etc.) or secure-coding.
• API design feedback → api-security.
• Forensics after exploitation → forensics-assist.
• Full pentest report → pentest-reporter.

Approach

Six phases. Phase 2 is the heart: class-specific triage per vuln type. The other phases are the wrapper.

1. Intake and context

Every triage starts with five facts:

• What did you see? A request+response pair, a scanner report, a subtle behavior (redirect pattern), a log entry?
• In scope? RoE check before you do manual verification. On our own ecosystem yes, on a third-party service-embed possibly no.
• Which layer? Client-side (browser context), server-side (auth/API), infrastructure (reverse-proxy behavior).
• Auth context? Pre-auth or auth-gated? A lot of impact hangs on this; the same bug pre-auth is a blocker, auth-only may be a medium.
• Data/privilege access? Which data does it touch, which role can the attacker reach?

If you cannot answer these five, you are not yet doing triage — you are doing recon. Hand back to recon-agent or ask the caller for more context.

2. Class-specific triage

The common web vuln classes this skill covers. For each: what to recognize, how to verify at pattern level (do not weaponize), and which compensating check shapes impact.

JWT flaws — CWE-347 and variants:

• alg: none accepted. Verify via a jwt.io-style decode or jq on base64 chunks. If the server accepts a token with alg: none: blocker candidate.
• Algorithm confusion (RS256 RSA public key as HS256 secret). Server that does not validate that the used alg matches the alg expected in config — pattern: HMAC verify with public key as the secret.
• kid header injection (directory traversal or SQL injection via kid → key lookup). Check whether the kid field flows directly into a file path or query.
• Weak HMAC secret. JWT brute-force with tools like hashcat or jwt_tool — in your own lab, not in production.
• Expired/not-before not verified. Send an old token, see if it is accepted.

Remediation handoff: api-security phase 2, spring-security phase 4 for Java stacks.

Deserialization — CWE-502:

• Java ObjectInputStream, Python pickle.loads, PHP unserialize, Ruby Marshal.load, .NET BinaryFormatter, Node node-serialize. Check the request body for serialized formats (magic bytes \xac\xed for Java, gASV base64-pickle).
• Pattern verification: send a benign deserialized object (e.g. {"simple": "value"}-shaped) and see if it is parsed without schema validation. That is the signal, not an RCE payload.
• Gadget chains (ysoserial for Java) only in a lab — and even there with discipline, not against production.
• Impact assessment: which deserialized type does the target use? Unknown → assume RCE. Documented to be limited to value-types → info disclosure or DoS.

Remediation handoff: secure-coding phase 5, framework-specific skills.

Prototype pollution — CWE-1321, JavaScript-specific:

• Verify with a benign payload: { "__proto__": { "isAdmin": true } } or {"constructor": {"prototype": {"isAdmin": true}}} in the JSON body. See whether a subsequent request behaves as if the prototype injection has been applied.
• Impact is two-step: pollution itself is often info disclosure; exploit depends on which downstream code reads the polluted property. You report "yes, pollution possible"; the exploit-chain skill looks for the gadget path to impact.
• Libraries with historical prototype pollution (lodash pre-4.17.21, jQuery-extend, minimist) flag at detection. See cve-triage.

Remediation: input validation with a JSON schema that rejects __proto__/constructor/prototype; Object.create(null) for untrusted data; Maps instead of objects for lookup tables.

OAuth 2.0 / OIDC misconfigs:

• Redirect-URI bypass: wildcards in redirect_uri registration (https://*.example.com), path traversal in redirect (https://example.com/../attacker.com), fragment appending, URL-parsing differences between authorization server and client.
• State parameter missing: CSRF on the callback possible, verify with a two-browser test in a lab.
• PKCE missing for public clients: authorization-code interception possible.
• Scope elevation: client requests scope X, server returns scope Y without challenge.
• Implicit flow still in use: deprecated in OAuth 2.1, access token in the URL fragment is loggable.
• JWT as access token: fall back on the JWT triage checklist above.

Remediation handoff: api-security phase 2 (implementation).

CSRF and CORS misconfigs:

• CSRF: pre-request body/URL accept without a CSRF token or SameSite cookie. Verify with a cross-origin form POST in a lab.
• CORS: Access-Control-Allow-Origin reflection (every Origin echoed back), wildcard + credentials (browsers block; misconfig signal), null-origin accepted (sandboxed iframes, file:// requests).

DOM XSS and client-side injection:

• Sinks: innerHTML, document.write, eval, setTimeout(string), location.href with user input, postMessage handlers without origin check.
• Verify via devtools inspection or breakpoints on sink functions; no live XSS payloads against production.
• Framework-specific: dangerouslySetInnerHTML (React), v-html (Vue), [innerHTML] (Angular).

SSRF — see api-security phase 5 for the extended treatment. Triage level: check whether a URL field in the request determines the outbound call; in that case the SSRF class is present.

3. Impact assessment (pattern level)

Per confirmed class: what can an attacker achieve? Qualitative, no CVSS here (that comes in pentest-reporter).

• Blocker: pre-auth RCE, auth bypass, admin takeover, mass data exfil.
• High: authenticated RCE, IDOR on PII/financial, stored XSS in admin, full OAuth account takeover.
• Medium: reflected XSS outside admin context, CSRF on state-changing actions without MFA, session fixation, limited info disclosure.
• Low: missing security header, disclosed framework version without a reachable exploit, weak-but-not-broken crypto.

Compensating controls that lower impact: a WAF rule blocking the pattern, strict input validation cutting off the vector path, network segmentation limiting reachability. Document each one — otherwise the claim is not supported.

4. Reproducible PoC discipline

When a PoC is needed (for communication with developers, for a pentest-reporter finding, for retest):

• Scope: only in your own lab or a customer-agreed sandbox. Production PoCs only with explicit written sign-off.
• Payload level: pattern-level examples (<img src=x>, {"__proto__":{"x":1}}, a benign pickle object) versus weaponized (shell-spawning, data exfil). Default: pattern. Weaponized only in a lab.
• Reproduction steps: numbered steps, screenshots with redacted PII, request/response pairs.
• Cleanup: if you created state (test account, test data), specify how the customer cleans it up.

Web exploit triage — <target / finding-ID>
RoE check:     <in scope | out of scope — stopped>
Auth context:  <pre-auth | auth-gated (scope)>
Layer:         <client | server | infra>

Class classification:
  Primary:     <JWT / deserialization / prototype-pollution / OAuth / CSRF / DOM-XSS / SSRF / ...>
  Secondary:   <chain candidates if any>
  CWE:         <N + possibly more>

Verification:
  Pattern test:     <method + result, pattern level>
  Compensating:     <WAF rule / input val / segmentation — effect on impact>
  Weaponized?:      <no, pattern level confirmed | yes in lab, not in report>

Impact:
  Severity:         <blocker | high | medium | low>
  Rationale:        <1–3 sentences>

PoC:
  Available:        <yes/no>
  PoC scope:        <lab | customer sandbox | n/a>
  Reproduction:     <numbered steps, redacted>

Remediation handoff:
  Skill(s):         <framework skill / secure-coding / api-security / cve-triage>
  Retest criteria:  <what you must see to confirm the fix works>

Verification-loop: ...