Exploiting Business Logic: Bypassing Client-Side Controls to Manipulate Pricing

Step 1: Log in to the Application

1. Open the lab in your browser.

2. Log in using the provided credentials:

   • Username: wiener

   • Password: peter

3. Navigate to the product page and locate the "Lightweight l33t leather jacket".

Step 2: Add the Jacket to Cart

1. Click "Add to Cart" for the jacket.

1. The original price of the jacket is $1337.00 (too expensive).

2. Since we don’t have enough store credit -Store credit: $100.00, we will modify the price.

Step 3: Capture and Modify the Price in Burp Suite

1. Open Burp Suite and ensure the intercept is ON.

2. In Burp Proxy > HTTP history, locate the POST /cart request.

3. Right-click on the request and select "Send to Repeater".

4. Look for the price parameter in the request body:

   

   After intercepting the request in Burp Suite, I noticed that the price parameter was sent directly in the request body. The price was set to 133700, which was the original price of the jacket. I was initially curious whether the application would accept any changes to this price, especially since the client-side validation didn't seem to enforce any restrictions.

Testing with Price 0: Initial Investigation

I began by changing the price to 0 and sent the modified request to see if any server-side validation was applied to prevent such manipulation:

After sending the request, the server responded with a 302 Found status:

This redirection meant that the application did not accept the zero price, but the price in the cart remained unchanged. When I refreshed the cart page, I could see the store credit displayed as $100.00, but the cart itself remained empty, with no item added at all.

This indicated that while the price manipulation didn’t immediately affect the application in a meaningful way, the cart was not updated with the item at the altered price. It was clear that the application was not properly validating or handling such changes on the server side at this point.

Testing with Price 1: Successful Exploit

Next, I tested the impact of changing the price to 1, which was a value greater than 0. After modifying the price parameter in the request to:

The server responded with the same 302 Found status:

This redirection again took me back to the product page. However, upon refreshing the cart page, I saw a significant change:
Store credit: $100.00
In the cart, the item was now added with a price of $0.01, as shown below:

This allowed me to exploit the business logic flaw, where the item was priced incorrectly at $0.01, instead of the intended $133700. The application failed to properly validate the price modification on the server side, and I was able to successfully add the item to the cart at an unintended price.

Note: The methodology was designed to systematically test the server's response to manipulated price values. Starting with a test of 0 for the price, I observed that the server didn’t reject it, suggesting weak validation. Then, I tested with a price of 1 to see if the application would accept this value, which it did, allowing the price to be exploited to $0.01. This incremental approach helped identify the server's over-reliance on client-side data and confirmed that it lacked proper server-side validation. By testing gradually, I could pinpoint the vulnerability without triggering any hidden checks.