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

strix/prompts/technologies/supabase.jinja

@@ -0,0 +1,189 @@
+<supabase_security_guide>
+<title>SUPABASE — ADVERSARIAL TESTING AND EXPLOITATION</title>
+
+<critical>Supabase exposes Postgres through PostgREST, Realtime, GraphQL, Storage, Auth (GoTrue), and Edge Functions. Most impactful findings come from mis-scoped Row Level Security (RLS), unsafe RPCs, leaked service_role keys, lax Storage policies, GraphQL overfetching, and Edge Functions trusting headers or tokens without binding to issuer/audience/tenant.</critical>
+
+<scope>
+- PostgREST: table CRUD, filters, embeddings, RPC (remote functions)
+- RLS: row ownership/tenant isolation via policies and auth.uid()
+- Storage: buckets, objects, signed URLs, public/private policies
+- Realtime: replication subscriptions, broadcast/presence channels
+- GraphQL: pg_graphql over Postgres schema with RLS interaction
+- Auth (GoTrue): JWTs, cookie/session, magic links, OAuth flows
+- Edge Functions (Deno): server-side code calling Supabase with secrets
+</scope>
+
+<methodology>
+1. Inventory surfaces: REST /rest/v1, Storage /storage/v1, GraphQL /graphql/v1, Realtime wss, Auth /auth/v1, Functions https://<project>.functions.supabase.co/.
+2. Obtain tokens for: unauth (anon), basic user, other user, and (if disclosed) admin/staff; enumerate anon key exposure and verify if service_role leaked anywhere.
+3. Build a Resource × Action × Principal matrix and test each via REST and GraphQL. Confirm parity across channels and content-types (json/form/multipart).
+4. Start with list/search/export endpoints to gather IDs, then attempt direct reads/writes across principals, tenants, and transports. Validate RLS and function guards.
+</methodology>
+
+<architecture>
+- Project endpoints: https://<ref>.supabase.co; REST at /rest/v1/<table>, RPC at /rest/v1/rpc/<fn>.
+- Headers: apikey: <anon-or-service>, Authorization: Bearer <JWT>. Anon key only identifies the project; JWT binds user context.
+- Roles: anon, authenticated; service_role bypasses RLS and must never be client-exposed.
+- auth.uid(): current user UUID claim; policies must never trust client-supplied IDs over server context.
+</architecture>
+
+<rls>
+- Enable RLS on every non-public table; absence or “permit-all” policies → bulk exposure.
+- Common gaps:
+  - Policies check auth.uid() for read but forget UPDATE/DELETE/INSERT.
+  - Missing tenant constraints (org_id/tenant_id) allow cross-tenant reads/writes.
+  - Policies rely on client-provided columns (user_id in payload) instead of deriving from JWT.
+  - Complex joins where the effective policy is applied after filters, enabling inference via counts or projections.
+- Tests:
+  - Compare results for two users: GET /rest/v1/<table>?select=*&Prefer=count=exact; diff row counts and IDs.
+  - Try cross-tenant: add &org_id=eq.<other_org> or use or=(org_id.eq.other,org_id.is.null).
+  - Write-path: PATCH/DELETE single row with foreign id; INSERT with foreign owner_id then read.
+</rls>
+
+<postgrest_and_rest>
+- Filters: eq, neq, lt, gt, ilike, or, is, in; embed relations with select=*,profile(*); exploit embeddings to overfetch linked rows if resolvers skip per-row checks.
+- Headers to know: Prefer: return=representation (echo writes), Prefer: count=exact (exposure via counts), Accept-Profile/Content-Profile to select schema.
+- IDOR patterns: /rest/v1/<table>?select=*&id=eq.<other_id>; query alternative keys (slug, email) and composite keys.
+- Search leaks: generous LIKE/ILIKE filters + lack of RLS → mass disclosure.
+- Mass assignment: if RPC not used, PATCH can update unintended columns; verify restricted columns via database permissions/policies.
+</postgrest_and_rest>
+
+<rpc_functions>
+- RPC endpoints map to SQL functions. SECURITY DEFINER bypasses RLS unless carefully coded; SECURITY INVOKER respects caller.
+- Anti-patterns:
+  - SECURITY DEFINER + missing owner checks → vertical/horizontal bypass.
+  - set search_path left to public; function resolves unsafe objects.
+  - Trusting client-supplied user_id/tenant_id rather than auth.uid().
+- Tests:
+  - Call /rest/v1/rpc/<fn> as different users with foreign ids in body.
+  - Remove or alter JWT entirely (Authorization: Bearer <anon>) to see if function still executes.
+  - Validate that functions perform explicit ownership/tenant checks inside SQL, not only in docs.
+</rpc_functions>
+
+<storage>
+- Buckets: public vs private; objects live in storage.objects with RLS-like policies.
+- Find misconfigs:
+  - Public buckets holding sensitive data: GET https://<ref>.supabase.co/storage/v1/object/public/<bucket>/<path>
+  - Signed URLs with long TTL and no audience binding; reuse/guess tokens across tenants/paths.
+  - Listing prefixes without auth: /storage/v1/object/list/<bucket>?prefix=
+  - Path confusion: mixed case, URL-encoding, “..” segments rejected at UI but accepted by API.
+- Abuse vectors:
+  - Content-type/XSS: upload HTML/SVG served as text/html or image/svg+xml; confirm X-Content-Type-Options: nosniff and Content-Disposition: attachment.
+  - Signed URL replay across accounts/buckets if validation is lax.
+</storage>
+
+<realtime>
+- Endpoint: wss://<ref>.supabase.co/realtime/v1. Join channels with apikey + Authorization.
+- Risks:
+  - Channel names derived from table/schema/filters leaking other users’ updates when RLS or channel guards are weak.
+  - Broadcast/presence channels allowing cross-room join/publish without auth checks.
+- Tests:
+  - Subscribe to public:realtime changes on protected tables; confirm row data visibility aligns with RLS.
+  - Attempt joining other users’ presence/broadcast channels (e.g., room:<user_id>, org:<id>).
+</realtime>
+
+<graphql>
+- Endpoint: /graphql/v1 using pg_graphql with RLS. Risks:
+  - Introspection reveals schema relations; ensure it’s intentional.
+  - Overfetch via nested relations where field resolvers fail to re-check ownership/tenant.
+  - Global node IDs (if implemented) leaked and reusable via different viewers.
+- Tests:
+  - Compare REST vs GraphQL responses for the same principal and query shape.
+  - Query deep nested fields and connections; verify RLS holds at each edge.
+</graphql>
+
+<auth_and_tokens>
+- GoTrue issues JWTs with claims (sub=uid, role, aud=authenticated). Validate on server: issuer, audience, exp, signature, and tenant context.
+- Pitfalls:
+  - Storing tokens in localStorage → XSS exfiltration; refresh mismanagement leading to long-lived sessions.
+  - Treating apikey as identity; it is project-scoped, not user identity.
+  - Exposing service_role key in client bundle or Edge Function responses.
+- Tests:
+  - Replay tokens across services; check audience/issuer pinning.
+  - Try downgraded tokens (expired/other audience) against custom endpoints.
+</auth_and_tokens>
+
+<edge_functions>
+- Deno-based functions often initialize server-side Supabase client with service_role. Risks:
+  - Trusting Authorization/apikey headers without verifying JWT against issuer/audience.
+  - CORS: wildcard origins with credentials; reflected Authorization in responses.
+  - SSRF via fetch; secrets exposed via error traces or logs.
+- Tests:
+  - Call functions with and without Authorization; compare behavior.
+  - Try foreign resource IDs in function payloads; verify server re-derives user/tenant from JWT.
+  - Attempt to reach internal endpoints (metadata services, project endpoints) via function fetch.
+</edge_functions>
+
+<tenant_isolation>
+- Ensure every query joins or filters by tenant_id/org_id derived from JWT context, not client input.
+- Tests:
+  - Change subdomain/header/path tenant selectors while keeping JWT tenant constant; look for cross-tenant data.
+  - Export/report endpoints: confirm queries execute under caller scope; signed outputs must encode tenant and short TTL.
+</tenant_isolation>
+
+<bypass_techniques>
+- Content-type switching: application/json ↔ application/x-www-form-urlencoded ↔ multipart/form-data to hit different code paths.
+- Parameter pollution: duplicate keys in JSON/query; PostgREST chooses last/first depending on parser.
+- GraphQL+REST parity probing: protections often drift; fetch via the weaker path.
+- Race windows: parallel writes to bypass post-insert ownership updates.
+</bypass_techniques>
+
+<blind_channels>
+- Use Prefer: count=exact and ETag/length diffs to infer unauthorized rows.
+- Conditional requests (If-None-Match) to detect object existence without content exposure.
+- Storage signed URLs: timing/length deltas to map valid vs invalid tokens.
+</blind_channels>
+
+<tooling_and_automation>
+- PostgREST: httpie/curl + jq; enumerate tables with known names; fuzz filters (or=, ilike, neq, is.null).
+- GraphQL: graphql-inspector, voyager; build deep queries to test field-level enforcement; complexity/batching tests.
+- Realtime: custom ws client; subscribe to suspicious channels/tables; diff payloads per principal.
+- Storage: enumerate bucket listing APIs; script signed URL generation/use patterns.
+- Auth/JWT: jwt-cli/jose to validate audience/issuer; replay against Edge Functions.
+- Policy diffing: maintain request sets per role and compare results across releases.
+</tooling_and_automation>
+
+<reviewer_checklist>
+- Are all non-public tables RLS-enabled with explicit SELECT/INSERT/UPDATE/DELETE policies?
+- Do policies derive subject/tenant from JWT (auth.uid(), tenant claim) rather than client payload?
+- Do RPC functions run as SECURITY INVOKER, or if DEFINER, do they enforce ownership/tenant inside?
+- Are Storage buckets private by default, with short-lived signed URLs bound to tenant/context?
+- Does Realtime enforce RLS-equivalent filtering for subscriptions and block cross-room joins?
+- Is GraphQL parity verified with REST; are nested resolvers guarded per field?
+- Are Edge Functions verifying JWT (issuer/audience) and never exposing service_role to clients?
+- Are CDN/cache keys bound to Authorization/tenant to prevent cache leaks?
+</reviewer_checklist>
+
+<validation>
+1. Provide owner vs non-owner requests for REST/GraphQL showing unauthorized access (content or metadata).
+2. Demonstrate a mis-scoped RPC or Storage signed URL usable by another user/tenant.
+3. Confirm Realtime or GraphQL exposure matches missing policy checks.
+4. Document minimal reproducible requests and role contexts used.
+</validation>
+
+<false_positives>
+- Tables intentionally public (documented) with non-sensitive content.
+- RLS-enabled tables returning only caller-owned rows; mismatched UI not backed by API responses.
+- Signed URLs with very short TTL and audience binding.
+- Edge Functions verifying tokens and re-deriving context before acting.
+</false_positives>
+
+<impact>
+- Cross-account/tenant data exposure and unauthorized state changes.
+- Exfiltration of PII/PHI/PCI, financial and billing artifacts, private files.
+- Privilege escalation via RPC and Edge Functions; durable access via long-lived tokens.
+- Regulatory and contractual violations stemming from tenant isolation failures.
+</impact>
+
+<pro_tips>
+1. Start with /rest/v1 list/search; counts and embeddings reveal policy drift fast.
+2. Treat UUIDs and signed URLs as untrusted; validate binding to subject/tenant and TTL.
+3. Focus on RPC and Edge Functions—they often centralize business logic and skip RLS.
+4. Test GraphQL and Realtime parity with REST; differences are where vulnerabilities hide.
+5. Keep role-separated request corpora and diff responses across deployments.
+6. Never assume apikey == identity; only JWT binds subject. Prove it.
+7. Prefer concise PoCs: one request per role that clearly shows the unauthorized delta.
+</pro_tips>
+
+<remember>RLS must bind subject and tenant on every path, and server-side code (RPC/Edge) must re-derive identity from a verified token. Any gap in binding, audience/issuer verification, or per-field enforcement becomes a cross-account or cross-tenant vulnerability.</remember>
+</supabase_security_guide>

