E-commerce stores can lose out on a lot of revenue if price manipulation vulnerabilities get actively exploited by bad actors.
These are often security vulnerabilities caused by improper logic handling by developers which can cause the server to miscalculate prices (formula injection) at checkout, often allowing malicious shoppers to order items at a highly reduced price, or in severe cases even entirely for free!
Let’s dive into the 5 most common price manipulation vulnerabilities and how they are exploited.
The 5 most common price manipulation vulnerabilities
Imagine this…
Your laptop’s screen suddenly turns off. You don’t know why but when you try to turn your PC back on, you notice that the screen doesn’t work anymore.
So, does this means no more bug bounty for the rest of the week? Of course not!
As you’ve already had some experience repairing some basic parts in a PC before, you decide to take the matter into your own hands!
A couple of moments later, you find the same screen on example[.]com for only $200.
The site looks a bit outdated and shady, but you realize that you received a private invite from that same company a few weeks ago.
Sweet! Maybe you can get the price of the screen back if you report a couple of vulnerabilities?!
And you did do so by discovering a way to order products for free!
Actually, you found multiple ways to order free products…
Being able to change the price of any product is a perfect example of a price manipulation vulnerability. Now let’s dive into some more examples.
1) Formula injection: price tampering
The first method that allowed you to order your new screen for only $0.01 was through parameter tampering! Let’s see how that works.
You saw that the POST body contained an “amount” parameter when you clicked on the checkout page. Then you changed “200” to “0.01”.
You ordered the screen and saw that you only got charged $0.01!
2) Formula injection: quantity tampering
After you find the first vulnerability, you think to yourself that this place might be full of other similar vulnerabilities… And you’re right! Let’s check it out.
Negative quantity
So this time, you decide to set the quantity of one of your items to a negative digit. And guess what happens in the backend…
The price of the first 2 items are added up, meanwhile, the amount of the second 2 items gets deducted!
Decimal quantity
Shortly after you find the second vulnerability, you decide to give the web shop another shot. This time, you set the quantity to a decimal number.
Guess what…The backend just multiplies the quantity again without validation!
3) Integer overflow
After submitting the first 3 vulnerabilities, you decide to bypass the checks that are put in place. You try to set the quantity again to a negative number, but that doesn’t seem to work anymore.
So this time, you try integer overflow.
You’ve set the quantity to a very big number that the backend just can’t handle, because the price is stored in a 64-bit integer (often typed as int64). If it doesn’t validate this case, it will get reset to a negative number or even get set back to 0 (depending on the underlying code and libraries used)!
4) Coupons:
After reporting all the previous vulnerabilities, you think you’ve had enough for one day. But right before you leave, a thought strikes your head.
You remember the last Intigriti bug bounty tip and decide to give it a shot!
The checkout page also accepts coupons, so you go on their social media and start looking for previous coupons. Unfortunately, you only find one that gives you 10% off that is still valid… Not vulnerable.
But you decide not to give up, and go to look at the Wayback Machine. You find 5 other different coupons that should’ve expired by now… or have they?
On top of that, the web shop allows you to redeem multiple vouchers.
And at the checkout you find yourself only paying $50 instead of the whole $200.
5) Currency confusion
You want to try to bypass the payment once more as you notice a new body parameter “currency” during retesting. This time, you try everything. Right before you quit, another thought strikes your head.
What if I leave the price untouched but instead change the currency from “USD” to “INR”?
200 INR is equal to ~2.5 USD
These are the top 5 most common price manipulation vulnerabilities present in e-commerce websites! We hope you’ve learned something new from this post.
Looking to hunt on e-commerce websites? Browse through our 70+ public bug bounty programs on Intigriti and who knows, maybe you’ll earn a bounty with us today!
