Skip to content

Module 12 — Business Logic & Race Conditions

Icon: ⚠ Warning   |   Colour: Orange

Overview

Tests for business logic flaws and race conditions that arise from insecure design rather than implementation bugs. This module covers race conditions via concurrent requests, workflow step-skipping, numeric manipulation, account enumeration, password policy validation, session management, and predictable resource location.

Maps to OWASP Top 10 A04 — Insecure Design, CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization) and CWE-840 (Business Logic Errors).

How It Works

1. Race Conditions (Double-Spend / Duplicate Creation)

Sends multiple concurrent POST requests to transaction-like endpoints (checkout, purchase, order, payment, transfer) and analyses whether the server allows duplicate processing:

  • Fires a configurable number of concurrent requests (default: 10)
  • Compares response status codes and bodies for duplicate successes
  • Detects missing idempotency controls and optimistic locking

2. Workflow Step-Skipping

Tests whether multi-step workflows can be bypassed by directly accessing final/confirmation endpoints without completing prerequisite steps:

  • Identifies /confirm, /finalize, /submit, /complete, and /step-N endpoints
  • Sends GET and POST requests directly to final steps
  • Checks for success/confirmation content in responses indicating a bypass

3. Numeric Manipulation

Sends manipulated numeric values to transaction endpoints to test server-side validation:

  • Negative quantities — e.g. quantity: -1
  • Zero prices — e.g. price: 0
  • Integer overflow — e.g. quantity: 2147483648
  • Float precision — e.g. amount: 0.001
  • Negative discounts — e.g. discount: -999
  • Tests both API endpoints (JSON) and HTML forms with numeric fields

4. Account Enumeration

Checks whether login, registration, and password reset endpoints reveal whether a user account exists through different error messages:

  • Submits fake credentials and analyses error messages
  • Detects patterns like "user not found", "email not registered", "unknown user"
  • Compares against generic messages like "invalid credentials"

5. Password Policy Validation

Tests registration endpoints with weak passwords to verify server-side enforcement:

  • Attempts registration with passwords like a, 12, abc, 1234, password
  • Checks whether weak passwords are accepted without validation errors
  • Flags missing password complexity requirements

6. Session Management

Evaluates session cookie security and fixation vulnerabilities:

  • Secure flag — Verifies session cookies set the Secure flag on HTTPS sites
  • HttpOnly flag — Checks that session cookies are not accessible to JavaScript
  • SameSite attribute — Verifies CSRF protection via SameSite cookie attribute
  • Session fixation — Tests whether session IDs are rotated after authentication attempts

7. Predictable Resource Location

Probes for common administrative, debug, and sensitive paths that should not be publicly accessible:

  • Tests paths like /admin, /debug, /config, /.env, /.git/config, /phpinfo.php
  • Analyses response content for sensitive information indicators
  • Distinguishes between genuinely sensitive resources and generic 200 responses

Configuration

When you select Business Logic & Race Conditions as a scan module, an additional configuration panel appears. Click Configure to open the settings modal.

Parameter Required Default Description
Concurrent Requests No 10 Number of concurrent requests for race condition testing (2–50)
Target Endpoints No Auto-discovered Comma-separated paths to transaction endpoints (e.g. /api/checkout, /api/orders)
Workflow Endpoints No Auto-discovered Comma-separated paths to workflow step endpoints (e.g. /api/step1, /api/confirm)

Auto-Discovery

When no endpoints are specified, the scanner uses crawl results to find transaction, workflow, authentication, and registration endpoints automatically.

Ephemeral Storage

All parameters are stored temporarily in Redis during the scan and never persisted to the database. They are automatically deleted when the scan completes.

Expected Findings

Finding Severity CWE
Duplicate successful responses from concurrent requests High CWE-362
Multiple concurrent successes without deduplication Medium CWE-362
Direct access to final workflow steps succeeds High CWE-840
Endpoint accepts negative quantities or zero prices Medium CWE-840
Revealing error messages enable account enumeration Medium CWE-840
Weak passwords accepted by registration endpoint Medium CWE-840
Session cookie missing Secure flag Medium CWE-362
Session cookie missing HttpOnly flag Medium CWE-362
Session cookie missing SameSite attribute Low CWE-362
Session fixation — ID not rotated after auth High CWE-362
Sensitive resource accessible at predictable path High/Low CWE-840

Remediation Guidance

  • Race conditions — Implement idempotency keys, database-level unique constraints, or distributed locks. Use optimistic locking or serializable transactions for financial operations.
  • Workflow bypass — Enforce server-side workflow state management. Verify that each step's prerequisites are met before allowing progression.
  • Numeric manipulation — Validate all numeric inputs server-side. Enforce minimum/maximum values, reject negative quantities and zero prices.
  • Account enumeration — Use generic error messages like "Invalid credentials" across all auth endpoints. Ensure consistent response times.
  • Password policy — Enforce minimum 8 characters with mixed case, digits, and special characters. Check against breached password lists (HIBP).
  • Session management — Set Secure, HttpOnly, and SameSite flags on session cookies. Regenerate session IDs after authentication.
  • Predictable resources — Return 403/404 for sensitive paths. Remove debug endpoints in production.