strix-agent 0.4.0__py3-none-any.whl

strix/prompts/vulnerabilities/mass_assignment.jinja

@@ -0,0 +1,141 @@
+<mass_assignment_guide>
+<title>MASS ASSIGNMENT</title>
+
+<critical>Mass assignment binds client-supplied fields directly into models/DTOs without field-level allowlists. It commonly leads to privilege escalation, ownership changes, and unauthorized state transitions in modern APIs and GraphQL.</critical>
+
+<scope>
+- REST/JSON, GraphQL inputs, form-encoded and multipart bodies
+- Model binding in controllers/resolvers; ORM create/update helpers
+- Writable nested relations, sparse/patch updates, bulk endpoints
+</scope>
+
+<methodology>
+1. Identify create/update endpoints and GraphQL mutations. Capture full server responses to observe returned fields.
+2. Build a candidate list of sensitive attributes per resource: role/isAdmin/permissions, ownerId/accountId/tenantId, status/state, plan/price, limits/quotas, feature flags, verification flags, balance/credits.
+3. Inject candidates alongside legitimate updates across transports and encodings; compare before/after state and diffs across roles.
+4. Repeat with nested objects, arrays, and alternative shapes (dot/bracket notation, duplicate keys) and in batch operations.
+</methodology>
+
+<discovery_techniques>
+<surface_map>
+- Controllers with automatic binding (e.g., request.json → model); GraphQL input types mirroring models; admin/staff tools exposed via API
+- OpenAPI/GraphQL schemas: uncover hidden fields or enums; SDKs often reveal writable fields
+- Client bundles and mobile apps: inspect forms and mutation payloads for field names
+</surface_map>
+
+<parameter_strategies>
+- Flat fields: isAdmin, role, roles[], permissions[], status, plan, tier, premium, verified, emailVerified
+- Ownership/tenancy: userId, ownerId, accountId, organizationId, tenantId, workspaceId
+- Limits/quotas: usageLimit, seatCount, maxProjects, creditBalance
+- Feature flags/gates: features, flags, betaAccess, allowImpersonation
+- Billing: price, amount, currency, prorate, nextInvoice, trialEnd
+</parameter_strategies>
+
+<shape_variants>
+- Alternate shapes: arrays vs scalars; nested JSON; objects under unexpected keys
+- Dot/bracket paths: profile.role, profile[role], settings[roles][]
+- Duplicate keys and precedence: {"role":"user","role":"admin"}
+- Sparse/patch formats: JSON Patch/JSON Merge Patch; try adding forbidden paths or replacing protected fields
+</shape_variants>
+
+<encodings_and_channels>
+- Content-types: application/json, application/x-www-form-urlencoded, multipart/form-data, text/plain (JSON via server coercion)
+- GraphQL: add suspicious fields to input objects; overfetch response to detect changes
+- Batch/bulk: arrays of objects; verify per-item allowlists not skipped
+</encodings_and_channels>
+
+<exploitation_techniques>
+<privilege_escalation>
+- Set role/isAdmin/permissions during signup/profile update; toggle admin/staff flags where exposed
+</privilege_escalation>
+
+<ownership_takeover>
+- Change ownerId/accountId/tenantId to seize resources; move objects across users/tenants
+</ownership_takeover>
+
+<feature_gate_bypass>
+- Enable premium/beta/feature flags via flags/features fields; raise limits/seatCount/quotas
+</feature_gate_bypass>
+
+<billing_and_entitlements>
+- Modify plan/price/prorate/trialEnd or creditBalance; bypass server recomputation
+</billing_and_entitlements>
+
+<nested_and_relation_writes>
+- Writable nested serializers or ORM relations allow creating or linking related objects beyond caller’s scope (e.g., attach to another user’s org)
+</nested_and_relation_writes>
+
+<advanced_techniques>
+<graphQL_specific>
+- Field-level authz missing on input types: attempt forbidden fields in mutation inputs; combine with aliasing/batching to compare effects
+- Use fragments to overfetch changed fields immediately after mutation
+</graphQL_specific>
+
+<orm_framework_edges>
+- Rails: strong parameters misconfig or deep nesting via accepts_nested_attributes_for
+- Laravel: $fillable/$guarded misuses; guarded=[] opens all; casts mutating hidden fields
+- Django REST Framework: writable nested serializer, read_only/extra_kwargs gaps, partial updates
+- Mongoose/Prisma: schema paths not filtered; select:false doesn’t prevent writes; upsert defaults
+</orm_framework_edges>
+
+<parser_and_validator_gaps>
+- Validators run post-bind and do not cover extra fields; unknown fields silently dropped in response but persisted underneath
+- Inconsistent allowlists between mobile/web/gateway; alt encodings bypass validation pipeline
+</parser_and_validator_gaps>
+
+<bypass_techniques>
+<content_type_switching>
+- Switch JSON ↔ form-encoded ↔ multipart ↔ text/plain; some code paths only validate one
+</content_type_switching>
+
+<key_path_variants>
+- Dot/bracket/object re-shaping to reach nested fields through different binders
+</key_path_variants>
+
+<batch_paths>
+- Per-item checks skipped in bulk operations; insert a single malicious object within a large batch
+</batch_paths>
+
+<race_and_reorder>
+- Race two updates: first sets forbidden field, second normalizes; final state may retain forbidden change
+</race_and_reorder>
+
+<validation>
+1. Show a minimal request where adding a sensitive field changes persisted state for a non-privileged caller.
+2. Provide before/after evidence (response body, subsequent GET, or GraphQL query) proving the forbidden attribute value.
+3. Demonstrate consistency across at least two encodings or channels.
+4. For nested/bulk, show that protected fields are written within child objects or array elements.
+5. Quantify impact (e.g., role flip, cross-tenant move, quota increase) and reproducibility.
+</validation>
+
+<false_positives>
+- Server recomputes derived fields (plan/price/role) ignoring client input
+- Fields marked read-only and enforced consistently across encodings
+- Only UI-side changes with no persisted effect
+</false_positives>
+
+<impact>
+- Privilege escalation and admin feature access
+- Cross-tenant or cross-account resource takeover
+- Financial/billing manipulation and quota abuse
+- Policy/approval bypass by toggling verification or status flags
+</impact>
+
+<pro_tips>
+1. Build a sensitive-field dictionary per resource and fuzz systematically.
+2. Always try alternate shapes and encodings; many validators are shape/CT-specific.
+3. For GraphQL, diff the resource immediately after mutation; effects are often visible even if the mutation returns filtered fields.
+4. Inspect SDKs/mobile apps for hidden field names and nested write examples.
+5. Prefer minimal PoCs that prove durable state changes; avoid UI-only effects.
+</pro_tips>
+
+<mitigations>
+- Enforce server-side allowlists per operation and role; deny unknown fields by default
+- Separate input DTOs from domain models; map explicitly
+- Recompute derived fields (role/plan/owner) from trusted context; ignore client values
+- Lock nested writes to owned resources; validate foreign keys against caller scope
+- For GraphQL, use input types that expose only permitted fields and enforce resolver-level checks
+</mitigations>
+
+<remember>Mass assignment is eliminated by explicit mapping and per-field authorization. Treat every client-supplied attribute—especially nested or batch inputs—as untrusted until validated against an allowlist and caller scope.</remember>
+</mass_assignment_guide>

