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.

Sounds more like a logical business flaw, but nice finding none the less In some way it could be referred to as a Denial of Service flaw, as you are denying other legitimate users the service the buy the products, but generally this is more like a logical business flaw as I mentioned in the beginning :-)

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.

This is a clear Denial of Service bug. It is denying service to legitimate users. It might even be more dangerous to a website, as the shopping cart failing might go unnoticed a bit longer than if the whole site was down.

this post can not be published, reproduced, etc. on third-party websites without explicit written permission.

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.

I'm not entirely convinced I would consider it a Denial of Service because legitimate use of the function has the same impact on the customer as does abuse of the function. Most reserve and collect services in general will still allow the user to purchase the goods. The impact on the customer would be the delay in being able to collect the goods. The impact for the retailer is if they are ordering or transferring goods to the store based on the fraudulent demands before the uncollected goods are returned to stock.

Ultimately unless the item is removed from the database until it is collected, the reserve and collect system won't work. The control is that if it's not collected it's returned to stock after a predetermined period.

I would lean on the side of considering it a logic flaw with regard to the quantity limit though. However, for this to work it would really need to be based on the type/value of the product e.g. you wouldn't expect someone to purchase 10 Televisions at the same time but someone may purchase 10 packs of napkins at the same time.

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.

that is a functional application bug only occurring in a special setup and not at all a 'Denial of Service' as our industry knows it.

Is the server still answering HTTP requests ? YESdid the application stopped responding ? NOcan users still use the application by for example browsing the products and reading information from the siteYESis the application misbehaving because of this setup/bugYES

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.

m0wgli wrote: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.

The application is misbehaving because:

1. there is no limit on how much you can order in 1 order, so you can 'block' the whole warehouse2. the time limit until the reservation is freed again is 25hrs, that is way too much, there must be given a message to the user: Warning, if you do not close your order now your reservation out of the warehouse will be void.

Software applications must mirror the non virtual reality and that is : 1. nobody will ever order and reserve the whole warehouse2. nobody will ever reserve huge quantities for 25 hours without actually placing an order

You remark :

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.

puts you in the 'mediocre' programming corner by saying 'hey, don't blame me, that's not on my programming list, that programming is functioning exactly as you asked...

don't blame me you're not getting that promotion, there's only yourself to blame here if you think like that. In fact, if I would have staff talking to me like that while we would be in this situation, I would look as fast as possible to replace them and I would be happy to fire you, with a smile.

"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.

sternone I agree with your comments on this one. I understand many stores offer a reserve and collect feature but the implmentation is done in the wrong manner. They assume no one will want try and add all the stock to the site.

I think they should let the end user know that any reserve and collect is not taken from the database. If they dont make payment the item could be sold to another customer.

Jamie.R wrote:sternone I agree with your comments on this one. I understand many stores offer a reserve and collect feature but the implmentation is done in the wrong manner. They assume no one will want try and add all the stock to the site.

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.

I think they should let the end user know that any reserve and collect is not taken from the database. If they dont make payment the item could be sold to another customer.

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.