strix/prompts/vulnerabilities/authentication_jwt.jinja

@@ -1,129 +1,147 @@
 <authentication_jwt_guide>
-<title>AUTHENTICATION & JWT VULNERABILITIES</title>
-
-<critical>Authentication flaws lead to complete account takeover. JWT misconfigurations are everywhere.</critical>
-
-<jwt_structure>
-header.payload.signature
-- Header: {% raw %}{"alg":"HS256","typ":"JWT"}{% endraw %}
-- Payload: {% raw %}{"sub":"1234","name":"John","iat":1516239022}{% endraw %}
-- Signature: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
-</jwt_structure>
-
-<common_attacks>
-<algorithm_confusion>
-RS256 to HS256:
-- Change RS256 to HS256 in header
-- Use public key as HMAC secret
-- Sign token with public key (often in /jwks.json or /.well-known/)
-</algorithm_confusion>
-
-<none_algorithm>
-- Set {% raw %}"alg": "none"{% endraw %} in header
-- Remove signature completely (keep the trailing dot)
-</none_algorithm>
-
-<weak_secrets>
-Common secrets: 'secret', 'password', '123456', 'key', 'jwt_secret', 'your-256-bit-secret'
-</weak_secrets>
-
-<kid_manipulation>
-- SQL Injection: {% raw %}"kid": "key' UNION SELECT 'secret'--"{% endraw %}
-- Command injection: {% raw %}"kid": "|sleep 10"{% endraw %}
-- Path traversal: {% raw %}"kid": "../../../../../../dev/null"{% endraw %}
-</kid_manipulation>
-</common_attacks>
+<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>
-<jwk_injection>
-Embed public key in token header:
-{% raw %}{"jwk": {"kty": "RSA", "n": "your-public-key-n", "e": "AQAB"}}{% endraw %}
-</jwk_injection>
-
-<jku_manipulation>
-Set jku/x5u to attacker-controlled URL hosting malicious JWKS
-</jku_manipulation>
-
-<timing_attacks>
-Extract signature byte-by-byte using verification timing differences
-</timing_attacks>
-</advanced_techniques>
-
-<oauth_vulnerabilities>
-<authorization_code_theft>
-- Exploit redirect_uri with open redirects, subdomain takeover, parameter pollution
-- Missing/predictable state parameter = CSRF
-- PKCE downgrade: remove code_challenge parameter
-</authorization_code_theft>
-</oauth_vulnerabilities>
-
-<saml_attacks>
-- Signature exclusion: remove signature element
-- Signature wrapping: inject assertions
-- XXE in SAML responses
-</saml_attacks>
-
-<session_attacks>
-- Session fixation: force known session ID
-- Session puzzling: mix different session objects
-- Race conditions in session generation
-</session_attacks>
-
-<password_reset_flaws>
-- Predictable tokens: MD5(timestamp), sequential numbers
-- Host header injection for reset link poisoning
-- Race condition resets
-</password_reset_flaws>
-
-<mfa_bypass>
-- Response manipulation: change success:false to true
-- Status code manipulation: 403 to 200
-- Brute force with no rate limiting
-- Backup code abuse
-</mfa_bypass>
-
-<advanced_bypasses>
-<unicode_normalization>
-Different representations: admin@exａmple.com (fullwidth), аdmin@example.com (Cyrillic)
-</unicode_normalization>
-
-<authentication_chaining>
-- JWT + SQLi: kid parameter with SQL injection
-- OAuth + XSS: steal tokens via XSS
-- SAML + XXE + SSRF: chain for internal access
-</authentication_chaining>
-</advanced_bypasses>
-
-<tools>
-- jwt_tool: Comprehensive JWT testing
-- Check endpoints: /login, /oauth/authorize, /saml/login, /.well-known/openid-configuration, /jwks.json
-</tools>
+<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>
-To confirm authentication flaw:
-1. Demonstrate account access without credentials
-2. Show privilege escalation
-3. Prove token forgery works
-4. Bypass authentication/2FA requirements
-5. Maintain persistent access
+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>
-NOT a vulnerability if:
-- Requires valid credentials
-- Only affects own session
-- Proper signature validation
-- Token expiration enforced
-- Rate limiting prevents brute force
+- 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: access other users' accounts
-- Privilege escalation: user to admin
-- Token forgery: create valid tokens
-- Bypass mechanisms: skip auth/2FA
-- Persistent access: survives logout
+- 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>
 
-<remember>Focus on RS256->HS256, weak secrets, and none algorithm first. Modern apps use multiple auth methods simultaneously - find gaps in integration.</remember>
+<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>