strix/prompts/vulnerabilities/open_redirect.jinja

@@ -0,0 +1,177 @@
+<open_redirect_vulnerability_guide>
+<title>OPEN REDIRECT</title>
+
+<critical>Open redirects enable phishing, OAuth/OIDC code and token theft, and allowlist bypass in server-side fetchers that follow redirects. Treat every redirect target as untrusted: canonicalize and enforce exact allowlists per scheme, host, and path.</critical>
+
+<scope>
+- Server-driven redirects (HTTP 3xx Location) and client-driven redirects (window.location, meta refresh, SPA routers)
+- OAuth/OIDC/SAML flows using redirect_uri, post_logout_redirect_uri, RelayState, returnTo/continue/next
+- Multi-hop chains where only the first hop is validated
+- Allowlist/canonicalization bypasses across URL parsers and reverse proxies
+</scope>
+
+<methodology>
+1. Inventory all redirect surfaces: login/logout, password reset, SSO/OAuth flows, payment gateways, email links, invite/verification, unsubscribe, language/locale switches, /out or /r redirectors.
+2. Build a test matrix of scheme×host×path variants and encoding/unicode forms. Compare server-side validation vs browser navigation results.
+3. Exercise multi-hop: trusted-domain → redirector → external. Verify if validation applies pre- or post-redirect.
+4. Prove impact: credential phishing, OAuth code interception, internal egress (if a server fetcher follows redirects).
+</methodology>
+
+<discovery_techniques>
+<injection_points>
+- Params: redirect, url, next, return_to, returnUrl, continue, goto, target, callback, out, dest, back, to, r, u
+- OAuth/OIDC/SAML: redirect_uri, post_logout_redirect_uri, RelayState, state (if used to compute final destination)
+- SPA: router.push/replace, location.assign/href, meta refresh, window.open
+- Headers influencing construction: Host, X-Forwarded-Host/Proto, Referer; and server-side Location echo
+</injection_points>
+
+<parser_differentials>
+<userinfo>
+https://trusted.com@evil.com → many validators parse host as trusted.com, browser navigates to evil.com
+Variants: trusted.com%40evil.com, a%40evil.com%40trusted.com
+</userinfo>
+
+<backslash_and_slashes>
+https://trusted.com\\evil.com, https://trusted.com\\@evil.com, ///evil.com, /\\evil.com
+Windows/backends may normalize \\ to /; browsers differ on interpretation of extra leading slashes
+</backslash_and_slashes>
+
+<whitespace_and_ctrl>
+http%09://evil.com, http%0A://evil.com, trusted.com%09evil.com
+Control/whitespace around the scheme/host can split parsers
+</whitespace_and_ctrl>
+
+<fragment_and_query>
+trusted.com#@evil.com, trusted.com?//@evil.com, ?next=//evil.com#@trusted.com
+Validators often stop at # while the browser parses after it
+</fragment_and_query>
+
+<unicode_and_idna>
+Punycode/IDN: truѕted.com (Cyrillic), trusted.com。evil.com (full-width dot), trailing dot trusted.com.
+Test with mixed Unicode normalization and IDNA conversion
+</unicode_and_idna>
+</parser_differentials>
+
+<encoding_bypasses>
+- Double encoding: %2f%2fevil.com, %252f%252fevil.com
+- Mixed case and scheme smuggling: hTtPs://evil.com, http:evil.com
+- IP variants: decimal 2130706433, octal 0177.0.0.1, hex 0x7f.1, IPv6 [::ffff:127.0.0.1]
+- User-controlled path bases: /out?url=/\\evil.com
+</encoding_bypasses>
+</discovery_techniques>
+
+<allowlist_evasion>
+<common_mistakes>
+- Substring/regex contains checks: allows trusted.com.evil.com, or path matches leaking external
+- Wildcards: *.trusted.com also matches attacker.trusted.com.evil.net
+- Missing scheme pinning: data:, javascript:, file:, gopher: accepted
+- Case/IDN drift between validator and browser
+</common_mistakes>
+
+<robust_validation>
+- Canonicalize with a single modern URL parser (WHATWG URL) and compare exact scheme, hostname (post-IDNA), and an explicit allowlist with optional exact path prefixes
+- Require absolute HTTPS; reject protocol-relative // and unknown schemes
+- Normalize and compare after following zero redirects only; if following, re-validate the final destination per hop server-side
+</robust_validation>
+</allowlist_evasion>
+
+<oauth_oidc_saml>
+<redirect_uri_abuse>
+- Using an open redirect on a trusted domain for redirect_uri enables code interception
+- Weak prefix/suffix checks: https://trusted.com → https://trusted.com.evil.com; /callback → /callback@evil.com
+- Path traversal/canonicalization: /oauth/../../@evil.com
+- post_logout_redirect_uri often less strictly validated; test both
+- state must be unguessable and bound to client/session; do not recompute final destination from state without validation
+</redirect_uri_abuse>
+
+<defense_notes>
+- Pre-register exact redirect_uri values per client (no wildcards). Enforce exact scheme/host/port/path match
+- For public native apps, follow RFC guidance (loopback 127.0.0.1 with exact port handling); disallow open web redirectors
+- SAML RelayState should be validated against an allowlist or ignored for absolute URLs
+</defense_notes>
+</oauth_oidc_saml>
+
+<client_side_vectors>
+<javascript_redirects>
+- location.href/assign/replace using user input; ensure targets are normalized and restricted to same-origin or allowlist
+- meta refresh content=0;url=USER_INPUT; browsers treat javascript:/data: differently; still dangerous in client-controlled redirects
+- SPA routers: router.push(searchParams.get('next')); enforce same-origin and strip schemes
+</javascript_redirects>
+
+</client_side_vectors>
+
+<reverse_proxies_and_gateways>
+- Host/X-Forwarded-* may change absolute URL construction; validate against server-derived canonical origin, not client headers
+- CDNs that follow redirects for link checking or prefetching can leak tokens when chained with open redirects
+</reverse_proxies_and_gateways>
+
+<ssrf_chaining>
+- Some server-side fetchers (web previewers, link unfurlers, validators) follow 3xx; combine with an open redirect on an allowlisted domain to pivot to internal targets (169.254.169.254, localhost, cluster addresses)
+- Confirm by observing distinct error/timing for internal vs external, or OAST callbacks when reachable
+</ssrf_chaining>
+
+<framework_notes>
+<server_side>
+- Rails: redirect_to params[:url] without URI parsing; test array params and protocol-relative
+- Django: HttpResponseRedirect(request.GET['next']) without is_safe_url; relies on ALLOWED_HOSTS + scheme checks
+- Spring: return "redirect:" + param; ensure UriComponentsBuilder normalization and allowlist
+- Express: res.redirect(req.query.url); use a safe redirect helper enforcing relative paths or a vetted allowlist
+</server_side>
+
+<client_side>
+- React/Next.js/Vue/Angular routing based on URLSearchParams; ensure same-origin policy and disallow external schemes in client code
+</client_side>
+</framework_notes>
+
+<exploitation_scenarios>
+<oauth_code_interception>
+1. Set redirect_uri to https://trusted.example/out?url=https://attacker.tld/cb
+2. IdP sends code to trusted.example which redirects to attacker.tld
+3. Exchange code for tokens; demonstrate account access
+</oauth_code_interception>
+
+<phishing_flow>
+1. Send link on trusted domain: /login?next=https://attacker.tld/fake
+2. Victim authenticates; browser navigates to attacker page
+3. Capture credentials/tokens via cloned UI or injected JS
+</phishing_flow>
+
+<internal_evasion>
+1. Server-side link unfurler fetches https://trusted.example/out?u=http://169.254.169.254/latest/meta-data
+2. Redirect follows to metadata; confirm via timing/headers or controlled endpoints
+</internal_evasion>
+</exploitation_scenarios>
+
+<validation>
+1. Produce a minimal URL that navigates to an external domain via the vulnerable surface; include the full address bar capture.
+2. Show bypass of the stated validation (regex/allowlist) using canonicalization variants.
+3. Test multi-hop: prove only first hop is validated and second hop escapes constraints.
+4. For OAuth/SAML, demonstrate code/RelayState delivery to an attacker-controlled endpoint with role-separated evidence.
+</validation>
+
+<false_positives>
+- Redirects constrained to relative same-origin paths with robust normalization
+- Exact pre-registered OAuth redirect_uri with strict verifier
+- Validators using a single canonical parser and comparing post-IDNA host and scheme
+- User prompts that show the exact final destination before navigating and refuse unknown schemes
+</false_positives>
+
+<impact>
+- Credential and token theft via phishing and OAuth/OIDC interception
+- Internal data exposure when server fetchers follow redirects (previewers/unfurlers)
+- Policy bypass where allowlists are enforced only on the first hop
+- Cross-application trust erosion and brand abuse
+</impact>
+
+<pro_tips>
+1. Always compare server-side canonicalization to real browser navigation; differences reveal bypasses.
+2. Try userinfo, protocol-relative, Unicode/IDN, and IP numeric variants early; they catch many weak validators.
+3. In OAuth, prioritize post_logout_redirect_uri and less-discussed flows; they’re often looser.
+4. Exercise multi-hop across distinct subdomains and paths; validators commonly check only hop 1.
+5. For SSRF chaining, target services known to follow redirects and log their outbound requests.
+6. Favor allowlists of exact origins plus optional path prefixes; never substring/regex contains checks.
+7. Keep a curated suite of redirect payloads per runtime (Java, Node, Python, Go) reflecting each parser’s quirks.
+</pro_tips>
+
+<remember>Redirection is safe only when the final destination is constrained after canonicalization. Enforce exact origins, verify per hop, and treat client-provided destinations as untrusted across every stack.</remember>
+</open_redirect_vulnerability_guide>

