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

strix/prompts/vulnerabilities/idor.jinja

@@ -1,164 +1,195 @@
 <idor_vulnerability_guide>
-<title>INSECURE DIRECT OBJECT REFERENCE (IDOR) - ELITE TECHNIQUES</title>
+<title>INSECURE DIRECT OBJECT REFERENCE (IDOR)</title>
 
-<critical>IDORs are among the HIGHEST IMPACT vulnerabilities - direct unauthorized data access and account takeover.</critical>
+<critical>Object- and function-level authorization failures (BOLA/IDOR) routinely lead to cross-account data exposure and unauthorized state changes across APIs, web, mobile, and microservices. Treat every object reference as untrusted until proven bound to the caller.</critical>
+
+<scope>
+- Horizontal access: access another subject's objects of the same type
+- Vertical access: access privileged objects/actions (admin-only, staff-only)
+- Cross-tenant access: break isolation boundaries in multi-tenant systems
+- Cross-service access: token or context accepted by the wrong service
+</scope>
+
+<methodology>
+1. Build a Subject × Object × Action matrix (who can do what to which resource).
+2. For each resource type, obtain at least two principals: owner and non-owner (plus admin/staff if applicable). Capture at least one valid object ID per principal.
+3. Exercise every action (R/W/D/Export) while swapping IDs, tokens, tenants, and channels (web, mobile, API, GraphQL, WebSocket, gRPC).
+4. Track consistency: the same rule must hold regardless of transport, content-type, serialization, or gateway.
+</methodology>
 
 <discovery_techniques>
 <parameter_analysis>
-- Numeric IDs: user_id=123, account=456
-- UUID/GUID patterns: id=550e8400-e29b-41d4-a716-446655440000
-- Encoded IDs: Base64, hex, custom encoding
-- Composite IDs: user-org-123-456, ACCT:2024:00123
-- Hash-based IDs: Check if predictable (MD5 of sequential numbers)
-- Object references in: URLs, POST bodies, headers, cookies, JWT tokens
+- Object references appear in: paths, query params, JSON bodies, form-data, headers, cookies, JWT claims, GraphQL arguments, WebSocket messages, gRPC messages
+- Identifier forms: integers, UUID/ULID/CUID, Snowflake, slugs, composite keys (e.g., {orgId}:{userId}), opaque tokens, base64/hex-encoded blobs
+- Relationship references: parentId, ownerId, accountId, tenantId, organization, teamId, projectId, subscriptionId
+- Expansion/projection knobs: fields, include, expand, projection, with, select, populate (often bypass authorization in resolvers or serializers)
+- Pagination/cursors: page[offset], page[limit], cursor, nextPageToken (often reveal or accept cross-tenant/state)
 </parameter_analysis>
 
 <advanced_enumeration>
-- Boundary values: 0, -1, null, empty string, max int
-- Different formats: {% raw %}{"id":123} vs {"id":"123"}{% endraw %}
-- ID patterns: increment, decrement, similar patterns
-- Wildcard testing: *, %, _, all
-- Array notation: id[]=123&id[]=456
+- Alternate types: {% raw %}{"id":123}{% endraw} vs {% raw %}{"id":"123"}{% endraw}, arrays vs scalars, objects vs scalars, null/empty/0/-1/MAX_INT, scientific notation, overflows, unknown attributes retained by backend
+- Duplicate keys/parameter pollution: id=1&id=2, JSON duplicate keys {% raw %}{"id":1,"id":2}{% endraw} (parser precedence differences)
+- Case/aliasing: userId vs userid vs USER_ID; alt names like resourceId, targetId, account
+- Path traversal-like in virtual file systems: /files/user_123/../../user_456/report.csv
+- Directory/list endpoints as seeders: search/list/suggest/export often leak object IDs for secondary exploitation
 </advanced_enumeration>
 </discovery_techniques>
 
 <high_value_targets>
-- User profiles and PII
-- Financial records/transactions
-- Private messages/communications
-- Medical records
-- API keys/secrets
-- Internal documents
-- Admin functions
-- Export endpoints
-- Backup files
-- Debug information
+- Exports/backups/reporting endpoints (CSV/PDF/ZIP)
+- Messaging/mailbox/notifications, audit logs, activity feeds
+- Billing: invoices, payment methods, transactions, credits
+- Healthcare/education records, HR documents, PII/PHI/PCI
+- Admin/staff tools, impersonation/session management
+- File/object storage keys (S3/GCS signed URLs, share links)
+- Background jobs: import/export job IDs, task results
+- Multi-tenant resources: organizations, workspaces, projects
 </high_value_targets>
 
 <exploitation_techniques>
