strix-agent 0.4.0__py3-none-any.whl

strix/prompts/vulnerabilities/authentication_jwt.jinja

@@ -0,0 +1,147 @@
+<authentication_jwt_guide>
+<title>AUTHENTICATION AND JWT/OIDC</title>
+
+<critical>JWT/OIDC failures often enable token forgery, token confusion, cross-service acceptance, and durable account takeover. Do not trust headers, claims, or token opacity without strict validation bound to issuer, audience, key, and context.</critical>
+
+<scope>
+- Web/mobile/API authentication using JWT (JWS/JWE) and OIDC/OAuth2
+- Access vs ID tokens, refresh tokens, device/PKCE/Backchannel flows
+- First-party and microservices verification, gateways, and JWKS distribution
+</scope>
+
+<methodology>
+1. Inventory issuers and consumers: identity providers, API gateways, services, mobile/web clients.
+2. Capture real tokens (access and ID) for multiple roles. Note header, claims, signature, and verification endpoints (/.well-known, /jwks.json).
+3. Build a matrix: Token Type × Audience × Service; attempt cross-use (wrong audience/issuer/service) and observe acceptance.
+4. Mutate headers (alg, kid, jku/x5u/jwk, typ/cty/crit), claims (iss/aud/azp/sub/nbf/iat/exp/scope/nonce), and signatures; verify what is actually enforced.
+</methodology>
+
+<discovery_techniques>
+<endpoints>
+- Well-known: /.well-known/openid-configuration, /oauth2/.well-known/openid-configuration
+- Keys: /jwks.json, rotating key endpoints, tenant-specific JWKS
+- Auth: /authorize, /token, /introspect, /revoke, /logout, device code endpoints
+- App: /login, /callback, /refresh, /me, /session, /impersonate
+</endpoints>
+
+<token_features>
+- Headers: {% raw %}{"alg":"RS256","kid":"...","typ":"JWT","jku":"...","x5u":"...","jwk":{...}}{% endraw %}
+- Claims: {% raw %}{"iss":"...","aud":"...","azp":"...","sub":"user","scope":"...","exp":...,"nbf":...,"iat":...}{% endraw %}
+- Formats: JWS (signed), JWE (encrypted). Note unencoded payload option ("b64":false) and critical headers ("crit").
+</token_features>
+</discovery_techniques>
+
+<exploitation_techniques>
+<signature_verification>
+- RS256→HS256 confusion: change alg to HS256 and use the RSA public key as HMAC secret if algorithm is not pinned
+- "none" algorithm acceptance: set {% raw %}"alg":"none"{% endraw %} and drop the signature if libraries accept it
+- ECDSA malleability/misuse: weak verification settings accepting non-canonical signatures
+</signature_verification>
+
+<header_manipulation>
+- kid injection: path traversal {% raw %}../../../../keys/prod.key{% endraw %}, SQL/command/template injection in key lookup, or pointing to world-readable files
+- jku/x5u abuse: host attacker-controlled JWKS/X509 chain; if not pinned/whitelisted, server fetches and trusts attacker keys
+- jwk header injection: embed attacker JWK in header; some libraries prefer inline JWK over server-configured keys
+- SSRF via remote key fetch: exploit JWKS URL fetching to reach internal hosts
+</header_manipulation>
+
+<key_and_cache_issues>
+- JWKS caching TTL and key rollover: accept obsolete keys; race rotation windows; missing kid pinning → accept any matching kty/alg
+- Mixed environments: same secrets across dev/stage/prod; key reuse across tenants or services
+- Fallbacks: verification succeeds when kid not found by trying all keys or no keys (implementation bugs)
+</key_and_cache_issues>
+
+<claims_validation_gaps>
+- iss/aud/azp not enforced: cross-service token reuse; accept tokens from any issuer or wrong audience
+- scope/roles fully trusted from token: server does not re-derive authorization; privilege inflation via claim edits when signature checks are weak
+- exp/nbf/iat not enforced or large clock skew tolerance; accept long-expired or not-yet-valid tokens
+- typ/cty not enforced: accept ID token where access token required (token confusion)
+</claims_validation_gaps>
+
+<token_confusion_and_oidc>
+- Access vs ID token swap: use ID token against APIs when they only verify signature but not audience/typ
+- OIDC mix-up: redirect_uri and client mix-ups causing tokens for Client A to be redeemed at Client B
+- PKCE downgrades: missing S256 requirement; accept plain or absent code_verifier
+- State/nonce weaknesses: predictable or missing → CSRF/logical interception of login\n- Device/Backchannel flows: codes and tokens accepted by unintended clients or services
+</token_confusion_and_oidc>
+
+<refresh_and_session>
+- Refresh token rotation not enforced: reuse old refresh token indefinitely; no reuse detection
+- Long-lived JWTs with no revocation: persistent access post-logout
+- Session fixation: bind new tokens to attacker-controlled session identifiers or cookies
+</refresh_and_session>
+
+<transport_and_storage>
+- Token in localStorage/sessionStorage: susceptible to XSS exfiltration; cookie vs header trade-offs with SameSite/CSRF
+- Insecure CORS: wildcard origins with credentialed requests expose tokens and protected responses
+- TLS and cookie flags: missing Secure/HttpOnly; lack of mTLS or DPoP/"cnf" binding permits replay from another device
+</transport_and_storage>
+</exploitation_techniques>
+
+<advanced_techniques>
+<microservices_and_gateways>
+- Audience mismatch: internal services verify signature but ignore aud → accept tokens for other services
+- Header trust: edge or gateway injects X-User-Id; backend trusts it over token claims
+- Asynchronous consumers: workers process messages with bearer tokens but skip verification on replay
+</microservices_and_gateways>
+
+<jws_edge_cases>
+- Unencoded payload (b64=false) with crit header: libraries mishandle verification paths
+- Nested JWT (JWT-in-JWT) verification order errors; outer token accepted while inner claims ignored
+</jws_edge_cases>
+
+<special_contexts>
+<mobile>
+- Deep-link/redirect handling bugs leak codes/tokens; insecure WebView bridges exposing tokens
+- Token storage in plaintext files/SQLite/Keychain/SharedPrefs; backup/adb accessible
+</mobile>
+
+<sso_federation>
+- Misconfigured trust between multiple IdPs/SPs, mixed metadata, or stale keys lead to acceptance of foreign tokens
+</sso_federation>
+</special_contexts>
+
+<chaining_attacks>
+- XSS → token theft → replay across services with weak audience checks
+- SSRF → fetch private JWKS → sign tokens accepted by internal services
+- Host header poisoning → OIDC redirect_uri poisoning → code capture
+- IDOR in sessions/impersonation endpoints → mint tokens for other users
+</chaining_attacks>
+
+<validation>
+1. Show forged or cross-context token acceptance (wrong alg, wrong audience/issuer, or attacker-signed JWKS).
+2. Demonstrate access token vs ID token confusion at an API.
+3. Prove refresh token reuse without rotation detection or revocation.
+4. Confirm header abuse (kid/jku/x5u/jwk) leading to key selection under attacker control.
+5. Provide owner vs non-owner evidence with identical requests differing only in token context.
+</validation>
+
+<false_positives>
+- Token rejected due to strict audience/issuer enforcement
+- Key pinning with JWKS whitelist and TLS validation
+- Short-lived tokens with rotation and revocation on logout
+- ID token not accepted by APIs that require access tokens
+</false_positives>
+
+<impact>
+- Account takeover and durable session persistence
+- Privilege escalation via claim manipulation or cross-service acceptance
+- Cross-tenant or cross-application data access
+- Token minting by attacker-controlled keys or endpoints
+</impact>
+
+<pro_tips>
+1. Pin verification to issuer and audience; log and diff claim sets across services.
+2. Attempt RS256→HS256 and "none" first only if algorithm pinning is unclear; otherwise focus on header key control (kid/jku/x5u/jwk).
+3. Test token reuse across all services; many backends only check signature, not audience/typ.
+4. Exploit JWKS caching and rotation races; try retired keys and missing kid fallbacks.
+5. Exercise OIDC flows with PKCE/state/nonce variants and mixed clients; look for mix-up.
+6. Try DPoP/mTLS absence to replay tokens from different devices.
+7. Treat refresh as its own surface: rotation, reuse detection, and audience scoping.
+8. Validate every acceptance path: gateway, service, worker, WebSocket, and gRPC.
+9. Favor minimal PoCs that clearly show cross-context acceptance and durable access.
+10. When in doubt, assume verification differs per stack (mobile vs web vs gateway) and test each.
+</pro_tips>
+
+<remember>Verification must bind the token to the correct issuer, audience, key, and client context on every acceptance path. Any missing binding enables forgery or confusion.</remember>
+</authentication_jwt_guide>

