strix-agent 0.1.1__py3-none-any.whl

strix/prompts/vulnerabilities/business_logic.jinja

@@ -0,0 +1,143 @@
+<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>
+
+<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
+</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>
+</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>
+
+<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>
+
+<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
+</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
+</false_positives>
+
+<impact>
+- Financial loss (direct monetary impact)
+- Unauthorized access to features/data
+- Service disruption
+- Compliance violations
+- Reputation damage
+</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
+</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>
+</business_logic_flaws_guide>

strix/prompts/vulnerabilities/csrf.jinja

@@ -0,0 +1,168 @@
+<csrf_vulnerability_guide>
+<title>CROSS-SITE REQUEST FORGERY (CSRF) - ADVANCED EXPLOITATION</title>
+
+<critical>CSRF forces authenticated users to execute unwanted actions, exploiting the trust a site has in the user's browser.</critical>
+
+<high_value_targets>
+- Password/email change forms
+- Money transfer/payment functions
+- Account deletion/deactivation
+- Permission/role changes
+- API key generation/regeneration
+- OAuth connection/disconnection
+- 2FA enable/disable
+- Privacy settings modification
+- Admin functions
+- File uploads/deletions
+</high_value_targets>
+
+<discovery_techniques>
+<token_analysis>
+Common token names: csrf_token, csrftoken, _csrf, authenticity_token, __RequestVerificationToken, X-CSRF-TOKEN
+
+Check if tokens are:
+- Actually validated (remove and test)
+- Tied to user session
+- Reusable across requests
+- Present in GET requests
+- Predictable or static
+</token_analysis>
+
+<http_methods>
+- Test if POST endpoints accept GET
+- Try method override headers: _method, X-HTTP-Method-Override
+- Check if PUT/DELETE lack protection
+</http_methods>
+</discovery_techniques>
+
+<exploitation_techniques>
+<basic_forms>
+HTML form auto-submit:
+<form action="https://target.com/transfer" method="POST">
+  <input name="amount" value="1000">
+  <input name="to" value="attacker">
+</form>
+<script>document.forms[0].submit()</script>
+</basic_forms>
+
+<json_csrf>
+For JSON endpoints:
+<form enctype="text/plain" action="https://target.com/api">
+  <input name='{"amount":1000,"to":"attacker","ignore":"' value='"}'>
+</form>
+</json_csrf>
+
+<multipart_csrf>
+For file uploads:
+Use XMLHttpRequest with credentials
+Generate multipart/form-data boundaries
+</multipart_csrf>
+</exploitation_techniques>
+
+<bypass_techniques>
+<token_bypasses>
+- Null token: remove parameter entirely
+- Empty token: csrf_token=
+- Token from own account: use your valid token
+- Token fixation: force known token value
+- Method interchange: GET token used for POST
+</token_bypasses>
+
+<header_bypasses>
+- Referer bypass: use data: URI, about:blank
+- Origin bypass: null origin via sandboxed iframe
+- CORS misconfigurations
+</header_bypasses>
+
+<content_type_tricks>
+- Change multipart to application/x-www-form-urlencoded
+- Use text/plain for JSON endpoints
+- Exploit parsers that accept multiple formats
+</content_type_tricks>
+</bypass_techniques>
+
+<advanced_techniques>
+<subdomain_csrf>
+- XSS on subdomain = CSRF on main domain
+- Cookie scope abuse (domain=.example.com)
+- Subdomain takeover for CSRF
+</subdomain_csrf>
+
+<csrf_login>
+- Force victim to login as attacker
+- Plant backdoors in victim's account
+- Access victim's future data
+</csrf_login>
+
+<csrf_logout>
+- Force logout → login CSRF → account takeover
+</csrf_logout>
+
+<double_submit_csrf>
+If using double-submit cookies:
+- Set cookie via XSS/subdomain
+- Cookie injection via header injection
+- Cookie tossing attacks
+</double_submit_csrf>
+</advanced_techniques>
+
+<special_contexts>
+<websocket_csrf>
+- Cross-origin WebSocket hijacking
+- Steal tokens from WebSocket messages
+</websocket_csrf>
+
+<graphql_csrf>
+- GET requests with query parameter
+- Batched mutations
+- Subscription abuse
+</graphql_csrf>
+
+<api_csrf>
+- Bearer tokens in URL parameters
+- API keys in GET requests
+- Insecure CORS policies
+</api_csrf>
+</special_contexts>
+
+<validation>
+To confirm CSRF:
+1. Create working proof-of-concept
+2. Test across browsers
+3. Verify action completes successfully
+4. No user interaction required (beyond visiting page)
+5. Works with active session
+</validation>
+
+<false_positives>
+NOT CSRF if:
+- Requires valid CSRF token
+- SameSite cookies properly configured
+- Proper origin/referer validation
+- User interaction required
+- Only affects non-sensitive actions
+</false_positives>
+
+<impact>
+- Account takeover
+- Financial loss
+- Data modification/deletion
+- Privilege escalation
+- Privacy violations
+</impact>
+
+<pro_tips>
+1. Check all state-changing operations
+2. Test file upload endpoints
+3. Look for token disclosure in URLs
+4. Chain with XSS for token theft
+5. Check mobile API endpoints
+6. Test CORS configurations
+7. Verify SameSite cookie settings
+8. Look for method override possibilities
+9. Test WebSocket endpoints
+10. Document clear attack scenario
+</pro_tips>
+
+<remember>Modern CSRF requires creativity - look for token leaks, chain with other vulnerabilities, and focus on high-impact actions. SameSite cookies are not always properly configured.</remember>
+</csrf_vulnerability_guide>