-<direct_access>
-Simple increment/decrement:
-/api/user/123 → /api/user/124
-/download?file=report_2024_01.pdf → report_2024_02.pdf
-</direct_access>
-
-<mass_enumeration>
-Automate ID ranges:
-for i in range(1, 10000):
-    /api/user/{i}/data
-</mass_enumeration>
-
-<type_confusion>
-- String where int expected: "123" vs 123
-- Array where single value expected: [123] vs 123
-- Object injection: {% raw %}{"id": {"$ne": null}}{% endraw %}
-</type_confusion>
-</exploitation_techniques>
+<horizontal_vertical>
+- Swap object IDs between principals using the same token to probe horizontal access; then repeat with lower-privilege tokens to probe vertical access
+- Target partial updates (PATCH, JSON Patch/JSON Merge Patch) for silent unauthorized modifications
+</horizontal_vertical>
 
-<advanced_techniques>
-<uuid_prediction>
-- Time-based UUIDs (version 1): predictable timestamps
-- Weak randomness in version 4
-- Sequential UUID generation
-</uuid_prediction>
-
-<blind_idor>
-- Side channel: response time, size differences
-- Error message variations
-- Boolean-based: exists vs not exists
-</blind_idor>
+<bulk_and_batch>
+- Batch endpoints (bulk update/delete) often validate only the first element; include cross-tenant IDs mid-array
+- CSV/JSON imports referencing foreign object IDs (ownerId, orgId) may bypass create-time checks
+</bulk_and_batch>
 
 <secondary_idor>
-First get list of IDs, then access:
-/api/users → [123, 456, 789]
-/api/user/789/private-data
+- Use list/search endpoints, notifications, emails, webhooks, and client logs to collect valid IDs, then fetch or mutate those objects directly
+- Pagination/cursor manipulation to skip filters and pull other users' pages
 </secondary_idor>
+
+<job_task_objects>
+- Access job/task IDs from one user to retrieve results for another (export/{jobId}/download, reports/{taskId})
+- Cancel/approve someone else's jobs by referencing their task IDs
+</job_task_objects>
+
+<file_object_storage>
+- Direct object paths or weakly scoped signed URLs; attempt key prefix changes, content-disposition tricks, or stale signatures reused across tenants
+- Replace share tokens with tokens from other tenants; try case/URL-encoding variations
+</file_object_storage>
+</exploitation_techniques>
+
+<advanced_techniques>
+<graphql>
+- Enforce resolver-level checks: do not rely on a top-level gate. Verify field and edge resolvers bind the resource to the caller on every hop
+- Abuse batching/aliases to retrieve multiple users' nodes in one request and compare responses
+- Global node patterns (Relay): decode base64 IDs and swap raw IDs; test {% raw %}node(id: "...base64..."){...}{% endraw %}
+- Overfetching via fragments on privileged types; verify hidden fields cannot be queried by unprivileged callers
+- Example:
+{% raw %}
+query IDOR {
+  me { id }
+  u1: user(id: "VXNlcjo0NTY=") { email billing { last4 } }
+  u2: node(id: "VXNlcjo0NTc=") { ... on User { email } }
+}
+{% endraw %}
+</graphql>
+
+<microservices_gateways>
+- Token confusion: a token scoped for Service A accepted by Service B due to shared JWT verification but missing audience/claims checks
+- Trust on headers: reverse proxies or API gateways injecting/trusting headers like X-User-Id, X-Organization-Id; try overriding or removing them
+- Context loss: async consumers (queues, workers) re-process requests without re-checking authorization
+</microservices_gateways>
+
+<multi_tenant>
+- Probe tenant scoping through headers, subdomains, and path params (e.g., X-Tenant-ID, org slug). Try mixing org of token with resource from another org
+- Test cross-tenant reports/analytics rollups and admin views which aggregate multiple tenants
+</multi_tenant>
+
+<uuid_and_opaque_ids>
+- UUID/ULID are not authorization: acquire valid IDs from logs, exports, JS bundles, analytics endpoints, emails, or public activity, then test ownership binding
+- Time-based IDs (UUIDv1, ULID) may be guessable within a window; combine with leakage sources for targeted access
+</uuid_and_opaque_ids>
+
+<blind_channels>
+- Use differential responses (status, size, ETag, timing) to detect existence; error shape often differs for owned vs foreign objects
+- HEAD/OPTIONS, conditional requests (If-None-Match/If-Modified-Since) can confirm existence without full content
+</blind_channels>
 </advanced_techniques>
 
 <bypass_techniques>
