/business-logic

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: 1. Understand the application's purpose 2. Map all user roles and permissions 3. Identify critical workflows (money, data, access) 4. Document trust assumptions between components 5. 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

1. **Identify User Roles**

• Anonymous
• Authenticated (regular user)
• Premium/Paid user
• Admin/Staff
• Super Admin

2. **Find Critical Workflows**

• Authentication flow
• **Registration/onboarding** (privileged usernames, role injection, rate limiting)
• Payment/checkout
• Password reset
• Data export
• Admin functions

3. **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)