strix/prompts/vulnerabilities/idor.jinja

@@ -0,0 +1,164 @@
+<idor_vulnerability_guide>
+<title>INSECURE DIRECT OBJECT REFERENCE (IDOR) - ELITE TECHNIQUES</title>
+
+<critical>IDORs are among the HIGHEST IMPACT vulnerabilities - direct unauthorized data access and account takeover.</critical>
+
+<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
+</parameter_analysis>
+
+<advanced_enumeration>
+- Boundary values: 0, -1, null, empty string, max int
+- Different formats: {"id":123} vs {"id":"123"}
+- ID patterns: increment, decrement, similar patterns
+- Wildcard testing: *, %, _, all
+- Array notation: id[]=123&id[]=456
+</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
+</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: {"id": {"$ne": null}}
+</type_confusion>
+</exploitation_techniques>
+
+<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>
+
+<secondary_idor>
+First get list of IDs, then access:
+/api/users → [123, 456, 789]
+/api/user/789/private-data
+</secondary_idor>
+</advanced_techniques>
+
+<bypass_techniques>
+<parameter_pollution>
+?id=123&id=456 (takes last or first?)
+?user_id=victim&user_id=attacker
+</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>
+</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:
+{"subscribe": "user_456_notifications"}
+</websocket_idor>
+
+<file_path_idor>
+../../../other_user/private.pdf
+/files/user_123/../../user_456/data.csv
+</file_path_idor>
+</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
+</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
+</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
+</false_positives>
+
+<impact>
+- Personal data exposure
+- Financial information theft
+- Account takeover
+- Business data leak
+- Compliance violations (GDPR, HIPAA)
+</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
+</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>
+</idor_vulnerability_guide>

strix/prompts/vulnerabilities/race_conditions.jinja

