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

71–80 of 157 posts

Re: Reverse-engineering the Starbucks ordering API

#71

Post by pilif »

I wonder why they went such great lengths to prevent unauthorized clients (which also is a thing that’s fundamentally impossible. All you can do is making it harder for attackers). What would be so bad about third party apps ordering coffee?

Generally, it’s a good idea to be protective, but between cert pinning and that encrypted device fingerprint and the time based signature, this adds a lot of points of possible failure to an app you want to be as available as possible to as many people as possible.

What information this API has access to is so precious to warrant all of this?

Re: Reverse-engineering the Starbucks ordering API

#72

Post by cwsx »

coworkerblues wrote: post #64

I want to write a similar write-up for a company which basically does everything over HTTP with their own half-baked hardcoded AES key in app for sending credit card info. and that their confirmation checkup is stupid (for SMS) and can be bypassed. The problem is that their site TOS forbids reverse engineering, and I am afraid their lawyers will go after me instead of fixing the security issues (even if I just contac…

Just formally ask the company, if they don't want you to they will tell you. Could be worth including a pitch of sorts ('Hey, Ive noticed a few problems using your site...') but MAKE SURE you don't incriminate yourself. Do NOT show evidence of you 'reverse engineering' anything.

Do not do anything without gaining permission, as there's a very good chance you're going to run into their legal team.

Re: Reverse-engineering the Starbucks ordering API

#73

Post by evan_ »

pilif wrote: post #71

I wonder why they went such great lengths to prevent unauthorized clients (which also is a thing that’s fundamentally impossible. All you can do is making it harder for attackers). What would be so bad about third party apps ordering coffee? Generally, it’s a good idea to be protective, but between cert pinning and that encrypted device fingerprint and the time based signature, this adds a lot of points of possible f…

I'm thinking they probably don't want unauthorized clients just to lower the support threshold. Some percentage of people will hold them responsible for broken third-party clients.

Re: Reverse-engineering the Starbucks ordering API

#74

Post by peterburkimsher »

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…

You certainly know how to bring home the bacon.

Re: Reverse-engineering the Starbucks ordering API

#75

Post by spike021 »

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 tell it's only to be used for commercial purposes/paid for by companies.

But, I can easily find the API token being used on site A, dig through the private/deprecated docs for the API of site B, and use any of their endpoints and data for pretty much whatever I want.

At least, this was the case roughly 4-6 months ago and I haven't looked into it since; perhaps they've changed it since then.

But I wonder how this works. Wouldn't it be a misuse of their API and something they wouldn't want allowed? Usually sports statistics APIs are fairly expensive, and the fact that some random person like me can get access easily for free seems unfair to site B, especially when they don't want normal people using their API anymore.

Re: Reverse-engineering the Starbucks ordering API

#76

Post by hueving »

ghayes wrote: post #36
saghm wrote: post #35

Earlier quoted context omitted.

> That said, instead of installing an entire framework like Xposed that hooks the process to bypass certificate pinning, you can usually just decompile the APK I remember reading something years back about Java decompiling, and I believe it said that all Java code is decompileable except for inner classes and nested try-catch. Assuming my memory and the source are correct (which might not be the case), why hasn't it…

I mean, Java compiles down to a byte-code, which can be decompiled. If that were a limitation of decompilers at a time, it's likely not now. There's no way to "hide" instructions.

You can hide them in the sense that it's very difficult to find the 100 instructions and correct state machine out of the millions of instructions and possible states.

Re: Reverse-engineering the Starbucks ordering API

#77

Post by omegote »

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…

Papa bless.

Re: Reverse-engineering the Starbucks ordering API

#78

Post by BigJono »

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

Re: Reverse-engineering the Starbucks ordering API

#79

Post by thiagocsf »

BigJono wrote: post #78
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'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.

Re: Reverse-engineering the Starbucks ordering API

#80

Post by rkunnamp »

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 part as 'Paid'

The thing is, one could add as many pizzas to the cart in a different tab, while the original tab proceeds to payment. The end result is, you get to pay only for pizzas that were initially in the cart, but could get any number of pizzas. For literally Rs100 one could order thousands of rupees worth pizza.

I discovered it accidentally and did report to them. Neither did they acknowledge nor did they send me a free pizza :(

They later fixed this, by not allowing to load the cart in a different tab. But there is a high chance that there could be another hack even now. Since I had wowed not to eat junk food anymore, there was not much incentive for me to spend any more time on it.

Post reply on HN