BUSINESS LOGIC ERROR // PRICE MANIPULATION // CHECKOUT BYPASS
WEB APPLICATION SECURITY

Exploiting Business Logic Error: Price Manipulation

CHECKOUT MANIPULATION // NEGATIVE QUANTITY // PAYMENT BYPASS

researcher
Naveen Jagadeesan
published
2023-04-12
platform
E-Commerce Web Application

This article discusses the exploitation of a business logic error that allowed users to manipulate prices and reduce the payment amount for products and services.

Target Background

The target application functioned as an e-commerce platform supporting online purchases of products and services.

The application provided checkout workflows, payment handling, and order management functionality.

Overview

The organization had previously disclosed an issue where attackers manipulated payment amounts during the checkout process.

The objective of this research was to analyze the application's updated validation mechanisms and determine whether alternative bypass techniques still existed.

Reconnaissance

Finding the Encryption Key

Inspection of application traffic revealed that both requests and responses were encrypted before transmission.

To manipulate the checkout payloads, it was necessary to identify:

JavaScript bundle analysis exposed the required cryptographic implementation details.

Using the extracted parameters, encrypted requests could be recreated and modified externally.

Initial Manipulation Attempt

The initial approach attempted direct modification of the price parameter.

However the application validated the amount against a server-generated salted hash associated with the order.

This validation prevented direct price tampering.

Actual Checkout Request

Request


POST /api/v1/checkout HTTP/2
Host: www.target.com

{
  "saltedhash": "hashcode",
  "product_id": "121212",
  "price": "10",
  "quantity": "10",
  "address": "ABC city",
  "zipcode": "123456"
}

Response


{
  "saltedhash": "hashcode",
  "product_id": "121212",
  "price": "10",
  "quantity": "10",
  "amount_to_be_paid": "100",
  "address": "ABC city",
  "zipcode": "123456"
}

The developer introduced the saltedhash parameter to mitigate previous payment manipulation attacks.

Exploring Alternative Inputs

Further analysis focused on additional checkout parameters used during server-side calculations.

One particularly interesting parameter was:


"quantity"

The parameter controlled the number of products added to the purchase order.

Bypass

Instead of modifying the product price directly, the quantity parameter was manipulated using negative integer values.

The backend failed to validate whether quantities were positive numbers.

Manipulated Request


POST /api/v1/checkout HTTP/2
Host: www.target.com

{
  "saltedhash": "hashcode",
  "product_id": "121212",
  "price": "10",
  "quantity": "-5",
  "address": "ABC city",
  "zipcode": "123456"
}

Manipulated Response


{
  "saltedhash": "hashcode",
  "product_id": "121212",
  "price": "10",
  "quantity": "-5",
  "amount_to_be_paid": "6",
  "address": "ABC city",
  "zipcode": "123456"
}

The backend calculation logic trusted the supplied quantity value and recalculated the payable amount using the negative integer.

As a result, the final payable amount became significantly lower than the legitimate order value.

The server validated price integrity but failed to validate business constraints around product quantity values.

Impact

Root Cause

Mitigation

Conclusion

Business logic vulnerabilities often survive traditional security fixes because the focus remains on individual parameters rather than complete transactional workflows.

Although the application introduced salted hash validation to protect pricing integrity, the absence of quantity validation enabled an alternate payment manipulation vector.

Thank you for reading.