How does it sound that you ordered something and almost got it for free? Wouldn't that make you happy? Well, that's exactly how I felt. But let me assure you, it wasn't as simple as it sounds. Allow me to provide a detailed explanation.

Firstly, let me reintroduce myself. I'm Sumeet Mahadik, a security engineer, and I hope you're doing well. I want to express my gratitude for the response I received on my first blog. If you haven't had the chance to check it out yet, you can find it on Medium titled "SQL Injection Attack on the Email ID Field."

Today, I'm excited to share my second blog with you. Judging by the title, you might already have an idea of what this topic is about. As mentioned earlier, I will walk you through the process of how I accomplished this.

While testing an e-commerce website, I decided to evaluate the functionality of placing an order. Initially, I selected a product called “Money envelopes” which had three available quantity options: 30 (priced at Rs. 1170), 50 (priced at Rs. 1495), and 100 (priced at Rs. 2340). For my test, I chose a quantity of 30 and intercepted the “add to cart” request using Burp Suite.

Request:

POST /express_product_info.php?sb=2b4k8d5bs9sbdg45bsafjl HTTP/2 
Host: target.com
prdqty=30&valid_qty=1&product_total=1170

In the below request, I modified the product_total parameter from 1170 to 10.

Manipulated Request:

POST /express_product_info.php?sb=2b4k8d5bs9sbdg45bsafjl HTTP/2 
Host: target.com
prdqty=30&valid_qty=1&product_total=10

After forwarding the request and switching to the browser to check the response, I noticed that the price remained unchanged at Rs. 1170. Based on this observation, I assumed that the price was determined solely based on the quantity of the product. So, I decided to manipulate the product quantity to see if I could order a different quantity. I selected a quantity of 30 again and intercepted the ‘add to cart’ request using Burp Suite. I then changed the product quantity parameter from 30 to 200.

Manipulated Request:

POST /express_product_info.php?sb=2b4k8d5bs9sbdg45bsafjl HTTP/2 
Host: target.com
prdqty=200&valid_qty=1&product_total=1170

I forwarding the request and checking the browser, I observed that the application accepted my manipulated product quantity. However, the price was marked as N/A (Not Available) because the option for a quantity of 200 was not available in the selection. But during the checkout process, the product was displayed with a subtotal of Rs. 00.00. Additionally, an extra charge of Rs. 177 was applied for shipping and taxes. So, the total of the order now is Rs. 177.

However, considering that the original price of these 200 money envelopes should be more than Rs. 4,000.

Example:

( Product price: Rs. 4,000 (Approximately)

Shipping and taxes: Rs. 177

Subtotal: Rs. 4,000 + Rs. 177 = Rs. 4,177 )

Therefore, the actual total for the order should be Rs. 4,177, rather than the one I got i.e. Rs. 177.

Now another challenge arose when I found that the pay button was disabled, preventing me from paying for the order. This occurred because the order quantity was manipulated. After contemplating for a few minutes, I right-clicked on the pay button and inspected it. Upon examining the code, I noticed that it had the following attribute:

class="btn btn-success ld-ext-left text-uppercase disabled"

So, I decided to replace the word ‘disabled’ with ‘enabled’, and as a result, the pay button became active. I clicked on the pay button, which took me to the payment method. Now, since this was just for testing purposes, I did not proceed further with the order placement.

And that’s how I was able to order a product worth approximately Rs. 4,177 for just Rs. 177.

Thank you for taking the time to read and engage with my blog. I sincerely hope that this blog has provided you with valuable information and opportunities for learning.

HAPPY HACKING!!