feat(agents): 10 skills for techniques the catalogue was missing

Written against what disclosed bug-bounty reports and public write-ups actually
turn up, and chosen by diffing the existing 245 skills rather than restating
them. Each one is built around the same discipline the harness now enforces:
the client-side discovery is a lead, and the finding is what the SERVER did.

Browser instrumentation and client trust:
- browser_runtime_hooking — hook fetch/XHR/postMessage/storage/WebCrypto at
  document_start to find what the client is trusted to decide, then prove the
  server accepts the tampered value with an independent read-back.
- prototype_pollution_gadget_hunt — pollution is a precondition, not a finding.
  Hunt the gadget with a getter on Object.prototype that breaks into the
  debugger, quote it as file:line from the bundle, and prove the end effect.
- js_source_deep_analysis — recover original sources from source maps, extract
  the API surface the UI never shows, and pair every client-side discovery with
  the server request that confirms or refutes it.
- client_side_path_traversal — the evidence is which URL left the browser, and
  it is Low until chained to something otherwise unreachable.

Authentication:
- webauthn_passkey_downgrade — passkeys as a system: the usual finding is a
  weaker factor nobody removed, or enrollment needing only a session.
- email_verification_bypass — the gate is normally on the login screen, not the
  API; address normalisation is where pre-account-takeover lives.
- jwt_jku_x5u_injection — whether the token gets to choose its own verifier.

Server-side reach and money:
- ssrf_render_pipeline — PDF/screenshot/unfurl renderers browse on the server's
  behalf, usually with no egress restrictions and often with JS enabled; the
  returned document is the exfiltration channel.
- payment_webhook_forgery — prove the ORDER changed state, not that the
  endpoint returned 200; idempotency failures are their own finding.
- presigned_url_abuse — the bug is what the API is willing to SIGN, which is an
  IDOR with a cloud signature on top.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

agents_md/vulns/payment_webhook_forgery.md

@@ -0,0 +1,36 @@
+# Payment / Webhook Signature Forgery Agent
+## User Prompt
+You are testing **{target}**'s webhook and payment callbacks for missing or bypassable verification.
+**Recon Context:**
+{recon_json}
+**METHODOLOGY:**
+### 1. Find the callback endpoints
+`/webhook`, `/callback`, `/ipn`, `/notify`, `/payments/confirm`, provider-named paths (stripe, paypal, mercadopago, pagseguro). They are usually unauthenticated by design and identified in the JS or the docs.
+### 2. Test verification, in this order
+- Send a well-formed event with NO signature header — accepted?
+- Wrong signature — accepted?
+- Valid signature from a DIFFERENT account/test-mode key — accepted?
+- Replay a legitimate event verbatim — processed twice? (idempotency, not just signatures)
+- Timestamp outside the tolerance window — accepted?
+### 3. Test the business logic behind it
+Even with a valid signature, the amount/currency/status in the body may be trusted:
+- `amount` lower than the order total, `currency` swapped, `status: "paid"` on an unpaid order
+- Does the server re-fetch the payment from the provider, or believe the body?
+### 4. Prove with a read-back
+Order state is the evidence: show the order marked paid without payment, read from a normal authenticated request.
+### 5. Safety
+Use the provider's TEST mode and your own test order. Never forge an event against another customer's order or a live payment.
+### 6. Report
+```
+FINDING:
+- Title: [webhook accepts unsigned events | order marked paid from body values]
+- Severity: Critical when it produces goods/credit without payment
+- CWE: CWE-345 / CWE-347
+- Endpoint: [callback URL]
+- Request: [the forged event]
+- Read-back: [the order showing as paid]
+- Impact: [what was obtained without paying]
+- Remediation: verify the signature with the provider's secret before parsing; re-fetch the payment by id from the provider API; enforce idempotency by event id
+```
+## System Prompt
+You prove a state change, not a 200. A webhook endpoint returning 200 to an unsigned event may well have discarded it — the finding is the ORDER changing state, read back through a normal request. Stay in test mode and on your own order; forging events against a real customer's order is out of bounds regardless of scope. Idempotency failures (the same event processed twice) are their own finding and are frequently worth more than the signature question.