EH-Net

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.

Doesn't really sound like a DOS bug, more of a logic flaw. DOS implies some sort of crashed service, memory consumption or extended CPU spike.

Certainly on smaller sites if they don't have a limit on quantity that you could add, it could be an issue but it wouldn't work on a site like Amazon for example.

How is DOS related to this issue ???

Sounds more like a logical business flaw, but nice finding none the less ;D 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.

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 ?
YES
did the application stopped responding ?
NO
can users still use the application by for example browsing the products and reading information from the site
YES
is the application misbehaving because of this setup/bug
YES

= it's a bug, not a DoS

Hey, I know a bug when I see one :-)

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 warehouse
2. 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 warehouse
2. nobody will ever reserve huge quantities for 25 hours without actually placing an order

You remark :
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.

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.

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.

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.

How is Amazon doing it ?

The item was reported to the client as DOS bug. I am not sure what the recommendation was to the client, as I did not finish the report or was in the call to the client.

I think the client was made aware of it was enought for them. I mean from the feedback the client gave the bug had been in the application for well over 10 years.

I am not sure how Amazon are doing it but I would think most companies are using the same sort of method.

I'm not sure. As far as I'm aware Amazon don't offer reserve and collect as they don't have retail premises.

My experience of the reserve and collect process is based off of how major UK retailers such as Argos and PC World are doing it. The item is removed from stock until the end of the next business day without requiring payment.


Jamie, thanks for the information.

Just my 2cents.

If an outside company would report a functional bug as a DoS to me I would have serious questions who I'm dealing with.

I have so much stuff more to learn in my life, but apparently I'm not the only one ;-)

I think its hit and miss tbh I would say agree with all comments here I would say its 50/50 as a DOS and functional bug.

So we put it as a DOS and explain to the client why it happend and what we could do.

An intresting question would be if you have a phone that has a lock feature on it and your friend decides to play a game. He enters your pin wrong 3 times this then lock the phone for 1 min. He then does it again 3 more times and lock the phone for 10 min. He then keeps on doing this until the phone is locked for 60min.

Would you say that was a DOS ? as mentioned above you not really using resources up like ram, HDD or the processor. you are just locking him out of his phone and stoping him from using the phone for 1 hour.

Personally, I would consider this a clearcut DoS through abuse of the account lockout functionality.

So what the difference between locking someone phone and denying someone access to make a purchase? As I think there is no difference or a really small amount of difference that does not matter.

I believe the distinction between the two is that the DoS condition you refer to in the reserve and collect function is a consequence of the applications flawed functionality/logic. It is this flaw that is the underlying issue and is therefore the issue that should be reported. If the functionality was implemented correctly it couldn't be abused to cause the situation you describe.

The account lockout functionality isn't flawed as it is functioning as intended, i.e. reacting to incorrect logins. It is the abuse of it's intended function resulting in a DoS, that would be the issue.

Good points but would the developer not argue that the reserve and collect was implemented and is a function of the site.And in both cases the phone case and the collet and reserve case the features are being abused?

I am just trying to look at this from different points of view as I have said I think its very 50/50 on being a DOS/Logic-function flaw.

I think everyone will have a different view on what they would class it as.

The phone locking out the user is not a DoS. It's how the system was programmed.

A denial of service is just a condition when for example because of an attack the servers become unresponsive or the network is unreachable.

You guys are confusing bugs and software functionality to lock out a user as a Denial of Service.

Otherwise every condition with a bug or with a programmed function becomes a DoS, why would you call them bugs ? Just call them all DOS then or even more, call every 'programmed safety function' that takes out a user for a certain time (as intended too!!) as a DoS !!

It's almost funny...  :D

sternone I don’t think we confusing them I just trying point out that it sometimes hard to decide between the two. Even if you look this post some people said it’s a type of DOS some said no way so there is a lot of confusing around it.

Wikipedia says "In computing, a denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a machine or network resource unavailable to its intended users"

So by purchasing the entire shop when you have no intention to pay for them are you not in a way making resources unavailable to its intended users?

If you stop your friends from having access to his phone by entering the pin so many times wrong are you not denying him access to his machine?
I just trying say that it sometimes hard to identify if an issue is a DOS, Logical or any other type of flaw.

No you are not.

Wikipedia is very correct, they are talking about having the servers or networks being not responding.

If you use a bug to lock up a certain function of the program in this case ordering a product for a certain period that is not making the servers or the network unresponsive.

I'm done with this discussion, you can have it all, sure, all bugs are 'denial of service' and hey, even if we programmed it so you get locked out for a certain period well then its a 'denial of service' also.

Yeah right. there is hope in this industry for me after all, if I need to compete with you guys... Sigh... :P

I was only trying get people opinion was not stating facts or saying you’re wrong and I am right I just trying to look at it from different people’s points of view.

:)

I wouldn't entirely rely on Wikipedia for a source of information if at all. They are discussing DoS at the network layer, DoS can also occur at the application layer.

With regard to abusing the account lockout process to cause a DoS, heres a couple of links that I suggest you read:

http://projects.webappsec.org/w/page/13246921/Denial%20of%20Service

https://www.owasp.org/index.php/Denial_of_Service

http://technet.microsoft.com/en-us/library/cc737614%28v=ws.10%29.aspx

Thanks for the links