strix/prompts/vulnerabilities/broken_function_level_authorization.jinja

@@ -0,0 +1,146 @@
+<broken_function_level_authorization_guide>
+<title>BROKEN FUNCTION LEVEL AUTHORIZATION (BFLA)</title>
+
+<critical>BFLA is action-level authorization failure: callers invoke functions (endpoints, mutations, admin tools) they are not entitled to. It appears when enforcement differs across transports, gateways, roles, or when services trust client hints. Bind subject × action at the service that performs the action.</critical>
+
+<scope>
+- Vertical authz: privileged/admin/staff-only actions reachable by basic users
+- Feature gates: toggles enforced at edge/UI, not at core services
+- Transport drift: REST vs GraphQL vs gRPC vs WebSocket with inconsistent checks
+- Gateway trust: backends trust X-User-Id/X-Role injected by proxies/edges
+- Background workers/jobs performing actions without re-checking authz
+</scope>
+
+<methodology>
+1. Build an Actor × Action matrix with at least: unauth, basic, premium, staff/admin. Enumerate actions (create/update/delete, approve/cancel, impersonate, export, invite, role-change, credit/refund).
+2. Obtain tokens/sessions for each role. Exercise every action across all transports and encodings (JSON, form, multipart), including method overrides.
+3. Vary headers and contextual selectors (org/tenant/project) and test behavior behind gateway vs direct-to-service.
+4. Include background flows: job creation/finalization, webhooks, queues. Confirm re-validation of authz in consumers.
+</methodology>
+
+<discovery_techniques>
+<surface_enumeration>
+- Admin/staff consoles and APIs, support tools, internal-only endpoints exposed via gateway
+- Hidden buttons and disabled UI paths (feature-flagged) mapped to still-live endpoints
+- GraphQL schemas: mutations and admin-only fields/types; gRPC service descriptors (reflection)
+- Mobile clients often reveal extra endpoints/roles in app bundles or network logs
+</surface_enumeration>
+
+<signals>
+- 401/403 on UI but 200 via direct API call; differing status codes across transports
+- Actions succeed via background jobs when direct call is denied
+- Changing only headers (role/org) alters access without token change
+</signals>
+
+<high_value_actions>
+- Role/permission changes, impersonation/sudo, invite/accept into orgs
+- Approve/void/refund/credit issuance, price/plan overrides
+- Export/report generation, data deletion, account suspension/reactivation
+- Feature flag toggles, quota/grant adjustments, license/seat changes
+- Security settings: 2FA reset, email/phone verification overrides
+</high_value_actions>
+
+<exploitation_techniques>
+<verb_drift_and_aliases>
+- Alternate methods: GET performing state change; POST vs PUT vs PATCH differences; X-HTTP-Method-Override/_method
+- Alternate endpoints performing the same action with weaker checks (legacy vs v2, mobile vs web)
+</verb_drift_and_aliases>
+
+<edge_vs_core_mismatch>
+- Edge blocks an action but core service RPC accepts it directly; call internal service via exposed API route or SSRF
+- Gateway-injected identity headers override token claims; supply conflicting headers to test precedence
+</edge_vs_core_mismatch>
+
+<feature_flag_bypass>
+- Client-checked feature gates; call backend endpoints directly
+- Admin-only mutations exposed but hidden in UI; invoke via GraphQL or gRPC tools
+</feature_flag_bypass>
+
+<batch_job_paths>
+- Create export/import jobs where creation is allowed but finalize/approve lacks authz; finalize others' jobs
+- Replay webhooks/background tasks endpoints that perform privileged actions without verifying caller
+</batch_job_paths>
+
+<content_type_paths>
+- JSON vs form vs multipart handlers using different middleware: send the action via the most permissive parser
+</content_type_paths>
+</exploitation_techniques>
+
+<advanced_techniques>
+<graphql>
+- Resolver-level checks per mutation/field; do not assume top-level auth covers nested mutations or admin fields
+- Abuse aliases/batching to sneak privileged fields; persisted queries sometimes bypass auth transforms
+- Example:
+{% raw %}
+mutation Promote($id:ID!){
+  a: updateUser(id:$id, role: ADMIN){ id role }
+}
+{% endraw %}
+</graphql>
+
+<grpc>
+- Method-level auth via interceptors must enforce audience/roles; probe direct gRPC with tokens of lower role
+- Reflection lists services/methods; call admin methods that the gateway hid
+</grpc>
+
+<websocket>
+- Handshake-only auth: ensure per-message authorization on privileged events (e.g., admin:impersonate)
+- Try emitting privileged actions after joining standard channels
+</websocket>
+
+<multi_tenant>
+- Actions requiring tenant admin enforced only by header/subdomain; attempt cross-tenant admin actions by switching selectors with same token
+</multi_tenant>
+
+<microservices>
+- Internal RPCs trust upstream checks; reach them through exposed endpoints or SSRF; verify each service re-enforces authz
+</microservices>
+
+<bypass_techniques>
+<header_trust>
+- Supply X-User-Id/X-Role/X-Organization headers; remove or contradict token claims; observe which source wins
+</header_trust>
+
+<route_shadowing>
+- Legacy/alternate routes (e.g., /admin/v1 vs /v2/admin) that skip new middleware chains
+</route_shadowing>
+
+<idempotency_and_retries>
+- Retry or replay finalize/approve endpoints that apply state without checking actor on each call
+</idempotency_and_retries>
+
+<cache_key_confusion>
+- Cached authorization decisions at edge leading to cross-user reuse; test with Vary and session swaps
+</cache_key_confusion>
+</bypass_techniques>
+
+<validation>
+1. Show a lower-privileged principal successfully invokes a restricted action (same inputs) while the proper role succeeds and another lower role fails.
+2. Provide evidence across at least two transports or encodings demonstrating inconsistent enforcement.
+3. Demonstrate that removing/altering client-side gates (buttons/flags) does not affect backend success.
+4. Include durable state change proof: before/after snapshots, audit logs, and authoritative sources.
+</validation>
+
+<false_positives>
+- Read-only endpoints mislabeled as admin but publicly documented
+- Feature toggles intentionally open to all roles for preview/beta with clear policy
+- Simulated environments where admin endpoints are stubbed with no side effects
+</false_positives>
+
+<impact>
+- Privilege escalation to admin/staff actions
+- Monetary/state impact: refunds/credits/approvals without authorization
+- Tenant-wide configuration changes, impersonation, or data deletion
+- Compliance and audit violations due to bypassed approval workflows
+</impact>
+
+<pro_tips>
+1. Start from the role matrix; test every action with basic vs admin tokens across REST/GraphQL/gRPC.
+2. Diff middleware stacks between routes; weak chains often exist on legacy or alternate encodings.
+3. Inspect gateways for identity header injection; never trust client-provided identity.
+4. Treat jobs/webhooks as first-class: finalize/approve must re-check the actor.
+5. Prefer minimal PoCs: one request that flips a privileged field or invokes an admin method with a basic token.
+</pro_tips>
+
+<remember>Authorization must bind the actor to the specific action at the service boundary on every request and message. UI gates, gateways, or prior steps do not substitute for function-level checks.</remember>
+</broken_function_level_authorization_guide>

