Business Logic Analysis
npx machina-cli add skill allsmog/vuln-scout/business-logic --openclawBusiness 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 pentest (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
# VULNERABLE - No ownership check
def get_order(order_id):
return Order.query.get(order_id) # Any user can access any order
# SECURE
def get_order(order_id, user):
return Order.query.filter_by(id=order_id, user_id=user.id).first()
Trust Boundary Issues
# VULNERABLE - Trusting client-provided role
def update_user(request):
user.role = request.data['role'] # User can set their own role!
# SECURE
def update_user(request, current_user):
if current_user.is_admin: # Server-side check
user.role = request.data['role']
State Manipulation
# VULNERABLE - State as client parameter
def update_order_status(request, order_id):
order = Order.query.get(order_id)
order.status = request.data['status'] # User can set order to "shipped"!
# SECURE - Server controls state transitions
def ship_order(order_id, admin_user):
if admin_user.has_permission('ship'):
order = Order.query.get(order_id)
if order.status == 'paid': # Valid transition check
order.status = 'shipped'
Grep Patterns
Find Authorization Checks (or lack thereof)
# Look for direct object access without filtering by user
grep -rniE "\.get\s*\(\s*[a-z_]+_id\s*\)" --include="*.py"
grep -rniE "findById|getById|find\(.*id\)" --include="*.java" --include="*.js"
# Find role/permission checks
grep -rniE "(is_admin|has_role|has_permission|authorize)" --include="*.py" --include="*.java" --include="*.php"
# Find missing auth decorators (compare with route definitions)
grep -rniE "@(login_required|authenticated|requires_auth)" --include="*.py"
Find Trust Boundary Issues
# Client-controlled sensitive values
grep -rniE "request\.(data|json|form)\[.*(role|admin|price|discount|status)\]" --include="*.py"
grep -rniE "req\.body\.(role|admin|price|discount|status)" --include="*.js"
# Hidden field patterns in templates
grep -rniE "type=['\"]hidden['\"].*name=['\"].*id" --include="*.html" --include="*.php" --include="*.erb"
Find State Machine Logic
# Status/state transitions
grep -rniE "(status|state|step)\s*=\s*(request|req|params)" --include="*.py" --include="*.java" --include="*.php" --include="*.js"
# Workflow step handling
grep -rniE "(step|stage|phase)\s*(==|!=|>=|<=)" --include="*.py" --include="*.java" --include="*.php" --include="*.js"
Find Registration Security Issues
# Privileged username registration (absence of reserved check is the vulnerability)
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)"
# Role injection in registration
grep -rniE "role.*=.*request\.(data|json|form|body)|is_admin.*=.*request" --include="*.py" --include="*.php" --include="*.js"
# Missing username normalization
grep -rniE "username.*=.*request" --include="*.py" --include="*.php" --include="*.js" | grep -v "lower\|upper\|strip"
# Missing rate limiting on registration
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 techniquesreferences/trust-boundaries.md- Trust boundary analysis and common flawsreferences/state-machine-bugs.md- State transition vulnerabilities
Source
git clone https://github.com/allsmog/vuln-scout/blob/main/whitebox-pentest/skills/business-logic/SKILL.mdView on GitHub Overview
Business Logic Analysis helps pentesters identify flaws that arise from how users interact with an application, not just technical bugs. It requires understanding workflows, trust boundaries, and state transitions to detect authorization bypasses and misordered steps.
How This Skill Works
The skill combines deep application understanding, mapping user roles and critical workflows, and documenting trust boundaries. It then models state machines for multi-step processes and categorizes vulnerabilities into Authorization Logic Flaws, Workflow Bypass, and Input Trust Issues to guide focused testing.
When to Use It
- Beginning a whitebox pentest (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
Quick Start
- Step 1: Map user roles (Anonymous, Authenticated, Premium, Admin) and identify critical workflows (auth, checkout, data export).
- Step 2: Document trust boundaries (where backend relies on frontend validation, and how components trust each other).
- Step 3: Model the state machine for multi-step processes and actively test for skips, invalid transitions, replays, and race conditions.
Best Practices
- Map all user roles and permissions before testing
- Document trust assumptions and boundaries between components
- Model state machines for multi-step processes and test for skips, invalid transitions, and replays
- Test critical workflows (money, data, access) for enforcement gaps
- Do not rely solely on client-side validation; validate on the server side
Example Use Cases
- Step Skipping: Bypassing verification steps by skipping steps in a multi-step workflow
- IDOR: Direct object reference without ownership checks to access other users’ data
- Hidden Field Tampering: User role/ID manipulated in a hidden field to impersonate others
- Price Manipulation: Client-sent price leads to purchases at arbitrary prices
- Race Conditions: Non-atomic check-then-use allowing double-spend or over-redeem