| name | Business Logic Analysis |
| description | This skill should be used when the user asks about "business logic", "workflow vulnerability", "trust boundary", "state machine", "authorization bypass", "multi-step process", "workflow bypass", "application logic flaw", or needs to identify business logic vulnerabilities during whitebox security review. |
| version | 1.0.0 |
Business Logic Analysis
Purpose
Provide comprehensive knowledge of business logic vulnerabilities - flaws that arise from incorrect assumptions about how users will interact with an application, rather than from traditional injection or parsing errors.
Key Insight: Unlike technical vulnerabilities (SQLi, XSS), business logic flaws require deep understanding of what the application is supposed to do. You cannot find them without first understanding the application.
When to Use
Activate this skill when:
- Beginning a whitebox security review (understand before hunt)
- Analyzing multi-step workflows (checkout, registration, auth)
- Reviewing authorization and access control
- Looking for ways to abuse intended functionality
- Identifying trust boundaries between components
Core Concepts
1. Deep Application Understanding
Before hunting for business logic bugs:
- Understand the application's purpose
- Map all user roles and permissions
- Identify critical workflows (money, data, access)
- Document trust assumptions between components
- Model state machines for multi-step processes
2. Trust Boundaries
Trust boundaries exist where:
- Frontend communicates with backend
- Service A calls Service B
- Application trusts database content
- External APIs are consumed
- User-controlled data crosses privilege levels
Common flaw: Backend trusts frontend validation, allowing bypass.
3. State Machine Vulnerabilities
Multi-step processes have states. Vulnerabilities arise from:
- Skipping states (jump from step 1 to step 4)
- Invalid transitions (completed → pending)
- Replaying states (submit same step twice)
- Concurrent state manipulation (race)
Vulnerability Categories
Authorization Logic Flaws
| Flaw | Pattern | Impact |
|---|
| IDOR | Direct object reference without ownership check | Access other users' data |
| Horizontal Privilege Escalation | Role check missing on specific action | Act as peer user |
| Vertical Privilege Escalation | Admin function callable by regular user | Gain admin access |
| Function-Level Access Control | Endpoint has no auth check | Bypass authentication |
Workflow Bypass
| Flaw | Pattern | Impact |
|---|
| Step Skipping | No enforcement of workflow sequence | Bypass verification steps |
| State Manipulation | Direct modification of state parameters | Change order/payment status |
| Race Conditions | Non-atomic check-then-use | Double-spend, over-redeem |
| Replay Attacks | Action can be repeated without limit | Free resources, repeated discounts |
Input Trust Issues
| Flaw | Pattern | Impact |
|---|
| Client-Side Validation Only | Backend trusts frontend checks | Bypass all input validation |
| Price Manipulation | Price sent from client | Purchase at arbitrary price |
| Quantity Manipulation | Quantity not validated server-side | Order more than allowed |
| Hidden Field Tampering | User role/ID in hidden field | Impersonate other users |
Methodology
Phase 1: Map the Application
-
Identify User Roles
- Anonymous
- Authenticated (regular user)
- Premium/Paid user
- Admin/Staff
- Super Admin
-
Find Critical Workflows
- Authentication flow
- Registration/onboarding (privileged usernames, role injection, rate limiting)
- Payment/checkout
- Password reset
- Data export
- Admin functions
-
Document Trust Boundaries
- What validates user input?
- Where are authorization checks?
- What does the backend trust?
Phase 2: Model State Machines
For each critical workflow:
[State A] --action--> [State B] --action--> [State C]
^
|
What prevents:
- Skipping B?
- Reversing to A?
- Racing through B?
Phase 3: Identify Attack Surface
Look for:
- Parameters that control flow (step, status, role)
- IDs/references without ownership validation
- Values that should be server-controlled but come from client
- Actions that should be rate-limited or single-use
Phase 4: Test Hypotheses
Develop test cases:
- What if I skip step 2?
- What if I change user_id to another user?
- What if I modify the price?
- What if I send request 100x simultaneously?
Code Review Indicators
Authorization Flaws
def get_order(order_id):
return Order.query.get(order_id)
def get_order(order_id, user):
return Order.query.filter_by(id=order_id, user_id=user.id).first()
Trust Boundary Issues
def update_user(request):
user.role = request.data['role']
def update_user(request, current_user):
if current_user.is_admin:
user.role = request.data['role']
State Manipulation
def update_order_status(request, order_id):
order = Order.query.get(order_id)
order.status = request.data['status']
def ship_order(order_id, admin_user):
if admin_user.has_permission('ship'):
order = Order.query.get(order_id)
if order.status == 'paid':
order.status = 'shipped'
Grep Patterns
Find Authorization Checks (or lack thereof)
grep -rniE "\.get\s*\(\s*[a-z_]+_id\s*\)" --include="*.py"
grep -rniE "findById|getById|find\(.*id\)" --include="*.java" --include="*.js"
grep -rniE "(is_admin|has_role|has_permission|authorize)" --include="*.py" --include="*.java" --include="*.php"
grep -rniE "@(login_required|authenticated|requires_auth)" --include="*.py"
Find Trust Boundary Issues
grep -rniE "request\.(data|json|form)\[.*(role|admin|price|discount|status)\]" --include="*.py"
grep -rniE "req\.body\.(role|admin|price|discount|status)" --include="*.js"
grep -rniE "type=['\"]hidden['\"].*name=['\"].*id" --include="*.html" --include="*.php" --include="*.erb"
Find State Machine Logic
grep -rniE "(status|state|step)\s*=\s*(request|req|params)" --include="*.py" --include="*.java" --include="*.php" --include="*.js"
grep -rniE "(step|stage|phase)\s*(==|!=|>=|<=)" --include="*.py" --include="*.java" --include="*.php" --include="*.js"
Find Registration Security Issues
grep -rniE "(def|function|func)\s+(register|signup|create_user)" --include="*.py" --include="*.php" --include="*.js" --include="*.go" -A 20 | grep -vE "(reserved|blocked|forbidden)"
grep -rniE "role.*=.*request\.(data|json|form|body)|is_admin.*=.*request" --include="*.py" --include="*.php" --include="*.js"
grep -rniE "username.*=.*request" --include="*.py" --include="*.php" --include="*.js" | grep -v "lower\|upper\|strip"
grep -rniE "@(app\.|router\.)(route|post).*register" --include="*.py" --include="*.js" | grep -v "limiter\|throttle"
Integration with Other Skills
- Use dangerous-functions after mapping trust boundaries
- Use data-flow-tracing to trace user input through authorization checks
- Use vuln-patterns/race-conditions for state manipulation attacks
- Use exploit-techniques to develop PoC for confirmed logic flaws
Reference Files
For detailed patterns and examples:
references/workflow-patterns.md - Multi-step process bypass techniques
references/trust-boundaries.md - Trust boundary analysis and common flaws
references/state-machine-bugs.md - State transition vulnerabilities