Business Logic Flaws - Logikfehler in Anwendungen

Business Logic Flaws are the most insidious vulnerabilities in web applications: They do not result from faulty programming (such as SQL injection), but from the incorrect implementation of business rules. An automated scanner only sees HTTP requests—it does not understand that "order quantity -5" should result in a negative price. Only experienced testers with an understanding of the business process can identify these gaps.

Categories and Examples

Category 1 - Price Manipulation:

Scenario: E-commerce with client-side pricing
  POST /cart/checkout
  {
    "item_id": "laptop_123",
    "price": 999.99,  ← Client sends the price!
    "quantity": 1
  }

  Attack: Set price to 0.01
  POST /cart/checkout
  { "item_id": "laptop_123", "price": 0.01, "quantity": 1 }
  → If the server accepts the client-side price: Laptop for 1 cent!

  Further price manipulations:
  → Negative quantities: quantity: -1 (receive credit instead of paying)
  → Integer overflow: quantity: 9999999999 (price overflows to 0)
  → Discount manipulation: discount_percent: 100 (free product)

Category 2 - Workflow Bypass:

Scenario: Multi-step checkout (3 steps)
  Step 1: Enter address → /checkout/step1
  Step 2: Select payment method → /checkout/step2
  Step 3: Confirm → /checkout/step3

  Attack: Jump directly to /checkout/step3
  → If server does not validate state: Order placed without payment!
  → Check if step3 can be executed without step2

  Typical workflows to test:
  → Password reset: Go directly to "Set new password" without a token
  → Email verification: Use account features before confirmation
  → Admin actions: Skip the "Approval" step

Category 3 - Coupon/Voucher Abuse:

  Scenarios:
  → Redeem a one-time voucher multiple times (Race Condition!)
  → Brute-force voucher codes (short, predictable codes)
  → Redeem vouchers for other user accounts (IDOR!)
  → Negative balance through combination of multiple vouchers

  Race Condition (parallel redemption attack):
  → Redeem the same voucher code 100 times in parallel
  → If no atomic DB operation: multiple redemptions possible

Category 4 - Privilege/Role Confusion:

  Scenario: Buyer can use "Seller" function
  → Profile endpoint: PATCH /api/user (allowed for own profile)
  → Include "role" field in request: {"role": "admin"}
  → If server retrieves role from request body instead of JWT: Privilege escalation!

  Mass Assignment (related issue):
  → ORM/framework copies all POST fields to DB update
  → is_admin: true, is_premium: true, credit: 10000
  → Framework sets all fields automatically!

Category 5 - Money/Credit Logic:

  Scenarios:
  → Request withdrawal (pending) → Delete account → Withdrawal still processed?
  → Transfer to self (source_account = dest_account): Amount doubled?
  → Exploit currency conversion with different rates
  → Cryptocurrency withdrawals with manipulated decimal places

Detection in the Penetration Test

Business Logic Testing Methodology:

Preparation (CRITICAL - Domain expertise required!):
  □ Thoroughly review and understand the application
  □ Document all transaction flows
  □ Price calculation: where? Client or server?
  □ What steps are involved? Can they be skipped?
  □ What user roles exist?
  □ Where is money/credits transferred?

Manual Tests (cannot be automated!):

1. Identify price fields in all requests:
   → Burp Suite: Check all requests for "price", "amount", "cost"
   → Manipulate every price value found:
     - 0
     - -1
     - 0.001
     - 99999999999

2. Workflow mapping and step skipping:
   → Track all steps of a workflow in Burp HTTP History
   → Call the last step directly (referrer check?)
   → Use cookies/sessions from step N in step N+2

3. Parameter fuzzing for mass assignment:
   → Known fields: all fields from the response back into the request
   → Try sensitive fields:
     is_admin, is_premium, role, verified, credit_balance, status
   → Difference between "Field ignored" and "Field updated"?

4. Coupon race condition test (ethical!):
   # Burp Suite Intruder with zero payload:
   # 50 parallel requests with the same coupon code
   # HTTP/2 single-packet attack (Turbo Intruder)
   # → Can multiple redemptions be detected in response data?

5. State manipulation between requests:
   → Check intermediate state: What if the account is deleted while the transfer is in progress?
   → Two-user test: User A and User B simultaneously (transaction isolation?)

Tools:
  Burp Suite Pro:  HTTP History, Repeater, Intruder (Race Conditions)
  OWASP ZAP:       Not a good BLF scanner (manual testing remains mandatory!)
  ffuf/feroxbuster: Parameter discovery
  BApp Store:      Turbo Intruder (Race Condition Testing)

Mitigation Measures

Secure Business Logic Implementation:

1. ALWAYS calculate prices on the server side:
   // WRONG - Use client price:
   final_price = req.body.price * req.body.quantity;

   // CORRECT - Server calculates from product DB:
   const product = await db.products.findById(req.body.item_id);
   const final_price = product.price * req.body.quantity;  // Always!
   // IGNORE client-side price values!

2. Server-Side State for Workflows:
   // Step validation in session/DB:
   if (req.session.checkout_step < 2) {
     return res.status(400).json({ error: 'Previous step not completed' });
   }
   // DO NOT rely on the Referer header!

3. Quantity validation:
   if (quantity <= 0 || quantity > MAX_ORDER_QUANTITY) {
     return res.status(400).json({ error: 'Invalid quantity' });
   }

4. Redeem coupons atomically:
   -- Atomic transaction (PostgreSQL):
   BEGIN;
   UPDATE coupons
   SET used_count = used_count + 1
   WHERE code = $1
   AND used_count < max_uses
   AND expiry > NOW()
   RETURNING *;
   -- 0 rows → Coupon invalid/used → ROLLBACK
   COMMIT;
   -- "UPDATE ... WHERE" with a condition is atomic!

5. Prevent mass assignment:
   // Explicitly allowed fields (allowlist):
   const allowedFields = ['name', 'email', 'bio'];
   const updateData = _.pick(req.body, allowedFields);
   // NEVER: await User.update(req.body)

6. Money/Credit Transactions:
   → Prevent double posting: Idempotency Keys
   → Idempotent key per transaction (unique!)
   → Enforce positive balances: CHECK CONSTRAINT balance >= 0
   → Audit log for all financial transactions

7. Business logic tests in CI/CD:
   → Automated tests for negative quantities, zero prices, etc.
   → Boundary tests for all business rules
   → Authorization tests: User A cannot use User B’s resources