@@ -0,0 +1,194 @@
+<race_conditions_guide>
+<title>RACE CONDITIONS - TIME-OF-CHECK TIME-OF-USE (TOCTOU) MASTERY</title>
+
+<critical>Race conditions lead to financial fraud, privilege escalation, and business logic bypass. Often overlooked but devastating.</critical>
+
+<high_value_targets>
+- Payment/checkout processes
+- Coupon/discount redemption
+- Account balance operations
+- Voting/rating systems
+- Limited resource allocation
+- User registration (username claims)
+- Password reset flows
+- File upload/processing
+- API rate limits
+- Loyalty points/rewards
+- Stock/inventory management
+- Withdrawal functions
+</high_value_targets>
+
+<discovery_techniques>
+<identify_race_windows>
+Multi-step processes with gaps between:
+1. Check phase (validation/verification)
+2. Use phase (action execution)
+3. Write phase (state update)
+
+Look for:
+- "Check balance then deduct"
+- "Verify coupon then apply"
+- "Check inventory then purchase"
+- "Validate token then consume"
+</identify_race_windows>
+
+<detection_methods>
+- Parallel requests with same data
+- Rapid sequential requests
+- Monitor for inconsistent states
+- Database transaction analysis
+- Response timing variations
+</detection_methods>
+</discovery_techniques>
+
+<exploitation_tools>
+<turbo_intruder>
+Python script for Burp Suite Turbo Intruder:
+```python
+def queueRequests(target, wordlists):
+    engine = RequestEngine(endpoint=target.endpoint,
+                          concurrentConnections=30,
+                          requestsPerConnection=100,
+                          pipeline=False)
+
+    for i in range(30):
+        engine.queue(target.req, gate='race1')
+
+    engine.openGate('race1')
+```
+</turbo_intruder>
+
+<manual_methods>
+- Browser developer tools (multiple tabs)
+- curl with & for background: curl url & curl url &
+- Python asyncio/aiohttp
+- Go routines
+- Node.js Promise.all()
+</manual_methods>
+</exploitation_tools>
+
+<common_vulnerabilities>
+<financial_races>
+- Double withdrawal
+- Multiple discount applications
+- Balance transfer duplication
+- Payment bypass
+- Cashback multiplication
+</financial_races>
+
+<authentication_races>
+- Multiple password resets
+- Account creation with same email
+- 2FA bypass
+- Session generation collision
+</authentication_races>
+
+<resource_races>
+- Inventory depletion bypass
+- Rate limit circumvention
+- File overwrite
+- Token reuse
+</resource_races>
+</common_vulnerabilities>
+
+<advanced_techniques>
+<single_packet_attack>
+HTTP/2 multiplexing for true simultaneous delivery:
+- All requests in single TCP packet
+- Microsecond precision
+- Bypass even mutex locks
+</single_packet_attack>
+
+<last_byte_sync>
+Send all but last byte, then:
+1. Hold connections open
+2. Send final byte simultaneously
+3. Achieve nanosecond precision
+</last_byte_sync>
+
+<connection_warming>
+Pre-establish connections:
+1. Create connection pool
+2. Prime with dummy requests
+3. Send race requests on warm connections
+</connection_warming>
+</advanced_techniques>
+
+<bypass_techniques>
+<distributed_attacks>
+- Multiple source IPs
+- Different user sessions
+- Varied request headers
+- Geographic distribution
+</distributed_attacks>
+
+<timing_optimization>
+- Measure server processing time
+- Align requests with server load
+- Exploit maintenance windows
+- Target async operations
+</timing_optimization>
+</bypass_techniques>
+
+<specific_scenarios>
+<limit_bypass>
+"Limited to 1 per user" → Send N parallel requests
+Results: N successful purchases
+</limit_bypass>
+
+<balance_manipulation>
+Transfer $100 from account with $100 balance:
+- 10 parallel transfers
+- Each checks balance: $100 available
+- All proceed: -$900 balance
+</balance_manipulation>
+
+<vote_manipulation>
+Single vote limit:
+- Send multiple vote requests simultaneously
+- All pass validation
+- Multiple votes counted
+</vote_manipulation>
+</specific_scenarios>
+
+<validation>
+To confirm race condition:
+1. Demonstrate parallel execution success
+2. Show single request fails
+3. Prove timing dependency
+4. Document financial/security impact
+5. Achieve consistent reproduction
+</validation>
+
+<false_positives>
+NOT a race condition if:
+- Idempotent operations
+- Proper locking mechanisms
+- Atomic database operations
+- Queue-based processing
+- No security impact
+</false_positives>
+
+<impact>
+- Financial loss (double spending)
+- Resource exhaustion
+- Data corruption
+- Business logic bypass
+- Privilege escalation
+</impact>
+
+<pro_tips>
+1. Use HTTP/2 for better synchronization
+2. Automate with Turbo Intruder
+3. Test payment flows extensively
+4. Monitor database locks
+5. Try different concurrency levels
+6. Test async operations
+7. Look for compensating transactions
+8. Check mobile app endpoints
+9. Test during high load
+10. Document exact timing windows
+</pro_tips>
+
+<remember>Modern race conditions require microsecond precision. Focus on financial operations and limited resource allocation. Single-packet attacks are most reliable.</remember>
+</race_conditions_guide>