Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse-engineering the Starbucks ordering API

blog.tendigi.com

Post reply on HN
Print view View original

81–90 of 157 posts

Re: Reverse-engineering the Starbucks ordering API

#81

Post by BigJono »

thiagocsf wrote: post #79
BigJono wrote: post #78

Earlier quoted context omitted.

I'm struggling to grok exactly how that would work. 1 pizza with bacon, -1 pizza (without bacon?) Then what, hope the employee reads -1 as 1 and doesn't cancel the order and call you to find out what you wanted? I must be missing something...

The employee will ignore the negative sign in front of the number and make you that pizza anyway. The calculation of the total is where it might give you free pizza.

Yeah that's what I figured. The wording of the post made it sound like it had something to do with the bacon though. You could just do this for any arbitrary pizza.

Re: Reverse-engineering the Starbucks ordering API

#82

Post by _e »

seanp2k2 wrote: post #9
turdnagel wrote: post #5

Is there a good guide out there on reverse engineering mobile apps for iOS & Android?

Use http://www.telerik.com/fiddler or https://www.charlesproxy.com or https://mitmproxy.org If they pin certs it can be harder but not impossible.

Xposed Framework module to disable SSL cert pinning https://github.com/Fuzion24/JustTrustMe

Re: Reverse-engineering the Starbucks ordering API

#83

Post by CodeWriter23 »

joombaga wrote: post #45

I did this with the Papa John's webapp a while back (which was waaaay simpler btw). They limited duplicate toppings to (I think) 3 of the same, but "duplicate_item" was just a numerical property on the (e.g.) "bacon" object. Turns out you could just add multiple "bacon" members to the toppings array to exceed the limit, and they didn't charge for duplicates, so I ordered a pizza with like 50 bacons. It definitely did…

I'm not a lawyer but I'm pretty sure yours would advise against confessing to theft and wire fraud in a public forum.

Re: Reverse-engineering the Starbucks ordering API

#84

Post by CodeWriter23 »

rkunnamp wrote: post #80

The dominos ordering app in India had a terrible flow a while back. Once the products are added to the cart and proceeded to checkout , the flow was as follows 1. First a payment collection flow is initiated from the browser (asking Credit Card details, pin etc) 2. The payment confirmation comes to the browser 3. The browser then places the order(the pizza information) to another api end point, marking the payment pa…

This is why we never trust input from the client.

Re: Reverse-engineering the Starbucks ordering API

#85

Post by CodeWriter23 »

vinhboy wrote: post #62
rconti wrote: post #41

Excellent writeup. I have to take issue with the "Starbucks app is great" line, though. I think I've had more problems with it (on iOS) than any other app. It's the only app that (for a period of many months if not a year) was regularly unable to find my location. Even if I opened up Maps or some other location enabled app and found my location before launching Starbucks, it would just bomb out. Overall the app seems…

Agreed. I'd also add that the UI for the app needs work. Ordering coffee for a group of people becomes a huge hassle on my phone because their search is not precise, and customizing drinks is a bit cumbersome. I spent like 20 minutes trying to order 5 drinks the other day. It was also annoying because when I left the app, all my selected items disappeared.

I'd call that an app fail, taking more time to use the app than writing a list then walking there and back with your complete order.

Re: Reverse-engineering the Starbucks ordering API

#86

Post by _pmf_ »

bpicolo wrote: post #6

Opening up an API like this is ripe for abuse, so taking care makes sense. Bad actors translate directly to lost money. A real method of securing APIs would be a godsend, but in current tech it's just not possible. This is the one place where mediocre security-by-obscurity is your only choice =(

> A real method of securing APIs would be a godsend, but in current tech it's just not possible. This is the one place where mediocre security-by-obscurity is your only choice

It's magically possible when tying it to a payment processor, though.

Re: Reverse-engineering the Starbucks ordering API

#87

Post by Lazare »

13of40 wrote: post #68
joombaga wrote: post #45

I did this with the Papa John's webapp a while back (which was waaaay simpler btw). They limited duplicate toppings to (I think) 3 of the same, but "duplicate_item" was just a numerical property on the (e.g.) "bacon" object. Turns out you could just add multiple "bacon" members to the toppings array to exceed the limit, and they didn't charge for duplicates, so I ordered a pizza with like 50 bacons. It definitely did…

Whenever you do this sort of thing, you should check whether they do negative number checking on the client side or in the API itself. You might be able to get 1 pizza with bacon and (1) pizza without, all for the price of the bacon.

I work for a company with a similar sort of online ordering API, and a while back some enterprising person discovered that:

1. Our API had a hidden "tip" feature; we hadn't exposed it in the storefront yet, mostly because the developer in charge of it had left with it halfway finished, and nobody had picked it back up yet

2. But the API itself was perfectly functional. If you manually submitted an order to the API with a tip set, it would be reflected in the total, would bill your credit card, etc.

3. Except (I'm sure you saw where this is going...) the now-departed dev hadn't added any validation yet. So if you ordered $40 worth of pizza and added a negative $39 tip...boom, nearly free pizza.

We learned a few valuable lessons for the cost of buying a college student a couple of pizzas. :)

Re: Reverse-engineering the Starbucks ordering API

#88

Post by dx034 »

Lazare wrote: post #87
13of40 wrote: post #68

Earlier quoted context omitted.

Whenever you do this sort of thing, you should check whether they do negative number checking on the client side or in the API itself. You might be able to get 1 pizza with bacon and (1) pizza without, all for the price of the bacon.

I work for a company with a similar sort of online ordering API, and a while back some enterprising person discovered that: 1. Our API had a hidden "tip" feature; we hadn't exposed it in the storefront yet, mostly because the developer in charge of it had left with it halfway finished, and nobody had picked it back up yet 2. But the API itself was perfectly functional. If you manually submitted an order to the API wi…

At least you didn't sue them for that. There are enough companies that would've done so..

Re: Reverse-engineering the Starbucks ordering API

#89

Post by qb45 »

rkunnamp wrote: post #80

The dominos ordering app in India had a terrible flow a while back. Once the products are added to the cart and proceeded to checkout , the flow was as follows 1. First a payment collection flow is initiated from the browser (asking Credit Card details, pin etc) 2. The payment confirmation comes to the browser 3. The browser then places the order(the pizza information) to another api end point, marking the payment pa…

Surely you can do just point 3 if you know how the API works. Atrocious design.

There used to be some "secure pendrive" which worked similar way: an app asks you for password, checks if it matches hash stored on the drive and optionally commands the drive to unlock itself. What could possibly go wrong? ;)

Re: Reverse-engineering the Starbucks ordering API

#90

Post by semi-extrinsic »

spike021 wrote: post #75

Maybe a bit off-topic, but APIs always make me wonder a bit when they can be reverse-engineered or.. for lack of a better word, misused. I know of one website (site A) that sells items for sports and uses an API of a sports website (site B) to provide current statistics and other information. Thing is, that sports website's API is now deprecated for public use, there's no way to request a token, and from what I can t…

I was looking at statistics for prices of sold houses in a European country a few years back, and started digging around in the javascript of a local newspaper that every month listed the local sold properties. Turned out in the API they were using from the central statistics provider, they just had "days=30" and "municipalities=[list]". They weren't even caching it, every user visiting the page was another (identical) request to the API provider. And sure enough, sending a request with "days=3650","municipalities=[{all of them}] gave me 10 years of data with every property sale in the country.
Post reply on HN