Hi all,

I was testing a web app the other day and found a pretty cool DOS bug that I wanted to share as it should work on most sites that use this method.

The site was online site that you could buy item from they took two methods of payment credit card and reserve pay later within 24 hours.

The Bug:
I noticed that if you reserve an item it would take it out of their database so no one else could buy the item. The problems were once it took it out of the database no one else could buy it, and two there was no limit on what you could buy. So in theory you could purchase everything in the store and it would stop anyone else from buying anything for up to 24 hours or until they noticed the issue.

As said any site that use like a reserve and collect could have this issue.

How is DOS related to this issue

Yah that makes sense MaXe and the reasons you stated it could be a DOS is exactly the reason why I said it was as it stopping legitimate user from making purchases. I can also see why it would be a logical flaw too.

well I think the way it worked was it took stock out of the database for 24 hours then if payment had not been made it would re active the stock but if this happen at peak time like xmas they could easy lose a days worth of profit.

There was no limit on what item could be ordered. I could add every single item to my basket and purchase it as reserve and collect this would stop anyone from buying from the site for 25 hours or until they noticed.

Could you elaborate on why you think it's a functional application bug? In the context of reserve and collect functionality, how is the application misbehaving? The application is performing as intended, it is removing stock from the database for collection and returning it once it has failed to be collected.

Thanks for the response. I wasn't sure of the exact definition of a functional bug so I looked it up:

http://help.utest.com/testers/participation/submit-reports/classifying-bugs

"Functional: Bugs that produce an unexpected/illogical application behavior where the end result differs from the expected result.
Examples: search returns the wrong results, clicking on a link takes you to page X instead of the intended page Y, etc. "

I couldn't entirely see how this related to the functionality of the reserve and collect function based on the examples given so I thought I'd ask for your clarification. However, having read it again I can see why your defining it as a functional bug.

In a previous post in this thread I had already considered the quantity an issue, but had referred to it as a logic flaw.

Firstly, just to be clear I accept that the implementation of reserve and collect in your example is flawed. It's the quantity than can be reserved and the time an item is in a reserved state that are the key issues.

I also appreciate I may be getting bogged down in semantics, but, I'm interested in how this would be correctly reported to the client and the mitigation/remediation advice that would be offered.


With regards to reserve and collect functionality, I still can't see how how a reserve and collect system can work without making an item temporarily unavailable to other customers for some period of time.

If payment is required to stop the item being made available to other customers it's no longer a reserve and collect system, it's a buy and collect in store system. How would people wishing to pay with cash/cheque use the system?

If payment is not required to be made online as part of the reserve and collect process and the item is not made unavailable to other customers for some period of time, you could end up with a situation where 2 customers both reserve the same item with only 1 in stock. The last customer to arrive at the store will leave disappointed.