+<parser_and_transport>
+- Content-type switching: application/json ↔ application/x-www-form-urlencoded ↔ multipart/form-data; some paths enforce checks per parser
+- Method tunneling: X-HTTP-Method-Override, _method=PATCH; or using GET on endpoints incorrectly accepting state changes
+- JSON duplicate keys/array injection to bypass naive validators
+</parser_and_transport>
+
 <parameter_pollution>
-?id=123&id=456 (takes last or first?)
-?user_id=victim&user_id=attacker
+- Duplicate parameters in query/body to influence server-side precedence (id=123&id=456); try both orderings
+- Mix case/alias param names so gateway and backend disagree (userId vs userid)
 </parameter_pollution>
 
-<encoding_tricks>
-- URL encode: %31%32%33
-- Double encoding: %25%33%31
-- Unicode: \u0031\u0032\u0033
-</encoding_tricks>
-
-<case_variation>
-userId vs userid vs USERID vs UserId
-</case_variation>
-
-<format_switching>
-/api/user.json?id=123
-/api/user.xml?id=123
-/api/user/123.json vs /api/user/123
-</format_switching>
+<cache_and_gateway>
+- CDN/proxy key confusion: responses keyed without Authorization or tenant headers expose cached objects to other users; manipulate Vary and Accept
+- Redirect chains and 304/206 behaviors can leak content across tenants
+</cache_and_gateway>
+
+<race_windows>
+- Time-of-check vs time-of-use: change the referenced ID between validation and execution using parallel requests
+</race_windows>
 </bypass_techniques>
 
 <special_contexts>
-<graphql_idor>
-Query batching and alias abuse:
-query { u1: user(id: 123) { data } u2: user(id: 456) { data } }
-</graphql_idor>
-
-<websocket_idor>
-Subscribe to other users' channels:
-{% raw %}{"subscribe": "user_456_notifications"}{% endraw %}
-</websocket_idor>
-
-<file_path_idor>
-../../../other_user/private.pdf
-/files/user_123/../../user_456/data.csv
-</file_path_idor>
+<websocket>
+- Authorization per-subscription: ensure channel/topic names cannot be guessed (user_{id}, org_{id}); subscribe/publish checks must run server-side, not only at handshake
+- Try sending messages with target user IDs after subscribing to own channels
+</websocket>
+
+<grpc>
+- Direct protobuf fields (owner_id, tenant_id) often bypass HTTP-layer middleware; validate references via grpcurl with tokens from different principals
+</grpc>
+
+<integrations>
+- Webhooks/callbacks referencing foreign objects (e.g., invoice_id) processed without verifying ownership
+- Third-party importers syncing data into wrong tenant due to missing tenant binding
+</integrations>
 </special_contexts>
 
 <chaining_attacks>
-- IDOR + XSS: Access and weaponize other users' data
-- IDOR + CSRF: Force actions on discovered objects
-- IDOR + SQLi: Extract all IDs then access
+- IDOR + CSRF: force victims to trigger unauthorized changes on objects you discovered
+- IDOR + Stored XSS: pivot into other users' sessions through data you gained access to
+- IDOR + SSRF: exfiltrate internal IDs, then access their corresponding resources
+- IDOR + Race: bypass spot checks with simultaneous requests
 </chaining_attacks>
 
 <validation>
-To confirm IDOR:
-1. Access data/function without authorization
-2. Demonstrate data belongs to another user
-3. Show consistent access pattern
-4. Prove it's not intended functionality
-5. Document security impact
+1. Demonstrate access to an object not owned by the caller (content or metadata).
+2. Show the same request fails with appropriately enforced authorization when corrected.
+3. Prove cross-channel consistency: same unauthorized access via at least two transports (e.g., REST and GraphQL).
+4. Document tenant boundary violations (if applicable).
+5. Provide reproducible steps and evidence (requests/responses for owner vs non-owner).
 </validation>
 
 <false_positives>
