Price Manipulation Lab

Business Logic Flaws and Client-Trusted Pricing

Not every vulnerability involves a malformed payload or a carefully crafted injection string. Some of the most financially damaging attacks on record worked by doing exactly what the application expected — placing an order — while supplying a value the developers never thought to question.

This lab is about one of those attacks: price manipulation, a business logic flaw in which the server trusts a price field submitted by the client rather than looking it up from its own authoritative product catalog.

A Flaw That Lives in the Design, Not the Code

Business logic flaws are different from injection vulnerabilities. An SQL injection attack exploits a failure to sanitize input. A price manipulation attack exploits a failure to think clearly about which side of the request should own financial data. The application is not broken in a technical sense — it does exactly what the developer wrote. The code has simply made a wrong assumption: that the browser will always submit the correct price.

The Starbucks Gift Card Bug (2014)

In 2014, a security researcher discovered that the Starbucks gift card transfer API accepted negative monetary values. By submitting a transfer amount of -$50.00, an attacker could move $50 from a victim's card to their own — while the sender's card balance increased by $50 instead of decreasing. The API faithfully applied the arithmetic the client requested.

This was not an exotic vulnerability requiring specialized tooling. It required only a proxy, a modified request, and a negative sign.

Modern E-Commerce Exposure

E-commerce platforms process thousands of orders per minute. In nearly every case, the server renders a product page, the browser displays the price, and an order request carrying that price value is submitted. Many early implementations — and some production systems today — accepted that submitted price without verification. The attack surface is anywhere a numeric financial value travels from the browser to the server and is used to compute a charge.

What the Attack Looks Like

From an attacker's perspective, the workflow is straightforward:

1. Add a product to the cart and click "Place Order."
2. Use Burp Suite to intercept the outbound HTTP request before it reaches the server.
3. Locate the "price" field in the JSON request body — it shows the display price.
4. Change the value to 0.01 (or even a negative number).
5. Forward the modified request.
6. If the server is vulnerable, it processes the order at the manipulated price.

Why Developers Make This Mistake

Client-side price display creates a false sense of authority. The developer writes code to render $299.00 on the page, builds a checkout flow that captures that value, and submits it as part of the order. The price was "correct" when it left the server — surely it will arrive correct. What is missing is the recognition that anything that passes through the browser can be modified by the user.

What You Will Do in This Lab

You will use the interactive panel below to:

1. View a shopping cart containing one item: a ProSecurity VPN Annual License priced at $299.00.
2. Click "Place Order" to trigger the intercepted request view.
3. Examine the raw JSON request body, including the "price" field.
4. Modify the price to a very small value and forward the request.
5. Observe that the server accepts and processes the order at the manipulated price.

By the end of this exercise, you will have demonstrated the vulnerability hands-on and be ready to learn the one-line server-side fix that eliminates it entirely.