True Stories of the TRC

Insufficient Process Validation

There are some vulnerabilities that security scans and code review will not find; they can only be discovered by business logic testing. Insufficient process validation is a perfect example of this kind of vulnerability.

Insufficient process validation occurs when a Web application fails to prevent an attacker from circumventing the intended flow or business logic of that application.

Finding insufficient process validation requires the tester to be patient and to be willing to explore every parameter. When playing video games, if you like to explore the entire map for items before moving to the next map, then you have the patience required to find insufficient process validation vulnerabilities.

Testing acme.cxx

I was able to find insufficient process validation on − let’s call it acme.cxx − an online store. After some time on the site I found a page where I could buy a gift certificate. Unlike the other product pages, which listed a specific price for each item, the gift card purchase page allowed me to enter an amount.

It was time to select the amount for my gift card, but I noticed the site did apply some limits to the value I could enter: In this case a minimum of $10 and a maximum of $5,000 per gift card purchase. Next, before trying any fancy deception, I decided to see how this functionality worked when I purchased a gift card whose amount was within the allowed limits. So I sent a request to add a gift card for $55 to my shopping cart. Then, when I looked at my request, I found two parameters that had 55 as their value: exampleparam1=55 and exampleparam2=55.

I tested these two parameters by trying to bypass the site’s gift card limits, changing the value to 9999. Then, by using one parameter at a time, I discovered that the only parameter that seemed to affect the shopping cart − and the value of the total order – was Exampleparam2. After this initial test, I cleaned my shopping cart to avoid any confusion later on.

Having successfully bypassed a limit set by the application, I then put on my black hat and thought: Can I gain even more for myself, now that I’ve discovered this security flaw?

Given that attackers usually attempt to cheat a Web store by exceeding discount levels and/or getting items for free, I added two items to my shopping cart: One costing $1,575 and one for $21.99 to see if I could get them for free or at least get a juicy discount. With these two items now added to my shopping cart, I went to the gift card page to add one to my shopping cart, however this time I changed the value of the vulnerable parameter, exampleparam2, to -1500.

The moment of truth had arrived: What would be the result of my discovery and subsequent attack? Well, when I checked my shopping cart I saw that my experiment had indeed worked. I had successfully purchased both the pricey $1,575 item and the random $21.99 item for a mere $96.99.

BUT! Deep down I knew that I still needed to make sure the parameter was affecting the entire transaction – and not just the shopping cart. So I clicked continue checkout, which took me to the shipping method page. There, of course, I selected free shipping; clicked continue checkout again, which took me to the Review and complete your order page. Once there, I scrolled down the page and smiled, because the Order Total and the Total Amount to be charged to my “account” was only $236.73!

This means that my ploy had indeed worked; I obtained a total savings of $1,500! In fact, the only two “legitimate” full costs that I had to pay were the cheap $21.99 item and sales tax. But, hey! That’s okay, our cities and counties need the money.

  • chamba

    and what did you bought? 😛

  • http://www.jardinesoftware.com James Jardine

    Hi Diego,

    Nice post. I think that is a great find and this type of flaw is often overlooked when tests are performed. I am curious though why you feel that a code review will not find this type of vulnerability? Maybe this type of vulnerability may be found more quickly through live testing, and more easily confirmed, but I don’t see any reason why this would not be identified during a code review.