-NOT IDOR if:
-- Public data by design
-- Proper authorization checks
-- Only affects own resources
-- Rate limiting prevents exploitation
-- Data is sanitized/limited
+- Public/anonymous resources by design
+- Soft-privatized data where content is already public
+- Idempotent metadata lookups that do not reveal sensitive content
+- Correct row-level checks enforced across all channels
 </false_positives>
 
 <impact>
-- Personal data exposure
-- Financial information theft
-- Account takeover
-- Business data leak
-- Compliance violations (GDPR, HIPAA)
+- Cross-account data exposure (PII/PHI/PCI)
+- Unauthorized state changes (transfers, role changes, cancellations)
+- Cross-tenant data leaks violating contractual and regulatory boundaries
+- Regulatory risk (GDPR/HIPAA/PCI), fraud, reputational damage
 </impact>
 
 <pro_tips>
-1. Test all ID parameters systematically
-2. Look for patterns in IDs
-3. Check export/download functions
-4. Test different HTTP methods
-5. Monitor for blind IDOR via timing
-6. Check mobile APIs separately
-7. Look for backup/debug endpoints
-8. Test file path traversal
-9. Automate enumeration carefully
-10. Chain with other vulnerabilities
+1. Always test list/search/export endpoints first; they are rich ID seeders.
+2. Build a reusable ID corpus from logs, notifications, emails, and client bundles.
+3. Toggle content-types and transports; authorization middleware often differs per stack.
+4. In GraphQL, validate at resolver boundaries; never trust parent auth to cover children.
+5. In multi-tenant apps, vary org headers, subdomains, and path params independently.
+6. Check batch/bulk operations and background job endpoints; they frequently skip per-item checks.
+7. Inspect gateways for header trust and cache key configuration.
+8. Treat UUIDs as untrusted; obtain them via OSINT/leaks and test binding.
+9. Use timing/size/ETag differentials for blind confirmation when content is masked.
+10. Prove impact with precise before/after diffs and role-separated evidence.
 </pro_tips>
 
-<remember>IDORs are about broken access control, not just guessable IDs. Even GUIDs can be vulnerable if disclosed elsewhere. Focus on high-impact data access.</remember>
+<remember>Authorization must bind subject, action, and specific object on every request, regardless of identifier opacity or transport. If the binding is missing anywhere, the system is vulnerable.</remember>
 </idor_vulnerability_guide>

strix/prompts/vulnerabilities/insecure_file_uploads.jinja

