True Stories of the TRC

Root of the Issue

Let’s say you’re performing some business logic testing…specifically, you’re testing the quantity of items on an e-commerce site. When you try to add a negative amount of items to your cart, the site responds with a negative number of items. However, the cart page reflects a regular price. Darn, they’ve thought of that issue and have eliminated it.

Should you stop your testing?

The persistent hacker would definitely say, “No way!”

I came across this exact issue on a major, unnamed e-commerce site. (This vulnerability has since been remediated.)

In the above example that I discovered, the all-too-common issue that many e-commerce sites once faced was fixed, but was it fixed for good, or was the fix just “a bandage placed over an open wound?” On the site that I assessed, the wound definitely had a bandage on it, but what it really needed was stitches!

I say that because I was still able, quite easily, to add negative items to my cart, although I would still have to pay the correct amount at checkout. So I started experimenting with the site’s cart and its checkout procedures. The result? I found an interesting loophole.

Here’s what I discovered: Let’s say you added one $50 grill to your cart, and then added gift wrapping. The total price would then be $54; thus, gift wrapping costs $4. Now add a “negative” 27 towels at $2 each, making your new total $108. Then add the gift-wrapping option for the towels, and your final total price becomes zero!

To add even more fuel to the fire, the checkout process was nice enough to require no billing information if the total was “zero” dollars. The site documented that this could occur if gift cards were used. We didn’t even have to enter any personal information whatsoever to receive products!


The problem described here occurred because the site developers failed to confirm that the other functionality and/or code used in the ordering process used the corrected values. The raw input the user provided should have been scrapped/corrected immediately on the first request, before permeating any functionality, instead of just trying to manipulate the very end result if it didn’t match certain criteria.

Although I thoroughly tested all the way up to the final checkout confirmation, I did not confirm that the order was accepted, because WhiteHat provides only production-safe solutions.

The most important lesson here is that it is always essential to fix the root of every vulnerability, rather than simply applying a quick fix. Because as this example shows, the results can otherwise be disastrous.