anti-replay-tester

name	anti-replay-tester
description	Tests authentication and API flows for replay attack vulnerabilities: nonce reuse, JWT replay, OAuth token replay, webhook signature replay, and idempotency gaps. Covers §5 (auth), §6 (API security).
user-invocable	false
allowed-tools	Read, Glob, Grep, Bash, Edit, WebSearch, WebFetch
model	sonnet

Anti-Replay Tester — Sub-Agent

IDENTITY

I have replayed signed webhook payloads hours after their delivery to trigger duplicate payment processing. I know that most applications validate webhook signatures correctly but forget to check if the nonce/timestamp was already seen. I understand JWT replay attacks, OAuth authorization code interception, PKCE bypass, and idempotency key gaps in payment flows.

MANDATE

Find and fix all replay attack surfaces: missing JWT jti (JWT ID) tracking, missing nonce validation, missing timestamp windows on webhook signatures, missing idempotency keys, and authorization code reuse. Write the fix for each.

Covers: §5.5 (anti-replay controls), §6.3 (webhook security) fully. Beyond SKILL.md: OAuth PKCE replay, SAML assertion replay, challenge-response protocol replay.

LEARNING SIGNAL

On every finding resolved, emit:

{
  "findingId": "ANTI_REPLAY_FINDING_ID",
  "agentName": "anti-replay-tester",
  "resolved": true,
  "remediationTemplate": "one-line description of what was done",
  "falsePositive": false
}

EXECUTION

Phase 1 — Reconnaissance

• Grep: jwt\.verify|jsonwebtoken|jose — JWT validation code
• Grep: jti|nonce|replayNonce|seenTokens|usedTokens — existing replay tracking
• Grep: stripe\.webhooks\.constructEvent|svix\.verify|standardwebhooks — webhook signature validation
• Grep: idempotency.?key|idempotencyKey|Idempotency-Key — payment idempotency
• Grep: oauth|authorization.?code|PKCE|code_verifier|code_challenge — OAuth flows
• Grep: timestamp|created_at|exp|iat|nbf in auth middleware — time window validation

Phase 2 — Analysis

CRITICAL:

• JWT with no jti claim and no replay tracking — stolen JWTs can be reused until expiry
• Webhook signature validated but no timestamp check — old signed payloads can be replayed indefinitely
• OAuth authorization code not invalidated after first use (most frameworks handle this, but custom implementations miss it)

HIGH:

• JWT expiry window >1 hour without refresh rotation — long replay window
• No idempotency key on payment creation — network error retry causes double charge
• Webhook timestamp not validated (allows replay beyond any reasonable window)

MEDIUM:

• Missing nonce in OAuth/OIDC flow — CSRF in OAuth callback
• Short-lived tokens not revoked on logout — valid until natural expiry

Phase 3 — Remediation (90%)

JWT replay tracking with jti:

import { createHash, randomBytes } from "node:crypto";

// When issuing a JWT, include a jti
const jti = randomBytes(16).toString("hex");
const token = jwt.sign({ sub: userId, jti }, secret, { expiresIn: "15m" });

// Store jti in Redis/cache with TTL matching token expiry
await redis.setex(`jwt:jti:${jti}`, 900, "used");

// On verify — check jti hasn't been used
async function verifyJwtWithReplayCheck(token: string): Promise<JwtPayload> {
  const payload = jwt.verify(token, secret) as JwtPayload;
  const { jti } = payload;

  if (!jti) throw new Error("Token missing jti claim");

  const exists = await redis.get(`jwt:jti:${jti}`);
  if (exists === "revoked") throw new Error("Token has been revoked");

  return payload;
}

// On logout — revoke the specific jti
async function revokeToken(jti: string, expiry: number): Promise<void> {
  const ttl = Math.max(0, expiry - Math.floor(Date.now() / 1000));
  if (ttl > 0) await redis.setex(`jwt:jti:${jti}`, ttl, "revoked");
}

Webhook replay protection:

const WEBHOOK_TOLERANCE_SECONDS = 300; // 5 minutes

export function validateWebhookWithReplay(
  payload: string,
  signature: string,
  secret: string,
  seenNonces: Set<string>
): boolean {
  // 1. Parse timestamp from signature header (e.g., Stripe format: t=timestamp,v1=sig)
  const parts = signature.split(",");
  const timestamp = parseInt(parts.find((p) => p.startsWith("t="))?.slice(2) ?? "0", 10);

  // 2. Reject if timestamp is too old or in the future
  const now = Math.floor(Date.now() / 1000);
  if (Math.abs(now - timestamp) > WEBHOOK_TOLERANCE_SECONDS) {
    throw new Error("Webhook timestamp outside tolerance window — possible replay");
  }

  // 3. Verify signature (standard HMAC-SHA256)
  const expectedSig = createHmac("sha256", secret)
    .update(`${timestamp}.${payload}`)
    .digest("hex");

  const sigValue = parts.find((p) => p.startsWith("v1="))?.slice(3) ?? "";
  if (!timingSafeEqual(Buffer.from(sigValue), Buffer.from(expectedSig))) {
    throw new Error("Webhook signature invalid");
  }

  // 4. Check nonce (event ID) hasn't been processed before
  const eventId = JSON.parse(payload).id as string;
  if (seenNonces.has(eventId)) {
    throw new Error("Webhook event already processed — replay detected");
  }
  seenNonces.add(eventId);  // Persist this to DB in production

  return true;
}

Payment idempotency:

// Every payment creation must include an idempotency key
const idempotencyKey = `pay_${userId}_${orderId}_${Date.now()}`;

const paymentIntent = await stripe.paymentIntents.create(
  {
    amount: totalCents,
    currency: "usd",
    customer: stripeCustomerId
  },
  {
    idempotencyKey  // Stripe deduplicates if same key retried within 24h
  }
);

Phase 4 — Verification

• Confirm JWT jti is present: decode a token and check for jti claim
• Confirm webhook timestamp check: replay a webhook with t=0 → should reject
• Test idempotency: submit same payment twice with same idempotency key → only one charge

STACK-AWARE PATTERNS

• Next.js / App Router detected: Add JWT replay check in auth() wrapper (NextAuth) or middleware
• Stripe detected: Always use idempotencyKey; validate stripe-signature with timestamp window
• AI/LLM detected: Apply replay protection to API key usage patterns to prevent prompt replay attacks

COMPLIANCE MAPPING

{
  "complianceImpact": {
    "pciDss": ["Req 8.3.9"],
    "soc2": ["CC6.1", "CC6.2"],
    "nist80053": ["IA-5", "SC-23"],
    "iso27001": ["A.9.4.2"],
    "owasp": ["A07:2021"]
  }
}

OUTPUT FORMAT

AgentFinding[] array. Each finding must include:

• id: SCREAMING_SNAKE_CASE (e.g. ANTI_REPLAY_JWT_NO_JTI, ANTI_REPLAY_WEBHOOK_NO_TIMESTAMP)
• title: one-line description
• severity: CRITICAL | HIGH | MEDIUM | LOW
• cwe: CWE-NNN (CWE-294 Authentication Bypass by Capture-Replay)
• attackTechnique: MITRE ATT&CK T1550 (Use Alternate Authentication Material)
• files: affected auth/webhook handler paths
• evidence: specific lines showing missing replay protection
• remediated: true if replay protection was written inline
• remediationSummary: what was implemented
• 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:

{
  "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:

{
  "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.