Hacking Bigbasket Ethically For Free Groceries

Who doesn’t love free groceries? In this write-up, I will be discussing a cart tampering vulnerability that I discovered in the popular online grocery platform, BigBasket. This vulnerability, if exploited, could have allowed an attacker to manipulate the contents and prices of a user’s shopping cart, potentially leading to financial loss to the company. I was able to identify this issue and report it to the BigBasket team, who promptly addressed the issue and rewarded me for my efforts through their bug bounty program. In this post, I will share the details of the vulnerability and how I was able to discover it.

The Vulnerability

Cart tampering is a very interesting vulnerability which can take various different forms, it can easily be overlooked by most researchers and can be one of the easiest vulnerabilities to find with a very high impact to the organization.

Cart tampering may include things like changing the list price of an item, changing its quantity, or anything that may lead to unexpected results or in most cases reduction in the actual cost of the item.

My Findings

The platform features a variety of grocery options from vegetables to fruits and from staples to bedding. The most common functionality on the platform is the ability to add and remove items from your cart and a way to manipulate the quantities of the items already in your cart.

When trying to increase an item quantity there would be an API call as such:

https://www.bigbasket.com/xredactedx/c-incr-i/

The body of the request looked like this:

POST {
  "prod_id":9999999999,
  "qty":1,
  "_bb_client_type":"web" //ignore
}

The most important key here is the “qty” which dictates the amount of the same items to be added to the cart. Changing this to a negative value like -2 will yield an error as:

Invalid Quantity [400 BAD REQUEST]

Let’s try changing the same quantity to a decimal value like 0.01 instead:

Invalid Quantity [400 BAD REQUEST]

We still got the same error meaning there is a check in place for such kind of input, but when we refresh our cart this happens:

Two very interesting things happened here:

1. Even though we got a 400 bad request error, this time the cart was still updated to reflect the 0.01 quantity we had entered
2. The sub-total was updated as well, it used a very simple calculation here and hence the cost was now Rs.0.93

item_price x item_quantity = sub_total

Changing the value to an even smaller decimal value like 0.0001 will result In an insignificant monetary value which will be ignored and will instead be treated as free:

On clicking the big red checkout button, there was yet another API call to temporarily reserve my cart items, and to my surprise, this was converting the decimal quantities to the nearest whole number without affecting the slashed prices! We could now easily move to the payment page and place the order successfully:

Timeline

18th August 2022 — Bug reported

19th August 2022 — First contact

22nd August 2022 — Bug confirmed and patched

29th August 2022 — Bounty released + HOF

Hall Of Fame : https://tech.bigbasket.com/security-at-bigbasket-5eaaa6fa7c89