strix/prompts/vulnerabilities/path_traversal_lfi_rfi.jinja

@@ -0,0 +1,142 @@
+<path_traversal_lfi_rfi_guide>
+<title>PATH TRAVERSAL, LFI, AND RFI</title>
+
+<critical>Improper file path handling and dynamic inclusion enable sensitive file disclosure, config/source leakage, SSRF pivots, and code execution. Treat all user-influenced paths, names, and schemes as untrusted; normalize and bind them to an allowlist or eliminate user control entirely.</critical>
+
+<scope>
+- Path traversal: read files outside intended roots via ../, encoding, normalization gaps
+- Local File Inclusion (LFI): include server-side files into interpreters/templates
+- Remote File Inclusion (RFI): include remote resources (HTTP/FTP/wrappers) for code execution
+- Archive extraction traversal (Zip Slip): write outside target directory upon unzip/untar
+- Server/proxy normalization mismatches (nginx alias/root, upstream decoders)
+- OS-specific paths: Windows separators, device names, UNC, NT paths, alternate data streams
+</scope>
+
+<methodology>
+1. Inventory all file operations: downloads, previews, templates, logs, exports/imports, report engines, uploads, archive extractors.
+2. Identify input joins: path joins (base + user), include/require/template loads, resource fetchers, archive extract destinations.
+3. Probe normalization and resolution: separators, encodings, double-decodes, case, trailing dots/slashes; compare web server vs application behavior.
+4. Escalate from disclosure (read) to influence (write/extract/include), then to execution (wrapper/engine chains).
+</methodology>
+
+<discovery_techniques>
+<surface_map>
+- HTTP params: file, path, template, include, page, view, download, export, report, log, dir, theme, lang
+- Upload and conversion pipelines: image/PDF renderers, thumbnailers, office converters
+- Archive extract endpoints and background jobs; imports with ZIP/TAR/GZ/7z
+- Server-side template rendering (PHP/Smarty/Twig/Blade), email templates, CMS themes/plugins
+- Reverse proxies and static file servers (nginx, CDN) in front of app handlers
+</surface_map>
+
+<capability_probes>
+- Path traversal baseline: ../../etc/hosts and C:\\Windows\\win.ini
+- Encodings: %2e%2e%2f, %252e%252e%252f, ..%2f, ..%5c, mixed UTF-8 (%c0%2e), Unicode dots and slashes
+- Normalization tests: ....//, ..\\, ././, trailing dot/double dot segments; repeated decoding
+- Absolute path acceptance: /etc/passwd, C:\\Windows\\System32\\drivers\\etc\\hosts
+- Server mismatch: /static/..;/../etc/passwd ("..;"), encoded slashes (%2F), double-decoding via upstream
+</capability_probes>
+</discovery_techniques>
+
+<detection_channels>
+<direct>
+- Response body discloses file content (text, binary, base64); error pages echo real paths
+</direct>
+
+<error_based>
+- Exception messages expose canonicalized paths or include() warnings with real filesystem locations
+</error_based>
+
+<oast>
+- RFI/LFI with wrappers that trigger outbound fetches (HTTP/DNS) to confirm inclusion/execution
+</oast>
+
+<side_effects>
+- Archive extraction writes files unexpectedly outside target; verify with directory listings or follow-up reads
+</side_effects>
+</detection_channels>
+
+<path_traversal>
+<bypasses_and_variants>
+- Encodings: single/double URL-encoding, mixed case, overlong UTF-8, UTF-16, path normalization oddities
+- Mixed separators: / and \\ on Windows; // and \\\\ collapse differences across frameworks
+- Dot tricks: ....// (double dot folding), trailing dots (Windows), trailing slashes, appended valid extension
+- Absolute path injection: bypass joins by supplying a rooted path
+- Alias/root mismatch (nginx): alias without trailing slash with nested location allows ../ to escape; try /static/../etc/passwd and ";" variants (..;)
+- Upstream vs backend decoding: proxies/CDNs decoding %2f differently; test double-decoding and encoded dots
+</bypasses_and_variants>
+
+<high_value_targets>
+- /etc/passwd, /etc/hosts, application .env/config.yaml, SSH/keys, cloud creds, service configs/logs
+- Windows: C:\\Windows\\win.ini, IIS/web.config, programdata configs, application logs
+- Source code templates and server-side includes; secrets in env dumps
+</high_value_targets>
+</path_traversal>
+
+<lfi>
+<wrappers_and_techniques>
+- PHP wrappers: php://filter/convert.base64-encode/resource=index.php (read source), zip://archive.zip#file.txt, data://text/plain;base64, expect:// (if enabled)
+- Log/session poisoning: inject PHP/templating payloads into access/error logs or session files then include them (paths vary by stack)
+- Upload temp names: include temporary upload files before relocation; race with scanners
+- /proc/self/environ and framework-specific caches for readable secrets
+- Null-byte (legacy): %00 truncation in older stacks; path length truncation tricks
+</wrappers_and_techniques>
+
+<template_engines>
+- PHP include/require; Smarty/Twig/Blade with dynamic template names
+- Java/JSP/FreeMarker/Velocity; Node.js ejs/handlebars/pug engines
+- Seek dynamic template resolution from user input (theme/lang/template)
+</template_engines>
+</lfi>
+
+<rfi>
+<conditions>
+- Remote includes (allow_url_include/allow_url_fopen in PHP), custom fetchers that eval/execute retrieved content, SSRF-to-exec bridges
+- Protocol handlers: http, https, ftp; language-specific stream handlers
+</conditions>
+
+<exploitation>
+- Host a minimal payload that proves code execution; prefer OAST beacons or deterministic output over heavy shells
+- Chain with upload or log poisoning when remote includes are disabled to reach local payloads
+</exploitation>
+</rfi>
+
+<archive_extraction>
+<zip_slip>
+- Files within archives containing ../ or absolute paths escape target extract directory
+- Test multiple formats: zip/tar/tgz/7z; verify symlink handling and path canonicalization prior to write
+- Impact: overwrite config/templates or drop webshells into served directories
+</zip_slip>
+</archive_extraction>
+
+<validation>
+1. Show a minimal traversal read proving out-of-root access (e.g., /etc/hosts) with a same-endpoint in-root control.
+2. For LFI, demonstrate inclusion of a benign local file or harmless wrapper output (php://filter base64 of index.php); avoid active code when not permitted.
+3. For RFI, prove remote fetch by OAST or controlled output; avoid destructive payloads.
+4. For Zip Slip, create an archive with ../ entries and show write outside target (e.g., marker file read back).
+5. Provide before/after file paths, exact requests, and content hashes/lengths for reproducibility.
+</validation>
+
+<false_positives>
+- In-app virtual paths that do not map to filesystem; content comes from safe stores (DB/object storage)
+- Canonicalized paths constrained to an allowlist/root after normalization
+- Wrappers disabled and includes using constant templates only
+- Archive extractors that sanitize paths and enforce destination directories
+</false_positives>
+
+<impact>
+- Sensitive configuration/source disclosure → credential and key compromise
+- Code execution via inclusion of attacker-controlled content or overwritten templates
+- Persistence via dropped files in served directories; lateral movement via revealed secrets
+- Supply-chain impact when report/template engines execute attacker-influenced files
+</impact>
+
+<pro_tips>
+1. Compare content-length/ETag when content is masked; read small canonical files (hosts) to avoid noise.
+2. Test proxy/CDN and app separately; decoding/normalization order differs, especially for %2f and %2e encodings.
+3. For LFI, prefer php://filter base64 probes over destructive payloads; enumerate readable logs and sessions.
+4. Validate extraction code with synthetic archives; include symlinks and deep ../ chains.
+5. Use minimal PoCs and hard evidence (hashes, paths). Avoid noisy DoS against filesystems.
+</pro_tips>
+
+<remember>Eliminate user-controlled paths where possible. Otherwise, resolve to canonical paths and enforce allowlists, forbid remote schemes, and lock down interpreters and extractors. Normalize consistently at the boundary closest to IO.</remember>
+</path_traversal_lfi_rfi_guide>

strix/prompts/vulnerabilities/race_conditions.jinja

@@ -0,0 +1,164 @@
+<race_conditions_guide>
+<title>RACE CONDITIONS</title>
+
+<critical>Concurrency bugs enable duplicate state changes, quota bypass, financial abuse, and privilege errors. Treat every read–modify–write and multi-step workflow as adversarially concurrent.</critical>
+
+<scope>
+- Read–modify–write sequences without atomicity or proper locking
+- Multi-step operations (check → reserve → commit) with gaps between phases
+- Cross-service workflows (sagas, async jobs) with eventual consistency
+- Rate limits, quotas, and idempotency controls implemented at the edge only
+</scope>
+
+<methodology>
+1. Model invariants for each workflow (e.g., conservation of value, uniqueness, maximums). Identify reads and writes and where they occur (service, DB, cache).
+2. Establish a baseline with single requests. Then issue concurrent requests with identical inputs. Observe deltas in state and responses.
+3. Scale and synchronize: ramp up parallelism, switch transports (HTTP/1.1, HTTP/2), and align request timing (last-byte sync, warmed connections).
+4. Repeat across channels (web, API, GraphQL, WebSocket) and roles. Confirm durability and reproducibility.
+</methodology>
+
+<discovery_techniques>
+<identify_race_windows>
+- Look for explicit sequences in code or docs: "check balance then deduct", "verify coupon then apply", "check inventory then purchase", "validate token then consume"
+- Watch for optimistic concurrency markers: ETag/If-Match, version fields, updatedAt checks; test if they are enforced
+- Examine idempotency-key support: scope (path vs principal), TTL, and persistence (cache vs DB)
+- Map cross-service steps: when is state written vs published, and what retries/compensations exist
+</identify_race_windows>
+
+<signals>
+- Sequential request fails but parallel succeeds
+- Duplicate rows, negative counters, over-issuance, or inconsistent aggregates
+- Distinct response shapes/timings for simultaneous vs sequential requests
+- Audit logs out of order; multiple 2xx for the same intent; missing or duplicate correlation IDs
+</signals>
+
+<surface_map>
+- Payments: auth/capture/refund/void; credits/loyalty points; gift cards
+- Coupons/discounts: single-use codes, stacking checks, per-user limits
+- Quotas/limits: API usage, inventory reservations, seat counts, vote limits
+- Auth flows: password reset/OTP consumption, session minting, device trust
+- File/object storage: multi-part finalize, version writes, share-link generation
+- Background jobs: export/import create/finalize endpoints; job cancellation/approve
+- GraphQL mutations and batch operations; WebSocket actions
+</surface_map>
+</discovery_techniques>
+
+<exploitation_techniques>
+<request_synchronization>
+- HTTP/2 multiplexing for tight concurrency; send many requests on warmed connections
+- Last-byte synchronization: hold requests open and release final byte simultaneously
+- Connection warming: pre-establish sessions, cookies, and TLS to remove jitter
+</request_synchronization>
+
+<idempotency_and_dedup_bypass>
+- Reuse the same idempotency key across different principals/paths if scope is inadequate
+- Hit the endpoint before the idempotency store is written (cache-before-commit windows)
+- App-level dedup drops only the response while side effects (emails/credits) still occur
+</idempotency_and_dedup_bypass>
+
+<atomicity_gaps>
+- Lost update: read-modify-write increments without atomic DB statements
+- Partial two-phase workflows: success committed before validation completes
+- Unique checks done outside a unique index/upsert: create duplicates under load
+</atomicity_gaps>
+
+<cross_service_races>
+- Saga/compensation timing gaps: execute compensation without preventing the original success path
+- Eventual consistency windows: act in Service B before Service A's write is visible
+- Retry storms: duplicate side effects due to at-least-once delivery without idempotent consumers
+</cross_service_races>
+
+<rate_limits_and_quotas>
+- Per-IP or per-connection enforcement: bypass with multiple IPs/sessions
+- Counter updates not atomic or sharded inconsistently; send bursts before counters propagate
+</rate_limits_and_quotas>
+</exploitation_techniques>
+
+<advanced_techniques>
+<optimistic_concurrency_evasion>
+- Omit If-Match/ETag where optional; supply stale versions if server ignores them
+- Version fields accepted but not validated across all code paths (e.g., GraphQL vs REST)
+</optimistic_concurrency_evasion>
+
+<database_isolation>
+- Exploit READ COMMITTED/REPEATABLE READ anomalies: phantoms, non-serializable sequences
+- Upsert races: use unique indexes with proper ON CONFLICT/UPSERT or exploit naive existence checks
+- Lock granularity issues: row vs table; application locks held only in-process
+</database_isolation>
+
+<distributed_locks>
+- Redis locks without NX/EX or fencing tokens allow multiple winners
+- Locks stored in memory on a single node; bypass by hitting other nodes/regions
+</distributed_locks>
+</advanced_techniques>
+
+<bypass_techniques>
+- Distribute across IPs, sessions, and user accounts to evade per-entity throttles
+- Switch methods/content-types/endpoints that trigger the same state change via different code paths
+- Intentionally trigger timeouts to provoke retries that cause duplicate side effects
+- Degrade the target (large payloads, slow endpoints) to widen race windows
+</bypass_techniques>
+
+<special_contexts>
+<graphql>
+- Parallel mutations and batched operations may bypass per-mutation guards; ensure resolver-level idempotency and atomicity
+- Persisted queries and aliases can hide multiple state changes in one request
+</graphql>
+
+<websocket>
+- Per-message authorization and idempotency must hold; concurrent emits can create duplicates if only the handshake is checked
+</websocket>
+
+<files_and_storage>
+- Parallel finalize/complete on multi-part uploads can create duplicate or corrupted objects; re-use pre-signed URLs concurrently
+</files_and_storage>
+
+<auth_flows>
+- Concurrent consumption of one-time tokens (reset codes, magic links) to mint multiple sessions; verify consume is atomic
+</auth_flows>
+</special_contexts>
+
+<chaining_attacks>
+- Race + Business logic: violate invariants (double-refund, limit slicing)
+- Race + IDOR: modify or read others' resources before ownership checks complete
+- Race + CSRF: trigger parallel actions from a victim to amplify effects
+- Race + Caching: stale caches re-serve privileged states after concurrent changes
+</chaining_attacks>
+
+<validation>
+1. Single request denied; N concurrent requests succeed where only 1 should.
+2. Durable state change proven (ledger entries, inventory counts, role/flag changes).
+3. Reproducible under controlled synchronization (HTTP/2, last-byte sync) across multiple runs.
+4. Evidence across channels (e.g., REST and GraphQL) if applicable.
+5. Include before/after state and exact request set used.
+</validation>
+
+<false_positives>
+- Truly idempotent operations with enforced ETag/version checks or unique constraints
+- Serializable transactions or correct advisory locks/queues
+- Visual-only glitches without durable state change
+- Rate limits that reject excess with atomic counters
+</false_positives>
+
+<impact>
+- Financial loss (double spend, over-issuance of credits/refunds)
+- Policy/limit bypass (quotas, single-use tokens, seat counts)
+- Data integrity corruption and audit trail inconsistencies
+- Privilege or role errors due to concurrent updates
+</impact>
+
+<pro_tips>
+1. Favor HTTP/2 with warmed connections; add last-byte sync for precision.
+2. Start small (N=5–20), then scale; too much noise can mask the window.
+3. Target read–modify–write code paths and endpoints with idempotency keys.
+4. Compare REST vs GraphQL vs WebSocket; protections often differ.
+5. Look for cross-service gaps (queues, jobs, webhooks) and retry semantics.
+6. Check unique constraints and upsert usage; avoid relying on pre-insert checks.
+7. Use correlation IDs and logs to prove concurrent interleaving.
+8. Widen windows by adding server load or slow backend dependencies.
+9. Validate on production-like latency; some races only appear under real load.
+10. Document minimal, repeatable request sets that demonstrate durable impact.
+</pro_tips>
+
+<remember>Concurrency safety is a property of every path that mutates state. If any path lacks atomicity, proper isolation, or idempotency, parallel requests will eventually break invariants.</remember>
+</race_conditions_guide>