Business Logic Errors

introduction

Business logic refers to the rules, workflows, and processes that govern how an application operates to fulfill its intended business objectives. These rules dictate how data is processed, how transactions are conducted, and how user interactions are handled. A business logic vulnerability occurs when an attacker identifies a way to subvert these rules, leading the application to behave in ways that violate its intended purpose.

Searching for the NOs

At the heart of identifying business logic vulnerabilities is the process of asking ourselves: **“What are we not meant to do?”** This approach focuses on understanding the boundaries and restrictions within the application’s intended functionality. By identifying these “NOs”—actions that should not be allowed or behaviors that should be restricted—we can uncover vulnerabilities where these boundaries can be bypassed or manipulated.

The Philosophy of “Searching for the NOs”

Business logic vulnerabilities often emerge when an attacker discovers a way to perform actions that the application was explicitly designed to prevent. These actions typically fall outside the normal, expected use of the application and can include:

• **Bypassing Validation**: Skipping steps or altering the sequence of operations to achieve an outcome that should be prohibited.
• **Exceeding Permissions**: Performing actions that should be restricted based on user roles or authorization levels.
• **Misusing Functionality**: Leveraging legitimate features in unintended ways to gain an unfair advantage or cause harm.

How to Search for the NOs

1. **Identify Critical Business Processes**:

   • Start by mapping out the key business processes within the application. Understand what the application is designed to do, who its users are, and what actions they are expected to perform.

2. **Question Assumptions**:

   • For each process, ask yourself: **“What should users not be able to do?”** Consider actions like skipping necessary steps, accessing restricted data, or performing operations out of sequence. Think like an attacker who is looking for ways to subvert the system.

3. **Explore Unintended Behaviors**:

   • Examine how the application handles edge cases, error conditions, and unexpected inputs. Test scenarios where a user might deviate from the normal workflow or provide inputs that the system doesn’t anticipate.

4. **Challenge the System’s Integrity**:

   • Assess whether the application enforces business rules consistently across all use cases. Look for discrepancies where the logic might fail, allowing an attacker to bypass controls or exploit weak spots in the workflow.

Examples of “NOs” in Business Logic

1. **NO Bypassing Authentication**:

   • The application should prevent any attempt to access restricted areas without proper authentication. However, if an attacker can manipulate session tokens or URL parameters to bypass this control, a vulnerability exists.

2. **NO Unauthorized Discounts**:

   • In an e-commerce application, users should not be able to apply discounts that they are not entitled to. If an attacker can manipulate the order process to apply unauthorized discounts, it’s a sign of a business logic flaw.

3. **NO Skipping Approval Steps**:

   • In a multi-step workflow, such as a loan approval process, users should not be able to bypass necessary approvals. If an attacker can skip these steps, the integrity of the process is compromised.

Examples of Business Logic Vulnerabilities

• Excessive Trust in Client-Side Controls
• Failing to Handle Unconventional Input
• Making Flawed Assumptions About User Behavior
• Domain-Specific Flaws
• Providing an Encryption Oracle
• Email Address Parser Discrepancies

Excessive Trust in Client-Side Controls

**Vulnerability:**

An attacker uses Burp Suite to intercept and modify HTTP requests, bypassing client-side validation.

**Steps to Exploit:**

1. **Intercept Requests**: Capture HTTP requests that include discount codes or cart modifications.
2. **Modify Data**: Change the discount code or cart parameters to unauthorized values.
3. **Send Tampered Request**: Submit the altered request to the server.

login your username and password. in 2FA change the username to victims username then bruteforce the 2FA

Failing to Handle Unconventional Input

• change value to negative
• change value contentiously check integer overflow happens (exceeding 2,147,483,647 for a 32-bit signed integer)
• like above contentiously add characters email field to check how many characters allowed

useful for privileged email bypass

Making Flawed Assumptions About User Behavior

Domain-Specific Flaws

Providing an Encryption Oracle

Email Address Parser Discrepancies

reference

• https://0xn1ghtm4r3.notion.site/Business-Logic-Vulnerabilities-0641135819794f2e9888dd513db3e250
• https://portswigger.net/web-security/logic-flaws/examples

Read Also

• Business Logic Errors