Business Logic Vulnerabilities

Business logic is the part of an application that controls how its features and processes work according to real-world rules. It decides what should happen, and in what order.

For example, in an online shopping site, business logic ensures that:

• A customer can add items to their shopping cart.
• They must provide valid payment details before completing the order.
• The system only confirms the order after the payment is successful.

Why Business Logic Vulnerabilities Matter

When business logic is implemented poorly, attackers can exploit flaws to bypass intended rules. Unlike technical vulnerabilities such as SQL Injection, these issues arise because developers fail to anticipate how users (or attackers) might misuse a feature. As a result, the application may allow fraud, financial loss, or unauthorized access.

Common Examples of Business Logic Flaws

1. Skipping Workflow Steps

If an application does not strictly enforce the correct sequence of actions, an attacker may bypass required steps and directly access later stages of the workflow.

Example:

An attacker may directly navigate to the ‘order confirmation’ page without completing the payment process, thereby obtaining goods or services without making a valid transaction.

2. Parameter Manipulation

Applications often rely on parameters passed through URLs or forms. If these parameters are not properly validated, attackers can alter them to gain unfair advantages.

Example:

In an online store, the price of an item may be sent in the request as price=100. An attacker could modify this value to price=1, effectively reducing the purchase cost and committing fraud.

3. Privilege Escalation via Workflow Abuse

If role-based access controls are not properly implemented, users may gain access to resources or functionalities beyond their intended permissions.

Example:

A regular user might change the URL from /user/profile to /admin/dashboard. Without strong access checks, this action could grant the user administrative privileges, allowing them to view or modify sensitive information.

4. Concurrency and Race Condition Exploits

Some applications fail to handle simultaneous or repeated requests correctly. Attackers can exploit this by sending multiple requests at the same time to manipulate system behavior.

Example:

An attacker may submit two requests simultaneously to redeem the same promotional coupon. Due to the race condition, the system processes both requests, giving the attacker double the discount or benefit.

Impact of Business Logic Vulnerabilities

Business logic vulnerabilities can lead to various impacts; a few of the most significant are outlined below:

1. Financial and Reputational Damage

Organizations can suffer direct financial losses when attackers exploit weak business logic. This may include fraudulent transactions, bypassed payments, or abuse of system functions. In addition, repeated exploitation can damage the organization’s reputation, leading to loss of customer trust.

Example:

A ticketing platform that fails to enforce proper payment validation might allow attackers to book tickets without completing payment. This not only results in revenue loss but also affects customer confidence if legitimate users face booking issues.

2. Unauthorized Data Access

Business logic flaws can unintentionally expose sensitive information if proper access controls are not enforced across workflows. This may result in violations of data protection regulations and compromise user privacy.

Example:

A student portal where the system only relies on the studentID parameter in the URL could be exploited. By modifying this value, one student might gain access to another student’s grades or personal details, breaching confidentiality.

3. Exploitation in Fraud and Abuse Scenarios

Attackers often take advantage of weakly designed features such as discounts, trial periods, or reward systems. These loopholes can be abused repeatedly, causing long-term financial harm and resource misuse.

Example:

In a subscription service, an attacker may repeatedly alter request parameters to reset the trial period, effectively enjoying the service for free without ever upgrading to a paid plan. This not only results in financial loss but also distorts usage metrics for the business.

Hands-on Lab on Business Logic Vulnerabilities

The following is a step-by-step hands-on exercise demonstrating a business-logic vulnerability caused by excessive reliance on client-side controls.

Step 1: Set up Burp Suite

Ensure Burp Suite is running and configured to intercept HTTP traffic from your browser. This typically involves setting your browser's proxy to 127.0.0.1:8080 and ensuring Burp's intercept is off initially for normal browsing.

Step 2: Access the Lab

• Go to the lab and click access the lab.
• Open the PortSwigger lab using this link: Excessive trust in client-side controls

Step 3: Log In:

Use the provided credentials to log in to your account:

Username: wiener
Password: peter

Step 4: Attempt to Purchase the Jacket:

• Browse to the product page for the "Lightweight l33t leather jacket".

• Add it to your cart.

• Proceed to checkout and attempt to place the order.

• The order will be rejected due to insufficient store credit. Note this for reference.

Step 5: Inspect the Order Process in Burp:

• In Burp Suite, go to the "Proxy" tab > "HTTP history".
• Filter or scroll to find the requests related to adding the item to the cart and the checkout process.

• Identify the POST /cart request that occurs when adding an item to the cart. This request includes parameters like the product ID, quantity, and crucially, a price parameter (e.g., price=133700 or similar, representing $1337.00).

Step 6: Send Request to Repeater:

• Right-click the POST /cart request in HTTP history and select "Send to Repeater".
• Switch to the Repeater tab in Burp.

Step 7: Modify the Price

• In Repeater, locate the price parameter in the request body (it might look like productId=1&redir=PRODUCT&quantity=1&price=133700).

• Change the price value to an arbitrary low integer, such as 1 (representing $0.01), ensuring it's less than your available store credit (typically $100 or similar in these labs).
• Send the modified request.
• Check the response to ensure it's successful (e.g., 302 redirect or confirmation).

Step 8: Verify the Change:

• Refresh your cart page in ths updated to your modified value.
• Confirm that the jacket's price has updated to your modified value.

Step 9: Complete the Purchase:

• With the updated low price in your cart, proceed to checkout.
• Place the order.
• The order should now succeed since the price is within your credit limit.
• The lab will mark itself as solved upon successful purchase (you'll see a confirmation message).