@@ -0,0 +1,188 @@
+<insecure_file_uploads_guide>
+<title>INSECURE FILE UPLOADS</title>
+
+<critical>Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware distribution, storage takeover, and DoS. Modern stacks mix direct-to-cloud uploads, background processors, and CDNs—authorization and validation must hold across every step.</critical>
+
+<scope>
+- Web/mobile/API uploads, direct-to-cloud (S3/GCS/Azure) presigned flows, resumable/multipart protocols (tus, S3 MPU)
+- Image/document/media pipelines (ImageMagick/GraphicsMagick, Ghostscript, ExifTool, PDF engines, office converters)
+- Admin/bulk importers, archive uploads (zip/tar), report/template uploads, rich text with attachments
+- Serving paths: app directly, object storage, CDN, email attachments, previews/thumbnails
+</scope>
+
+<methodology>
+1. Map the pipeline: client → ingress (edge/app/gateway) → storage → processors (thumb, OCR, AV, CDR) → serving (app/storage/CDN). Note where validation and auth occur.
+2. Identify allowed types, size limits, filename rules, storage keys, and who serves the content. Collect baseline uploads per type and capture resulting URLs and headers.
+3. Exercise bypass families systematically: extension games, MIME/content-type, magic bytes, polyglots, metadata payloads, archive structure, chunk/finalize differentials.
+4. Validate execution and rendering: can uploaded content execute on server or client? Confirm with minimal PoCs and headers analysis.
+</methodology>
+
+<discovery_techniques>
+<surface_map>
+- Endpoints/fields: upload, file, avatar, image, attachment, import, media, document, template
+- Direct-to-cloud params: key, bucket, acl, Content-Type, Content-Disposition, x-amz-meta-*, cache-control
+- Resumable APIs: create/init → upload/chunk → complete/finalize; check if metadata/headers can be altered late
+- Background processors: thumbnails, PDF→image, virus scan queues; identify timing and status transitions
+</surface_map>
+
+<capability_probes>
+- Small probe files of each claimed type; diff resulting Content-Type, Content-Disposition, and X-Content-Type-Options on download
+- Magic bytes vs extension: JPEG/GIF/PNG headers; mismatches reveal reliance on extension or MIME sniffing
+- SVG/HTML probe: do they render inline (text/html or image/svg+xml) or download (attachment)?
+- Archive probe: simple zip with nested path traversal entries and symlinks to detect extraction rules
+</capability_probes>
+</discovery_techniques>
+
+<detection_channels>
+<server_execution>
+- Web shell execution (language dependent), config/handler uploads (.htaccess, .user.ini, web.config) enabling execution
+- Interpreter-side template/script evaluation during conversion (ImageMagick/Ghostscript/ExifTool)
+</server_execution>
+
+<client_execution>
+- Stored XSS via SVG/HTML/JS if served inline without correct headers; PDF JavaScript; office macros in previewers
+</client_execution>
+
+<header_and_render>
+- Missing X-Content-Type-Options: nosniff enabling browser sniff to script
+- Content-Type reflection from upload vs server-set; Content-Disposition: inline vs attachment
+</header_and_render>
+
+<process_side_effects>
+- AV/CDR race or absence; background job status allows access before scan completes; password-protected archives bypass scanning
+</process_side_effects>
+</detection_channels>
+
+<core_payloads>
+<web_shells_and_configs>
+- PHP: GIF polyglot (starts with GIF89a) followed by <?php echo 1; ?>; place where PHP is executed
+- .htaccess to map extensions to code (AddType/AddHandler); .user.ini (auto_prepend/append_file) for PHP-FPM
+- ASP/JSP equivalents where supported; IIS web.config to enable script execution
+</web_shells_and_configs>
+
+<stored_xss>
+- SVG with onload/onerror handlers served as image/svg+xml or text/html
+- HTML file with script when served as text/html or sniffed due to missing nosniff
+</stored_xss>
+
+<mime_magic_polyglots>
+- Double extensions: avatar.jpg.php, report.pdf.html; mixed casing: .pHp, .PhAr
+- Magic-byte spoofing: valid JPEG header then embedded script; verify server uses content inspection, not extensions alone
+</mime_magic_polyglots>
+
+<archive_attacks>
+- Zip Slip: entries with ../../ to escape extraction dir; symlink-in-zip pointing outside target; nested zips
+- Zip bomb: extreme compression ratios (e.g., 42.zip) to exhaust resources in processors
+</archive_attacks>
+
+<toolchain_exploits>
+- ImageMagick/GraphicsMagick legacy vectors (policy.xml may mitigate): crafted SVG/PS/EPS invoking external commands or reading files
+- Ghostscript in PDF/PS with file operators (%pipe%)
+- ExifTool metadata parsing bugs; overly large or crafted EXIF/IPTC/XMP fields
+</toolchain_exploits>
+
+<cloud_storage_vectors>
+- S3/GCS presigned uploads: attacker controls Content-Type/Disposition; set text/html or image/svg+xml and inline rendering
+- Public-read ACL or permissive bucket policies expose uploads broadly; object key injection via user-controlled path prefixes
+- Signed URL reuse and stale URLs; serving directly from bucket without attachment + nosniff headers
+</cloud_storage_vectors>
+</core_payloads>
+
+<advanced_techniques>
+<resumable_multipart>
+- Change metadata between init and complete (e.g., swap Content-Type/Disposition at finalize)
+- Upload benign chunks, then swap last chunk or complete with different source if server trusts client-side digests only
+</resumable_multipart>
+
+<filename_and_path>
+- Unicode homoglyphs, trailing dots/spaces, device names, reserved characters to bypass validators and filesystem rules
+- Null-byte truncation on legacy stacks; overlong paths; case-insensitive collisions overwriting existing files
+</filename_and_path>
+
+<processing_races>
+- Request file immediately after upload but before AV/CDR completes; or during derivative creation to get unprocessed content
+- Trigger heavy conversions (large images, deep PDFs) to widen race windows
+</processing_races>
+
+<metadata_abuse>
+- Oversized EXIF/XMP/IPTC blocks to trigger parser flaws; payloads in document properties of Office/PDF rendered by previewers
+</metadata_abuse>
+
+<header_manipulation>
+- Force inline rendering with Content-Type + inline Content-Disposition; test browsers with and without nosniff
+- Cache poisoning via CDN with keys missing Vary on Content-Type/Disposition
+</header_manipulation>
+</advanced_techniques>
+
+<filter_bypasses>
+<validation_gaps>
+- Client-side only checks; relying on JS/MIME provided by browser; trusting multipart boundary part headers blindly
+- Extension allowlists without server-side content inspection; magic-bytes only without full parsing
+</validation_gaps>
+
+<evasion_tricks>
+- Double extensions, mixed case, hidden dotfiles, extra dots (file..png), long paths with allowed suffix
+- Multipart name vs filename vs path discrepancies; duplicate parameters and late parameter precedence
+</evasion_tricks>
+</filter_bypasses>
+
+<special_contexts>
+<rich_text_editors>
+- RTEs allow image/attachment uploads and embed links; verify sanitization and serving headers for embedded content
+</rich_text_editors>
+
+<mobile_clients>
+- Mobile SDKs may send nonstandard MIME or metadata; servers sometimes trust client-side transformations or EXIF orientation
+</mobile_clients>
+
+<serverless_and_cdn>
+- Direct-to-bucket uploads with Lambda/Workers post-processing; verify that security decisions are not delegated to frontends
+- CDN caching of uploaded content; ensure correct cache keys and headers (attachment, nosniff)
+</serverless_and_cdn>
+</special_contexts>
+
+<parser_hardening>
+- Validate on server: strict allowlist by true type (parse enough to confirm), size caps, and structural checks (dimensions, page count)
+- Strip active content: convert SVG→PNG; remove scripts/JS from PDF; disable macros; normalize EXIF; consider CDR for risky types
+- Store outside web root; serve via application or signed, time-limited URLs with Content-Disposition: attachment and X-Content-Type-Options: nosniff
+- For cloud: private buckets, per-request signed GET, enforce Content-Type/Disposition on GET responses from your app/gateway
+- Disable execution in upload paths; ignore .htaccess/.user.ini; sanitize keys to prevent path injections; randomize filenames
+- AV + CDR: scan synchronously when possible; quarantine until verdict; block password-protected archives or process in sandbox
+</parser_hardening>
+
+<validation>
+1. Demonstrate execution or rendering of active content: web shell reachable, or SVG/HTML executing JS when viewed.
+2. Show filter bypass: upload accepted despite restrictions (extension/MIME/magic mismatch) with evidence on retrieval.
+3. Prove header weaknesses: inline rendering without nosniff or missing attachment; present exact response headers.
+4. Show race or pipeline gap: access before AV/CDR; extraction outside intended directory; derivative creation from malicious input.
+5. Provide reproducible steps: request/response for upload and subsequent access, with minimal PoCs.
+</validation>
+
+<false_positives>
+- Upload stored but never served back; or always served as attachment with strict nosniff
+- Converters run in locked-down sandboxes with no external IO and no script engines; no path traversal on archive extraction
+- AV/CDR blocks the payload and quarantines; access before scan is impossible by design
+</false_positives>
+
+<impact>
+- Remote code execution on application stack or media toolchain host
+- Persistent cross-site scripting and session/token exfiltration via served uploads
+- Malware distribution via public storage/CDN; brand/reputation damage
+- Data loss or corruption via overwrite/zip slip; service degradation via zip bombs or oversized assets
+</impact>
+
+<pro_tips>
+1. Keep PoCs minimal: tiny SVG/HTML for XSS, a single-line PHP/ASP where relevant, and benign magic-byte polyglots.
+2. Always capture download response headers and final MIME from the server/CDN; that decides browser behavior.
+3. Prefer transforming risky formats to safe renderings (SVG→PNG) rather than attempting complex sanitization.
+4. In presigned flows, constrain all headers and object keys server-side; ignore client-supplied ACL and metadata.
+5. For archives, extract in a chroot/jail with explicit allowlist; drop symlinks and reject traversal.
+6. Test finalize/complete steps in resumable flows; many validations only run on init, not at completion.
+7. Verify background processors with EICAR and tiny polyglots; ensure quarantine gates access until safe.
+8. When you cannot get execution, aim for stored XSS or header-driven script execution; both are impactful.
+9. Validate that CDNs honor attachment/nosniff and do not override Content-Type/Disposition.
+10. Document full pipeline behavior per asset type; defenses must match actual processors and serving paths.
+</pro_tips>
+
+<remember>Secure uploads are a pipeline property. Enforce strict type, size, and header controls; transform or strip active content; never execute or inline-render untrusted uploads; and keep storage private with controlled, signed access.</remember>
+</insecure_file_uploads_guide>

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>