security-mcp 1.1.3 → 1.3.1

package/skills/anti-replay-tester/SKILL.md

@@ -193,3 +193,109 @@ const paymentIntent = await stripe.paymentIntents.create(
 - `requiredActions`: ordered action list
 - `complianceImpact`: framework mappings
 - `beyondSkillMd`: true if finding goes beyond the SKILL.md mandate
+- `intelligenceForOtherAgents`: structured hints for downstream agents (see schema below)
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "JWT with no jti and 24h expiry — stolen token has full replay window", "exploitHint": "Capture token from network log; replay raw Authorization header until expiry" }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "HMAC-SHA256 webhook signature without timestamp binding", "location": "src/webhooks/handler.ts" }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "Replay of signed S3 presigned URL beyond expiry window via missing server-side nonce check", "escalationPath": "Replayed presigned URL → S3 read of other-tenant objects if bucket policy is broad" }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["PCI-DSS Req 8.3.9", "SOC2 CC6.1"], "releaseBlock": true }]
+  }
+}
+```
+
+## §EDGE-CASE-MATRIX
+
+The 5 anti-replay attack cases that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | JWT replay after logout via a second session | Revocation check is scoped to the session that issued the token; a token captured before logout on device A remains valid on device B until natural expiry | Issue JWT on session A; log out session A; replay raw `Authorization: Bearer <token>` from a fresh client — should reject with 401 |
+| 2 | Webhook event ID collision across environments | Dev and staging share the same event-ID namespace; seen-nonce table is not environment-scoped, so a prod event ID replayed in staging is silently dropped (or vice-versa) | Send a webhook with `id=evt_prod_123` to the staging endpoint; verify the nonce store is keyed as `env:eventId`, not bare `eventId` |
+| 3 | OAuth authorization code reuse on clock-skew boundary | Code was issued at T; validator uses server clock T+6s; 5-minute code window has expired but the off-by-one in `<=` vs `<` accepts it; a second use 1 ms later also succeeds | Replay the same authorization code twice in rapid succession from different IPs — both should succeed if the comparison is `exp >= now` instead of `exp > now` |
+| 4 | SAML assertion replay via XML signature wrapping | The signature is valid on the outer element; a scanner checks signature validity, not that the signed element and the processed element are the same node | Use a signature-wrapping tool (e.g., saml-raider) to duplicate the assertion node; submit; verify the IdP or SP rejects a duplicate `InResponseTo` or missing `jti`/`ID` tracking |
+| 5 | Idempotency key fixation by attacker-controlled client | Attacker knows the key pattern (`userId_orderId_timestamp`); they pre-send a request with the same predicted key and a lower amount; the legitimate retry is deduplicated against the fraudulent first request | Generate the idempotency key server-side using a cryptographically random component the client cannot predict; confirm client-supplied keys are rejected or ignored |
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that anti-replay defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to Anti-Replay | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | HMAC-SHA256 webhook signatures and JWT HMAC-HS256 are not broken by Shor's algorithm, but RSA/ECDSA-signed JWTs (RS256, ES256) will be; captured tokens signed today can be forged in the post-CRQC window | Inventory all RS256/ES256 JWTs; migrate long-lived signing keys to ML-DSA (FIPS 204); prefer short-expiry tokens to minimise the harvest-now-replay-later window |
+| AI-assisted token capture and replay at scale | 2025–2027 (active) | LLM-assisted attack tooling automates intercepting tokens from mobile app traffic, browser storage, and log files at scale — then bulk-replays them | Enforce jti tracking in Redis with per-token revocation; rotate signing keys on a 90-day schedule; alert on >3 concurrent sessions per user |
+| WebAuthn / Passkey widespread adoption | 2025–2026 | As passkeys replace passwords, the replay attack surface shifts to the challenge-response nonce in the WebAuthn assertion; implementations that reuse challenges are trivially exploited | Validate `challenge` in every WebAuthn assertion against a server-side nonce store with 60-second TTL; never accept a challenge not issued by your server |
+| EU AI Act full enforcement | 2026 | Auth systems powering high-risk AI features must demonstrate replay protection as part of conformity assessment | Document anti-replay controls in system-security plan; map to AI Act Article 9 risk management requirements |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | Replay protection libraries (jose, jsonwebtoken) must appear in SBOM with pinned versions; outdated versions with CVEs become compliance blockers | Generate CycloneDX SBOM per release; track CVE status for all JWT/crypto dependencies; auto-alert on new CVEs in jose, jsonwebtoken, passport-jwt |
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in anti-replay attacks, and what to build to close each gap.
+
+**Gaps that MUST be checked:**
+
+- **jti reuse across microservices with separate Redis clusters**: Each service validates the JWT signature but checks jti in its own local cache; a token can be replayed once per service. Standard SIEM only sees individual service auth events, not cross-service jti fan-out. Need: centralised jti revocation store (shared Redis Sentinel or distributed cache) with a cross-service read; SIEM query correlating the same `jti` value appearing in auth logs for more than one distinct service within the token's validity window.
+
+- **Webhook replay within the timestamp tolerance window**: A 5-minute tolerance window is standard (Stripe uses 300 s). An attacker who captures a signed webhook can replay it up to 299 seconds later and pass all checks if the event-ID nonce store is not consulted. Standard WAF and signature-validation logs show "signature valid" — they do not log nonce-store hits. Need: explicit log event `webhook.nonce_check` (pass/fail) emitted after the nonce lookup, separate from the signature-validation log event; alert on any `nonce_check=fail` that is not preceded by a `signature=fail`.
+
+- **OAuth PKCE code_verifier brute-force**: The authorization code is captured (e.g., via redirect-URI mismatch); the attacker then brute-forces short `code_verifier` values. No rate limiting exists on the token endpoint in many implementations. Standard auth logs show token endpoint 400s but not the pattern of repeated attempts per `code`. Need: rate limit the token endpoint per `code` value (max 3 attempts); alert on >1 failed token exchange for the same `code`.
+
+- **Idempotency key exhaustion / collision DoS**: Attacker sends many requests with the same idempotency key but varying payloads to fill the deduplication store and force legitimate retries to be silently dropped. No log event emitted for dropped-as-duplicate requests in most payment libraries. Need: log every idempotency deduplication event with original request hash vs current request hash; alert when a key is reused with a *different* payload (indicates either a bug or an attack).
+
+- **Cross-agent finding chains invisible to single-agent review**: A missing `jti` finding (anti-replay-tester) combined with a SSRF finding (ssrf-scanner) could allow an attacker to obtain a valid JWT from an internal metadata service and replay it externally. Neither agent alone sees this chain. Need: CISO orchestrator Phase 1 synthesis step — correlate anti-replay findings with credential-exposure findings before Phase 2 penetration testing.
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any anti-replay attack class clean without explicit evidence of checking. For each item, output one of:
+- `CHECKED: [N files] | [patterns used] | CLEAN`
+- `CHECKED: [N files] | [patterns used] | [N findings, all fixed]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+Attack classes that MUST be covered:
+
+| Class | Grep Patterns | Expected Finding ID if Vulnerable |
+|-------|--------------|-----------------------------------|
+| JWT jti tracking | `jti`, `jwt:jti:`, `seenTokens`, `usedJtis` | `ANTI_REPLAY_JWT_NO_JTI` |
+| JWT logout revocation | `revokeToken`, `blacklist`, `redis.*jti`, `signOut` | `ANTI_REPLAY_JWT_NO_REVOCATION` |
+| Webhook timestamp window | `WEBHOOK_TOLERANCE`, `timestamp.*300`, `t=.*,v1=` | `ANTI_REPLAY_WEBHOOK_NO_TIMESTAMP` |
+| Webhook event-ID nonce | `seenNonces`, `processedEvents`, `eventId.*exists` | `ANTI_REPLAY_WEBHOOK_NO_NONCE` |
+| OAuth nonce / PKCE | `nonce`, `code_verifier`, `code_challenge`, `PKCE` | `ANTI_REPLAY_OAUTH_NO_NONCE` |
+| Payment idempotency key | `idempotencyKey`, `Idempotency-Key`, `idem` | `ANTI_REPLAY_PAYMENT_NO_IDEMPOTENCY` |
+| SAML assertion ID tracking | `InResponseTo`, `assertionId`, `saml.*replay` | `ANTI_REPLAY_SAML_NO_ASSERTION_TRACKING` |
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [
+      { "class": "JWT jti tracking", "filesReviewed": 12, "patterns": ["jti", "jwt:jti:", "seenTokens"], "result": "CLEAN" },
+      { "class": "Webhook timestamp window", "filesReviewed": 4, "patterns": ["WEBHOOK_TOLERANCE", "t=.*,v1="], "result": "1 finding, fixed" }
+    ],
+    "filesReviewed": 47,
+    "negativeAssertions": [
+      "JWT jti tracking: pattern 'jti' searched across 12 auth files — present in all token-issuance paths",
+      "Payment idempotency: 'idempotencyKey' found in all 3 payment creation call sites"
+    ],
+    "uncoveredReason": {}
+  }
+}
+```
+
+## BEYOND SKILL.MD — MANDATORY EXPANSIONS
+
+- **JWT Replay via Leaked Refresh Tokens in CI Logs (CVE-2023-49803 / ATT&CK T1552.001):** Long-lived refresh tokens for OAuth2 flows (e.g., GitHub Actions OIDC tokens) are inadvertently printed to CI stdout and harvested from public build logs. The refresh token is replayed hours or days later to mint new access tokens. Test by: grep CI pipeline logs for `refresh_token=`, `Bearer ey`, and `authorization_code=` patterns using `truffleHog` or `gitleaks`; then attempt to exchange a captured refresh token against the token endpoint — a finding is confirmed if the exchange succeeds after the issuing job has completed and the token has not been revoked.
+
+- **AI-Assisted Mass JWT Replay via LLM-Powered Traffic Analysis (ATT&CK T1550.001):** Attacker uses an LLM (e.g., via the Burp AI assistant or a custom GPT-4 script) to parse gigabytes of captured HAR files, extract every `Authorization: Bearer` header, deduplicate by expiry, and queue valid tokens for parallel replay across target endpoints. The attack requires no MITM — only access to exported browser traffic or CDN access logs. Test by: export a browser HAR file containing 50+ authenticated requests; run `python jwt_harvester.py <file.har>` (open-source tool); confirm that at least one replayed token returns HTTP 200 on a state-changing endpoint rather than 401. Finding threshold: any token accepted more than once on a non-idempotent endpoint.
+
+- **SAML Assertion Replay via XML Signature Wrapping (CVE-2017-11427 / ATT&CK T1606.002):** The SP validates the HMAC/RSA signature on the outer `<samlp:Response>` element but processes a cloned `<saml:Assertion>` node injected as a sibling. The signed element and the evaluated element are different DOM nodes — signature is valid, assertion is attacker-controlled. Affects SimpleSAMLphp, OneLogin, and custom SP implementations. Test by: use `saml-raider` (Burp extension) to perform a signature-wrapping mutation on a captured SAML response; inject a second `<saml:Assertion>` with elevated `<saml:Attribute>` values; replay to the SP's ACS endpoint — finding confirmed if the SP accepts the wrapped response and grants elevated privileges. Also verify the SP tracks `InResponseTo` and assertion `ID` attributes against a nonce store.
+
+- **Post-Quantum Harvest-Now-Replay-Later on RS256/ES256 JWTs (NIST IR 8413 / ATT&CK T1040):** Adversaries with access to encrypted traffic archives (nation-state interceptors, long-term PCAP storage) are collecting RS256/ES256-signed JWTs today with intent to forge signatures once a Cryptographically Relevant Quantum Computer (CRQC) breaks RSA/ECDSA (~2028–2032 per NIST). A forged JWT bearing a valid-looking signature can be replayed long after the original user session — especially against services that do not enforce `jti` revocation or tight expiry windows. Test by: audit all JWT-issuing code for `algorithm: RS256` or `algorithm: ES256`; inventory key lengths (`openssl rsa -text -noout -in jwt.pem`); confirm no JWT has expiry >15 minutes. Finding threshold: any RS256/ES256 JWT with `exp - iat > 900` seconds or any service without per-token `jti` revocation is a confirmed post-quantum harvest risk.
+
+- **WebAuthn Challenge Reuse Enabling Credential Replay (CVE-2021-41183 pattern / ATT&CK T1550.002):** Implementations that generate the WebAuthn `challenge` once per user (stored in a persistent session) rather than per-authentication ceremony allow an intercepted `authenticatorAssertionResponse` to be replayed in a new session. The server accepts the response because the stored challenge matches, even though the response was captured from a different browser context. Affects custom WebAuthn RP implementations that skip per-ceremony nonce rotation. Test by: capture a valid `authenticatorAssertionResponse` JSON blob using a MITM proxy; open a second incognito browser session; replay the captured response to the `/api/auth/webauthn/authenticate` endpoint — if the server stores the challenge in a database row (not a one-time Redis key with 60 s TTL), the replay succeeds. Finding threshold: server accepts a replayed `authenticatorAssertionResponse` more than once, or challenge TTL exceeds 120 seconds.
+
+- **Supply Chain Replay via Compromised Idempotency Key Generation in Stripe SDK Fork (CVE-2022-24434 pattern / ATT&CK T1195.001):** A malicious or backdoored fork of `stripe-node` (or `stripe-php`) generates predictable idempotency keys based on `userId + orderId + Math.floor(Date.now() / 1000)` — a pattern that an insider or supply-chain attacker can pre-compute and pre-register with a lower payment amount. When the legitimate payment fires, Stripe deduplicates it against the attacker's pre-registered fraudulent request. Test by: run `npm audit signatures` and `npm ls stripe` to verify the installed package matches the published registry checksum; inspect the idempotency key generation function for entropy — keys must include `crypto.randomBytes(16).toString('hex')`; attempt to pre-register a Stripe `PaymentIntent` with a predicted key and then trigger the legitimate checkout flow — finding confirmed if Stripe returns the fraudulent pre-registered intent.

package/skills/appsec-code-auditor/SKILL.md

@@ -79,8 +79,128 @@ If internet permitted:
 - Fetch GitHub Security Advisories for top dependencies
 - Fetch OWASP Testing Guide for any new test categories since last cached intel
 
+## §ZERO-MISS COVERAGE MANDATE (REQUIRED — RUNS BEFORE SUB-AGENTS)
+
+### 1. Enumerate All Files
+
+Before spawning sub-agents, glob all source files and write `.mcp/agent-runs/{agentRunId}/coverage-manifest.json`. Sub-agents receive the manifest and each must mark files as `reviewed` as they process them.
+
+### 2. Assign File Ownership
+
+Divide the manifest among sub-agents by directory. Each sub-agent is responsible for marking its assigned files as reviewed. No file is left unowned.
+
+### 3. Coverage Checkpoint
+
+After all sub-agents complete, read the manifest. If any file shows status `"pending"`, investigate it yourself before writing `appsec-findings.json`.
+
+### 4. Taint Map
+
+Write `taint-map.json` yourself for all cross-file dataflows detected. Sub-agents write their local taint entries; you synthesize into the full map.
+
+### 5. Negative Assertion Table
+
+Before writing `appsec-findings.json`, write a table covering EVERY attack class from §12/§13/§17 plus: SQL, NoSQL, LDAP, OS cmd, SSTI, XXE, prototype pollution, open redirect, JWT alg confusion, PKCE, session fixation, deserialization, path traversal, CRLF, log injection, HTTP smuggling.
+
+| Attack Class | Files Checked | Patterns Used | Result |
+|---|---|---|---|
+| SQL Injection | N/total | queryRaw, string concat | CLEAN |
+| ... | | | |
+
+### 6. Fix Verification
+
+After sub-agents write fixes, personally re-run the gate check patterns for every HIGH/CRITICAL finding. Do not trust sub-agent confirmation — verify independently.
+
+### 7. Zero Open Findings Rule
+
+You cannot call `orchestration.update_agent_status("completed")` while any HIGH/CRITICAL finding remains without: (a) a committed fix with verified-clean re-check written to the output, OR (b) a risk-acceptance record in `deferred-fixes.json` AND a failing gate check blocking merge.
+
 ## OUTPUT FORMAT
 
 Write `.mcp/agent-runs/{agentRunId}/appsec-findings.json` following the AgentFindingsFile schema.
 Each finding MUST include `exploitChain[]` showing step-by-step reproduction.
 Each remediated finding MUST reference the exact file + line number changed.
+
+Every findings JSON MUST include `intelligenceForOtherAgents`:
+```json
+{
+  "intelligenceForOtherAgents": {
+    "forPentestTeam": [{ "type": "HIGH_VALUE_TARGET", "description": "...", "exploitHint": "..." }],
+    "forCryptoSpecialist": [{ "type": "CRYPTO_WEAKNESS_REFERENCE", "algorithm": "...", "location": "..." }],
+    "forCloudSpecialist": [{ "type": "SSRF_TO_CLOUD_CHAIN", "ssrfLocation": "...", "escalationPath": "..." }],
+    "forComplianceGrc": [{ "type": "COMPLIANCE_BLOCKER", "frameworks": ["..."], "releaseBlock": true }]
+  }
+}
+```
+
+## LEARNING SIGNAL
+
+On every finding resolved, emit:
+```json
+{
+  "findingId": "FINDING_ID",
+  "agentName": "AGENT_NAME",
+  "resolved": true,
+  "remediationTemplate": "one-line description of what was done",
+  "falsePositive": false
+}
+```
+Call `security.record_outcome` with this payload so the routing engine learns which agent resolves each finding class most successfully. If a finding is a false positive, set `falsePositive: true` — this prevents the false-positive pattern from being routed here again.
+
+---
+
+## §EDGE-CASE-MATRIX
+
+The 5 attack cases in this domain that automated scanners and naive manual review universally miss. MANDATORY checks — do not skip.
+
+| # | Edge Case | Why Scanners Miss It | Concrete Test |
+|---|-----------|----------------------|---------------|
+| 1 | Second-order / stored payload executed in different context | Scanner checks input context, not execution context | Store payload safely; trigger in separate request/session |
+| 2 | Unicode normalisation bypass | Regex filters run before normalisation; attacker uses homoglyphs or composed forms | Submit Ⅰ (U+2160) or ＜ (U+FF1C) variants of known-bad strings |
+| 3 | Polyglot payload active in multiple sinks simultaneously | Scanners test one injection class per payload | `'"><script>{{7*7}}</script><!--` — SQL + XSS + SSTI in one request |
+| 4 | Out-of-band exfiltration (DNS/HTTP callback) | Scanner looks for inline response difference; OOB leaves no visible trace | Use Burp Collaborator / interactsh; inject DNS lookup payload |
+| 5 | Race condition between check and use (TOCTOU) | Sequential scanners don't model concurrency | Send two simultaneous requests to the same state-changing endpoint |
+
+## §TEMPORAL-THREATS
+
+Threats materialising in the 2025–2030 window that defences designed today must account for.
+
+| Threat | Est. Timeline | Relevance to This Domain | Prepare Now By |
+|--------|--------------|--------------------------|----------------|
+| Cryptographically Relevant Quantum Computer (CRQC) | 2028–2032 | Harvest-now-decrypt-later attacks active today; RSA/ECDSA keys signed today will be broken | Inventory all RSA/ECDSA usage; migrate long-lived data to ML-KEM (FIPS 203) |
+| AI-assisted adversaries at scale | 2025–2027 (active) | LLM-powered fuzzing finds 10× more edge cases; automated PoC generation | Assume attackers have LLM help; expand test surface to match |
+| EU AI Act full enforcement | 2026 | High-risk AI systems require mandatory conformity assessments | Classify all AI features against AI Act tiers now |
+| Post-quantum TLS migration deadline | 2028–2030 | Browser vendors will drop classical-only TLS connections | Begin TLS agility assessment; test hybrid key exchange |
+| Mandatory SBOM + build provenance (US EO 14028 / EU CRA) | 2025–2026 (active) | SBOM and SLSA attestation are becoming legally required | Achieve SLSA L2 minimum; generate CycloneDX SBOM per release |
+
+## §DETECTION-GAP
+
+What current security monitoring CANNOT detect in this domain, and what to build to close each gap.
+
+**Standard gaps that MUST be checked:**
+
+- **Second-order attack execution**: The storage request looks safe; only the retrieval+execution step is dangerous. Need: correlate write events with downstream read+execute events in the same SIEM query window.
+- **Timing-side-channel leakage**: No log event emitted; only observable as microsecond response-time variance. Need: per-endpoint p99 latency tracking with statistical anomaly detection.
+- **Low-and-slow credential stuffing**: Individually, each request is under rate limits. Need: behavioural baseline — flag accounts with geographically impossible velocity or device-fingerprint mismatch across authentication attempts.
+- **Insider exfiltration via legitimate process**: Authorised exports, reports, and data downloads that individually are permitted but collectively constitute data exfiltration. Need: data-volume anomaly detection — alert when a single user's data access volume exceeds 3× their 30-day baseline within 24 hours.
+- **Cross-agent attack chains**: Phase 1 finding A + Phase 1 finding B = CRITICAL chain invisible to either agent alone. Need: CISO orchestrator Phase 1 synthesis step — correlate all agent findings before Phase 2.
+
+## §ZERO-MISS-MANDATE
+
+This agent CANNOT declare any attack class clean without explicit evidence of checking. For each item, output one of:
+- `CHECKED: [N files] | [patterns used] | CLEAN`
+- `CHECKED: [N files] | [patterns used] | [N findings, all fixed]`
+- `SKIPPED: [reason — must be "not applicable: [evidence]"]`
+
+**Silent skip = FAILED COVERAGE.** The orchestrator flags this as a quality gap.
+
+The output findings JSON MUST include a `coverageManifest` key:
+```json
+{
+  "coverageManifest": {
+    "attackClassesCovered": [{ "class": "SQL Injection", "filesReviewed": 47, "patterns": ["queryRaw", "string concat"], "result": "CLEAN" }],
+    "filesReviewed": 47,
+    "negativeAssertions": ["SQL Injection: queryRaw pattern searched across 47 files — 0 matches"],
+    "uncoveredReason": {}
+  }
+}
+```