strix-agent 0.1.17__py3-none-any.whl → 0.1.19__py3-none-any.whl

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

@@ -1,143 +1,171 @@
 <business_logic_flaws_guide>
-<title>BUSINESS LOGIC FLAWS - OUTSMARTING THE APPLICATION</title>
-
-<critical>Business logic flaws bypass all technical security controls by exploiting flawed assumptions in application workflow. Often the highest-paying vulnerabilities.</critical>
+<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>
-- Map complete user journeys and state transitions
-- Document developer assumptions
-- Find edge cases in workflows
-- Look for missing validation steps
-- Identify trust boundaries
+<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>
-<financial_workflows>
-- Price manipulation (negative quantities, decimal truncation)
-- Currency conversion abuse (buy weak, refund strong)
-- Discount/coupon stacking
-- Payment method switching after verification
-- Cart manipulation during checkout
-</financial_workflows>
-
-<account_management>
-- Registration race conditions (same email/username)
-- Account type elevation
-- Trial period extension
-- Subscription downgrade with feature retention
-</account_management>
-
-<authorization_flaws>
-- Function-level bypass (accessing admin functions as user)
-- Object reference manipulation
-- Permission inheritance bugs
-- Multi-tenancy isolation failures
-</authorization_flaws>
+- 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>
-<race_conditions>
-Use race conditions to:
-- Double-spend vouchers/credits
-- Bypass rate limits
-- Create duplicate accounts
-- Exploit TOCTOU vulnerabilities
-</race_conditions>
-
-<state_manipulation>
-- Skip workflow steps
-- Replay previous states
-- Force invalid state transitions
-- Manipulate hidden parameters
-</state_manipulation>
-
-<input_manipulation>
-- Type confusion: string where int expected
-- Boundary values: 0, -1, MAX_INT
-- Format abuse: scientific notation, Unicode
-- Encoding tricks: double encoding, mixed encoding
-</input_manipulation>
-</exploitation_techniques>
-
-<common_flaws>
-<shopping_cart>
-- Add items with negative price
-- Modify prices client-side
-- Apply expired coupons
-- Stack incompatible discounts
-- Change currency after price lock
-</shopping_cart>
-
-<payment_processing>
-- Complete order before payment
-- Partial payment acceptance
-- Payment replay attacks
-- Void after delivery
-- Refund more than paid
-</payment_processing>
-
-<user_lifecycle>
-- Premium features in trial
-- Account deletion bypasses
-- Privilege retention after demotion
-- Transfer restrictions bypass
-</user_lifecycle>
-</common_flaws>
+<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>
-<business_constraint_violations>
-- Exceed account limits
-- Bypass geographic restrictions
-- Violate temporal constraints
-- Break dependency chains
-</business_constraint_violations>
-
-<workflow_abuse>
-- Parallel execution of exclusive processes
-- Recursive operations (infinite loops)
-- Asynchronous timing exploitation
-- Callback manipulation
-</workflow_abuse>
-</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>
-To confirm business logic flaw:
-1. Demonstrate financial impact
-2. Show consistent reproduction
-3. Prove bypass of intended restrictions
-4. Document assumption violation
-5. Quantify potential damage
+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>
-NOT a business logic flaw if:
-- Requires technical vulnerability (SQLi, XSS)
-- Working as designed (bad design ≠ vulnerability)
-- Only affects display/UI
-- No security impact
-- Requires privileged access
+- 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>
-- Financial loss (direct monetary impact)
-- Unauthorized access to features/data
-- Service disruption
-- Compliance violations
-- Reputation damage
+- 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. Think like a malicious user, not a developer
-2. Question every assumption
-3. Test boundary conditions obsessively
-4. Combine multiple small issues
-5. Focus on money flows
-6. Check state machines thoroughly
-7. Abuse features, don't break them
-8. Document business impact clearly
-9. Test integration points
-10. Time is often a factor - exploit it
+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 flaws are about understanding and exploiting the application's rules, not breaking them with technical attacks. The best findings come from deep understanding of the business domain.</remember>
+<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>