strix/prompts/vulnerabilities/business_logic.jinja

@@ -0,0 +1,171 @@
+<business_logic_flaws_guide>
+<title>BUSINESS LOGIC FLAWS</title>
+
+<critical>Business logic flaws exploit intended functionality to violate domain invariants: move money without paying, exceed limits, retain privileges, or bypass reviews. They require a model of the business, not just payloads.</critical>
+
+<scope>
+- Financial logic: pricing, discounts, payments, refunds, credits, chargebacks
+- Account lifecycle: signup, upgrade/downgrade, trial, suspension, deletion
+- Authorization-by-logic: feature gates, role transitions, approval workflows
+- Quotas/limits: rate/usage limits, inventory, entitlements, seat licensing
+- Multi-tenant isolation: cross-organization data or action bleed
+- Event-driven flows: jobs, webhooks, sagas, compensations, idempotency
+</scope>
+
+<methodology>
+1. Enumerate a state machine per critical workflow (states, transitions, pre/post-conditions). Note invariants (e.g., "refund ≤ captured amount").
+2. Build an Actor × Action × Resource matrix with at least: unauth, basic user, premium, staff/admin; identify actions per role.
+3. For each transition, test step skipping, repetition, reordering, and late mutation (modify inputs after validation but before commit).
+4. Introduce time, concurrency, and channel variance: repeat with parallel requests, different content-types, mobile/web/API/GraphQL.
+5. Validate persistence boundaries: verify that all services, queues, and jobs re-enforce invariants (no trust in upstream validation).
+</methodology>
+
+<discovery_techniques>
+<workflow_mapping>
+- Derive endpoints from the UI and proxy/network logs; map hidden/undocumented API calls, especially finalize/confirm endpoints
+- Identify tokens/flags: stepToken, paymentIntentId, orderStatus, reviewState, approvalId; test reuse across users/sessions
+- Document invariants: conservation of value (ledger balance), uniqueness (idempotency), monotonicity (non-decreasing counters), exclusivity (one active subscription)
+</workflow_mapping>
+
+<input_surface>
+- Hidden fields and client-computed totals; server must recompute on trusted sources
+- Alternate encodings and shapes: arrays instead of scalars, objects with unexpected keys, null/empty/0/negative, scientific notation
+- Business selectors: currency, locale, timezone, tax region; vary to trigger rounding and ruleset changes
+</input_surface>
+
+<state_time_axes>
+- Replays: resubmit stale finalize/confirm requests
+- Out-of-order: call finalize before verify; refund before capture; cancel after ship
+- Time windows: end-of-day/month cutovers, daylight saving, grace periods, trial expiry edges
+</state_time_axes>
+</discovery_techniques>
+
+<high_value_targets>
+- Pricing/cart: price locks, quote to order, tax/shipping computation
+- Discount engines: stacking, mutual exclusivity, scope (cart vs item), once-per-user enforcement
+- Payments: auth/capture/void/refund sequences, partials, split tenders, chargebacks, idempotency keys
+- Credits/gift cards/vouchers: issuance, redemption, reversal, expiry, transferability
+- Subscriptions: proration, upgrade/downgrade, trial extension, seat counts, meter reporting
+- Refunds/returns/RMAs: multi-item partials, restocking fees, return window edges
+- Admin/staff operations: impersonation, manual adjustments, credit/refund issuance, account flags
+- Quotas/limits: daily/monthly usage, inventory reservations, feature usage counters
+</high_value_targets>
+
+<exploitation_techniques>
+<state_machine_abuse>
+- Skip or reorder steps via direct API calls; verify server enforces preconditions on each transition
+- Replay prior steps with altered parameters (e.g., swap price after approval but before capture)
+- Split a single constrained action into many sub-actions under the threshold (limit slicing)
+</state_machine_abuse>
+
+<concurrency_and_idempotency>
+- Parallelize identical operations to bypass atomic checks (create, apply, redeem, transfer)
+- Abuse idempotency: key scoped to path but not principal → reuse other users' keys; or idempotency stored only in cache
+- Message reprocessing: queue workers re-run tasks on retry without idempotent guards; cause duplicate fulfillment/refund
+</concurrency_and_idempotency>
+
+<numeric_and_currency>
+- Floating point vs decimal rounding; rounding/truncation favoring attacker at boundaries
+- Cross-currency arbitrage: buy in currency A, refund in B at stale rates; tax rounding per-item vs per-order
+- Negative amounts, zero-price, free shipping thresholds, minimum/maximum guardrails
+</numeric_and_currency>
+
+<quotas_limits_inventory>
+- Off-by-one and time-bound resets (UTC vs local); pre-warm at T-1s and post-fire at T+1s
+- Reservation/hold leaks: reserve multiple, complete one, release not enforced; backorder logic inconsistencies
+- Distributed counters without strong consistency enabling double-consumption
+</quotas_limits_inventory>
+
+<refunds_chargebacks>
+- Double-refund: refund via UI and support tool; refund partials summing above captured amount
+- Refund after benefits consumed (downloaded digital goods, shipped items) due to missing post-consumption checks
+</refunds_chargebacks>
+
+<feature_gates_and_roles>
+- Feature flags enforced client-side or at edge but not in core services; toggle names guessed or fallback to default-enabled
+- Role transitions leaving stale capabilities (retain premium after downgrade; retain admin endpoints after demotion)
+</feature_gates_and_roles>
+
+<advanced_techniques>
+<event_driven_sagas>
+- Saga/compensation gaps: trigger compensation without original success; or execute success twice without compensation
+- Outbox/Inbox patterns missing idempotency → duplicate downstream side effects
+- Cron/backfill jobs operating outside request-time authorization; mutate state broadly
+</event_driven_sagas>
+
+<microservices_boundaries>
+- Cross-service assumption mismatch: one service validates total, another trusts line items; alter between calls
+- Header trust: internal services trusting X-Role or X-User-Id from untrusted edges
+- Partial failure windows: two-phase actions where phase 1 commits without phase 2, leaving exploitable intermediate state
+</microservices_boundaries>
+
+<multi_tenant_isolation>
+- Tenant-scoped counters and credits updated without tenant key in the where-clause; leak across orgs
+- Admin aggregate views allowing actions that impact other tenants due to missing per-tenant enforcement
+</multi_tenant_isolation>
+
+<bypass_techniques>
+- Content-type switching (json/form/multipart) to hit different code paths
+- Method alternation (GET performing state change; overrides via X-HTTP-Method-Override)
+- Client recomputation: totals, taxes, discounts computed on client and accepted by server
+- Cache/gateway differentials: stale decisions from CDN/APIM that are not identity-aware
+</bypass_techniques>
+
+<special_contexts>
+<ecommerce>
+- Stack incompatible discounts via parallel apply; remove qualifying item after discount applied; retain free shipping after cart changes
+- Modify shipping tier post-quote; abuse returns to keep product and refund
+</ecommerce>
+
+<banking_fintech>
+- Split transfers to bypass per-transaction threshold; schedule vs instant path inconsistencies
+- Exploit grace periods on holds/authorizations to withdraw again before settlement
+</banking_fintech>
+
+<saas_b2b>
+- Seat licensing: race seat assignment to exceed purchased seats; stale license checks in background tasks
+- Usage metering: report late or duplicate usage to avoid billing or to over-consume
+</saas_b2b>
+</special_contexts>
+
+<chaining_attacks>
+- Business logic + race: duplicate benefits before state updates
+- Business logic + IDOR: operate on others' resources once a workflow leak reveals IDs
+- Business logic + CSRF: force a victim to complete a sensitive step sequence
+</chaining_attacks>
+
+<validation>
+1. Show an invariant violation (e.g., two refunds for one charge, negative inventory, exceeding quotas).
+2. Provide side-by-side evidence for intended vs abused flows with the same principal.
+3. Demonstrate durability: the undesired state persists and is observable in authoritative sources (ledger, emails, admin views).
+4. Quantify impact per action and at scale (unit loss × feasible repetitions).
+</validation>
+
+<false_positives>
+- Promotional behavior explicitly allowed by policy (documented free trials, goodwill credits)
+- Visual-only inconsistencies with no durable or exploitable state change
+- Admin-only operations with proper audit and approvals
+</false_positives>
+
+<impact>
+- Direct financial loss (fraud, arbitrage, over-refunds, unpaid consumption)
+- Regulatory/contractual violations (billing accuracy, consumer protection)
+- Denial of inventory/services to legitimate users through resource exhaustion
+- Privilege retention or unauthorized access to premium features
+</impact>
+
+<pro_tips>
+1. Start from invariants and ledgers, not UI—prove conservation of value breaks.
+2. Test with time and concurrency; many bugs only appear under pressure.
+3. Recompute totals server-side; never accept client math—flag when you observe otherwise.
+4. Treat idempotency and retries as first-class: verify key scope and persistence.
+5. Probe background workers and webhooks separately; they often skip auth and rule checks.
+6. Validate role/feature gates at the service that mutates state, not only at the edge.
+7. Explore end-of-period edges (month-end, trial end, DST) for rounding and window issues.
+8. Use minimal, auditable PoCs that demonstrate durable state change and exact loss.
+9. Chain with authorization tests (IDOR/Function-level access) to magnify impact.
+10. When in doubt, map the state machine; gaps appear where transitions lack server-side guards.
+</pro_tips>
+
+<remember>Business logic security is the enforcement of domain invariants under adversarial sequencing, timing, and inputs. If any step trusts the client or prior steps, expect abuse.</remember>
+</business_logic_flaws_guide>

