Business Vulnerabilities

Business Vulnerabilities on Store Online

Direct Price Manipulation

This vulnerability can be exploited by modifying the item's price parameter to force a zero or negative balance.

productId=1&redir=PRODUCT&quantity=1&price=(0/-1/-2)

Quantity Manipulation Technique

If the application does not allow setting a negative or zero price directly, you can exploit a logic flaw by adding an additional item and manipulating its quantity to achieve a negative total.

Steps:

1. Add the desired item to your cart.

2. Add a second item that allows quantity adjustments.

3. Intercept the request using a proxy tool (e.g., Burp Suite) and modify the quantity of the second item to a large negative value.

4. This may cause the final total to be significantly reduced or even negative, making the purchase cheaper or free

If the system does not properly validate the total price before checkout, this technique could lead to unintended discounts or unauthorized purchases.

Infinite money logic flaw

This vulnerability arises when an application does not properly enforce coupon usage limits, allowing an attacker to repeatedly apply the same discount coupon to reduce the price of an item beyond its intended limit. When combined with gift card purchases, this flaw can lead to an infinite money loop, where an attacker can generate unlimited store credit.

1. The attacker adds a $10 gift card.

2. Apply a $3 discount coupon (e.g., DISCOUNT3).

3. The system fails to prevent reapplying the same coupon, allowing them to apply it repeatedly.

4. Then buy the items and repeat the process indefinitely to continuously generate store credit and abuse the system.

Integer Overflow Vulnerability in E-Commerce Applications

This vulnerability occurs when an application fails to properly handle large numerical values in price calculations. By continuously increasing the quantity of an item, the total price surpasses the maximum integer value that the system can process. As a result, an integer overflow occurs, causing the total price to wrap around into a negative value.

Exploitation Scenario:

1. The attacker adds an item to the cart.

2. They increment the quantity of the item to an extremely high value.

3. At a certain threshold, the total cost becomes so large that it exceeds the system's integer limit, causing it to flip into a negative value.

4. If the application does not validate negative totals, the attacker can proceed to checkout with a negative balance, potentially receiving a refund or store credit instead of paying for the purchase.

Coupon Reuse Vulnerability (Discount Stacking Exploit)

Some e-commerce applications allow users to apply discount coupons to their purchases. However, if the application does not properly validate whether a coupon has already been redeemed, an attacker can repeatedly apply the same coupons to continuously reduce the final price, potentially making the item free.

Exploitation Scenario:

1. The attacker adds an item to the cart.

2. They apply a discount coupon, such as NEWCUST5 (which deducts $5).

3. Next, they apply another coupon, like SIGNUP30 (which deducts $401.10).

4. If the application does not enforce a one-time use restriction per coupon, the attacker can keep alternating between NEWCUST5 and SIGNUP30 multiple times.

5. This leads to an excessive reduction in the total price, eventually bringing it down to $0 or even negative values.

Insufficient workflow validation

This vulnerability occurs when an application fails to properly enforce the required steps in a purchase workflow, allowing attackers to bypass key processes such as checkout and payment validation. If the system only relies on URL parameters or lacks proper backend validation, an attacker can directly access the order confirmation page without completing the actual transaction.

Exploitation Scenario:

1. The attacker adds an item to their cart:

   productId=1&redir=PRODUCT&quantity=99

2. Instead of proceeding through the full checkout process, they skip the payment step and directly access:

   GET /cart/order-confirmation?order-confirmed=true

3. If the application does not verify whether the payment was successfully completed, it may mark the order as confirmed, granting the attacker access to the purchased item without payment.

Authentication bypass via flawed state machine

This vulnerability occurs when an application’s authentication process lacks proper state validation, allowing attackers to bypass role selection and gain unauthorized access to privileged accounts. If the authentication workflow does not enforce step-by-step validation, an attacker can manipulate requests to authenticate as a higher-privileged user, such as an Administrator, instead of their intended role.

Authentication process:

1. username=wiener&password=peter

2. GET /role-selector

3. POST /role-selector (role=content-author)

And attacker can intercept the response after authenticate with their credentials and skipt the "GET /role-selector" bypassing the role selector and authenticate as defualt role that most cases is Administrator.

Insecure security Controls

Email-Based Access Restrictions

Some applications enforce access restrictions based on email domains, allowing only users with a specific domain (e.g., @company-name.com) to access certain features or administrative privileges.

Exploitation Scenario:

1. If an attacker does not have an authorized email address, they can first create an account using any email.

2. Once logged in, they attempt to change their registered email to an @company-name.com address.

3. If the application does not properly verify the new email before applying the change, the attacker may gain unauthorized access to restricted areas.

Incorrect Handling of Password Change Parameters

In this scenario, the tester is logged in as the wiener user and notices a functionality that allows users to change their passwords. The goal is to escalate privileges and gain access to the administrator account.

A typical password change request looks like this:

csrf=Qv9iiIpjNSJEF3Y6hfF7eDtR10kbpJ0z
&username=wiener
&current-password=peteer
&new-password-1=password123
&new-password-2=password123

To exploit this vulnerability:

1. Log in to the application and intercept the password change request.

2. Modify the username parameter to "administrator".

3. Remove the current-password parameter from the request.

4. Submit the modified request.

If the application is misconfigured and does not properly validate ownership of the account, the request may be processed successfully, allowing the tester to reset the administrator account's password.

Incorrect Handling of Input Length on Sign-Up (Truncate)

This scenario exploits how the application processes email addresses during user registration, specifically when determining admin access.

The application grants admin privileges only to users with an @company-name.com email. However, it truncates email addresses to 255 characters, which can be abused to bypass this restriction.

By registering with an email like:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[e-mail]

The application truncates it to:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[e-mail]

Since the portion after @dontwannacry.com is cut off, the application mistakenly validates it as a legitimate @company-name.com email. This bypasses security checks and grants unauthorized access to admin features.

This vulnerability arises because the application fails to properly validate and enforce email constraints before truncation, allowing attackers to manipulate the sign-up process.