High-level logic vulnerability

 This lab demonstrates a high-level business logic vulnerability, where the application fails to properly validate how quantities affect the final price during a purchase. Instead of enforcing strict rules around order calculations, the system allows the user to manipulate the quantity field in a way that produces an unintended and exploitable outcome. In this case, the vulnerability arises because the backend logic does not properly handle negative values for quantity, which should never be valid in a real-world shopping scenario.

During the lab, two items were added to the cart: one expensive item priced at 1337$, and another item priced at 95.37$. Under normal circumstances, the total cost should always be the sum of all positive quantities multiplied by their respective prices. However, the application does not properly validate the quantity input, allowing it to be set to a negative number. By manipulating the quantity of one of the items to -14, the pricing logic becomes corrupted. Instead of increasing the total cost, the negative quantity effectively reduces the overall price of the cart in an unintended way.

This happens because the backend likely calculates the total using a simple formula such as price × quantity without enforcing constraints on the quantity field. When a negative value is introduced, the multiplication produces a negative subtotal, which is then subtracted from the final order total. As a result, the expensive item becomes partially or fully “discounted” in an unintended manner. This allows the user to pay significantly less than the actual combined value of the items in the cart, effectively breaking the pricing logic of the application.

This type of vulnerability is not related to technical flaws in encryption or authentication, but rather to flawed business logic design. The system assumes that users will only enter valid values (such as positive quantities), which is a dangerous assumption in security. Attackers can manipulate any input field that is processed by the server, and if proper validation is missing, they can exploit these assumptions to gain financial advantage. In this case, the attacker was able to reduce the total cost of a 1337$ item to only 1.82$ by abusing the lack of input validation.

The root cause of this issue is the absence of strict server-side validation for business rules. Quantity values should always be validated to ensure they are positive integers greater than zero. Additionally, the system should reject or sanitize any unexpected values before performing calculations. A secure implementation would enforce constraints such as minimum quantity limits and ensure that totals are always derived from validated inputs. Ideally, the backend should treat quantity as a strictly controlled field and never allow negative or manipulated values to affect pricing logic.

This lab highlights an important lesson in application security: even if authentication and encryption are properly implemented, flawed business logic can still lead to severe financial exploitation. It shows that attackers do not always need to break into systems—they can simply abuse poorly designed assumptions. Proper input validation, strict server-side enforcement, and defensive programming are essential to prevent such vulnerabilities in real-world applications.