strix/prompts/vulnerabilities/csrf.jinja

@@ -0,0 +1,174 @@
+<csrf_vulnerability_guide>
+<title>CROSS-SITE REQUEST FORGERY (CSRF)</title>
+
+<critical>CSRF abuses ambient authority (cookies, HTTP auth) across origins. Do not rely on CORS alone; enforce non-replayable tokens and strict origin checks for every state change.</critical>
+
+<scope>
+- Web apps with cookie-based sessions and HTTP auth
+- JSON/REST, GraphQL (GET/persisted queries), file upload endpoints
+- Authentication flows: login/logout, password/email change, MFA toggles
+- OAuth/OIDC: authorize, token, logout, disconnect/connect
+</scope>
+
+<methodology>
+1. Inventory all state-changing endpoints (including admin/staff) and note method, content-type, and whether they are reachable via top-level navigation or simple requests (no preflight).
+2. For each, determine session model (cookies with SameSite attrs, custom headers, tokens) and whether server enforces anti-CSRF tokens and Origin/Referer.
+3. Attempt preflightless delivery (form POST, text/plain, multipart/form-data) and top-level GET navigation.
+4. Validate across browsers; behavior differs by SameSite and navigation context.
+</methodology>
+
+<high_value_targets>
+- Credentials and profile changes (email/password/phone)
+- Payment and money movement, subscription/plan changes
+- API key/secret generation, PAT rotation, SSH keys
+- 2FA/TOTP enable/disable; backup codes; device trust
+- OAuth connect/disconnect; logout; account deletion
+- Admin/staff actions and impersonation flows
+- File uploads/deletes; access control changes
+</high_value_targets>
+
+<discovery_techniques>
+<session_and_cookies>
+- Inspect cookies: HttpOnly, Secure, SameSite (Strict/Lax/None). Note that Lax allows cookies on top-level cross-site GET; None requires Secure.
+- Determine if Authorization headers or bearer tokens are used (generally not CSRF-prone) versus cookies (CSRF-prone).
+</session_and_cookies>
+
+<token_and_header_checks>
+- Locate anti-CSRF tokens (hidden inputs, meta tags, custom headers). Test removal, reuse across requests, reuse across sessions, and binding to method/path.
+- Verify server checks Origin and/or Referer on state changes; test null/missing and cross-origin values.
+</token_and_header_checks>
+
+<method_and_content_types>
+- Confirm whether GET, HEAD, or OPTIONS perform state changes.
+- Try simple content-types to avoid preflight: application/x-www-form-urlencoded, multipart/form-data, text/plain.
+- Probe parsers that auto-coerce text/plain or form-encoded bodies into JSON.
+</method_and_content_types>
+
+<cors_profile>
+- Identify Access-Control-Allow-Origin and -Credentials. Overly permissive CORS is not a CSRF fix and can turn CSRF into data exfiltration.
+- Test per-endpoint CORS differences; preflight vs simple request behavior can diverge.
+</cors_profile>
+</discovery_techniques>
+
+<exploitation_techniques>
+<navigation_csrf>
+- Auto-submitting form to target origin; works when cookies are sent and no token/origin checks are enforced.
+- Top-level GET navigation can trigger state if server misuses GET or links actions to GET callbacks.
+</navigation_csrf>
+
+<simple_ct_csrf>
+- application/x-www-form-urlencoded and multipart/form-data POSTs do not require preflight; prefer these encodings.
+- text/plain form bodies can slip through validators and be parsed server-side.
+</simple_ct_csrf>
+
+<json_csrf>
+- If server parses JSON from text/plain or form-encoded bodies, craft parameters to reconstruct JSON server-side.
+- Some frameworks accept JSON keys via form fields (e.g., {% raw %}data[foo]=bar{% endraw %}) or treat duplicate keys leniently.
+</json_csrf>
+
+<login_logout_csrf>
+- Force logout to clear CSRF tokens, then chain login CSRF to bind victim to attacker’s account.
+- Login CSRF: submit attacker credentials to victim’s browser; later actions occur under attacker’s account.
+</login_logout_csrf>
+
+<oauth_oidc_flows>
+- Abuse authorize/logout endpoints reachable via GET or form POST without origin checks; exploit relaxed SameSite on top-level navigations.
+- Open redirects or loose redirect_uri validation can chain with CSRF to force unintended authorizations.
+</oauth_oidc_flows>
+
+<file_and_action_endpoints>
+- File upload/delete often lack token checks; forge multipart requests to modify storage.
+- Admin actions exposed as simple POST links are frequently CSRFable.
+</file_and_action_endpoints>
+</exploitation_techniques>
+
+<advanced_techniques>
+<samesite_nuance>
+- Lax-by-default cookies are sent on top-level cross-site GET but not POST; exploit GET state changes and GET-based confirmation steps.
+- Legacy or nonstandard clients may ignore SameSite; validate across browsers/devices.
+</samesite_nuance>
+
+<origin_referer_obfuscation>
+- Sandbox/iframes can produce null Origin; some frameworks incorrectly accept null.
+- about:blank/data: URLs alter Referer; ensure server requires explicit Origin/Referer match.
+</origin_referer_obfuscation>
+
+<method_override>
+- Backends honoring _method or X-HTTP-Method-Override may allow destructive actions through a simple POST.
+</method_override>
+
+<graphql_csrf>
+- If queries/mutations are allowed via GET or persisted queries, exploit top-level navigation with encoded payloads.
+- Batched operations may hide mutations within a nominally safe request.
+</graphql_csrf>
+
+<websocket_csrf>
+- Browsers send cookies on WebSocket handshake; enforce Origin checks server-side. Without them, cross-site pages can open authenticated sockets and issue actions.
+</websocket_csrf>
+</advanced_techniques>
+
+<bypass_techniques>
+<token_weaknesses>
+- Accepting missing/empty tokens; tokens not tied to session, user, or path; tokens reused indefinitely; tokens in GET.
+- Double-submit cookie without Secure/HttpOnly, or with predictable token sources.
+</token_weaknesses>
+
+<content_type_switching>
+- Switch between form, multipart, and text/plain to reach different code paths and validators.
+- Use duplicate keys and array shapes to confuse parsers.
+</content_type_switching>
+
+<header_manipulation>
+- Strip Referer via meta refresh or navigate from about:blank; test null Origin acceptance.
+- Leverage misconfigured CORS to add custom headers that servers mistakenly treat as CSRF tokens.
+</header_manipulation>
+</bypass_techniques>
+
+<special_contexts>
+<mobile_spa>
+- Deep links and embedded WebViews may auto-send cookies; trigger actions via crafted intents/links.
+- SPAs that rely solely on bearer tokens are less CSRF-prone, but hybrid apps mixing cookies and APIs can still be vulnerable.
+</mobile_spa>
+
+<integrations>
+- Webhooks and back-office tools sometimes expose state-changing GETs intended for staff; confirm CSRF defenses there too.
+</integrations>
+</special_contexts>
+
+<chaining_attacks>
+- CSRF + IDOR: force actions on other users' resources once references are known.
+- CSRF + Clickjacking: guide user interactions to bypass UI confirmations.
+- CSRF + OAuth mix-up: bind victim sessions to unintended clients.
+</chaining_attacks>
+
+<validation>
+1. Demonstrate a cross-origin page that triggers a state change without user interaction beyond visiting.
+2. Show that removing the anti-CSRF control (token/header) is accepted, or that Origin/Referer are not verified.
+3. Prove behavior across at least two browsers or contexts (top-level nav vs XHR/fetch).
+4. Provide before/after state evidence for the same account.
+5. If defenses exist, show the exact condition under which they are bypassed (content-type, method override, null Origin).
+</validation>
+
+<false_positives>
+- Token verification present and required; Origin/Referer enforced consistently.
+- No cookies sent on cross-site requests (SameSite=Strict, no HTTP auth) and no state change via simple requests.
+- Only idempotent, non-sensitive operations affected.
+</false_positives>
+
+<impact>
+- Account state changes (email/password/MFA), session hijacking via login CSRF, financial operations, administrative actions.
+- Durable authorization changes (role/permission flips, key rotations) and data loss.
+</impact>
+
+<pro_tips>
+1. Prefer preflightless vectors (form-encoded, multipart, text/plain) and top-level GET if available.
+2. Test login/logout, OAuth connect/disconnect, and account linking first.
+3. Validate Origin/Referer behavior explicitly; do not assume frameworks enforce them.
+4. Toggle SameSite and observe differences across navigation vs XHR.
+5. For GraphQL, attempt GET queries or persisted queries that carry mutations.
+6. Always try method overrides and parser differentials.
+7. Combine with clickjacking when visual confirmations block CSRF.
+</pro_tips>
+
+<remember>CSRF is eliminated only when state changes require a secret the attacker cannot supply and the server verifies the caller’s origin. Tokens and Origin checks must hold across methods, content-types, and transports.</remember>
+</csrf_vulnerability_guide>