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

91–100 of 157 posts

Re: Reverse-engineering the Starbucks ordering API

#91

Post by qb45 »

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…

> HTTP with their own half-baked hardcoded AES key in app for sending credit card info.

You mean, no TLS, JavaScript crypto and credit card info?

Are there no authorities to report that kind of garbage? No certification they are supposed to pass? I would research that angle first before hacking. It doesn't take any reversing to realize everyone can pwn you on a public WiFi.

Otherwise, at the very least use tor...

Re: Reverse-engineering the Starbucks ordering API

#92

Post by TeMPOraL »

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 wonder how did the people on the other end react.

One evening I ordered a pizza on-line to the office. I was too lazy to go out to the nearest grocery store (even if I knew which will be open at those hours) to buy a ketchup bottle, so in the form I added ~16x sachets of ketchup (figured it'll last me a while). I don't think it was more than 5 minutes after submitting the form that my phone rang, with the pizza guy on the other end asking if I really, really want 16 bags of ketchup?

Re: Reverse-engineering the Starbucks ordering API

#93

Post by Lazare »

dx034 wrote: post #88
Lazare wrote: post #87

Earlier quoted context omitted.

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

We actually debated offering them a job interview when they graduated. If they'd contacted us first, we might have. :) Instead we just fixed the bug, called it a day, and spent a few days reviewing the rest of the API for weak validation.

Re: Reverse-engineering the Starbucks ordering API

#94

Post by TeMPOraL »

BHSPitMonkey wrote: post #60
shortstuffsushi wrote: post #48

Earlier quoted context omitted.

Why would their API need to be anything more than what they offer to their app? Why not something like "hey, you can use our stuff, but you've only got access to the same set of APIs we use in our app, and we may change it as we please. Oh btw, here are the auto-gen'd docs, hope those are enough" That seems like it'd be both developer friendly and no more maintenance than they're already putting into it. The alternat…

You can't make breaking changes to a public API, for starters. Needing to maintain/version APIs you want to deprecate has a nonzero cost.

Of course you can.

All you have to do is to say: "this is our internal API, we're releasing endpoint documentation for curious developers, but be warned, that the API may, and will, change without any notice".

I.e. when you're releasing something in the open, you don't have to take social responsibilities if you don't want to. It's not a binary choice between "release a fully supported product" and "don't release at all".

Re: Reverse-engineering the Starbucks ordering API

#95

Post by CamperBob2 »

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.

Instructions unclear. Employee entered home and stole existing pizza from freezer.

Re: Reverse-engineering the Starbucks ordering API

#98

Post by IshKebab »

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 =(

What abuse would it be ripe for exactly? I assume the only thing they were trying to prevent is third party apps.

Re: Reverse-engineering the Starbucks ordering API

#99

Post by lambdas »

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

Being a negative, the delivery driver arrives and demands you give him a pizza.

Re: Reverse-engineering the Starbucks ordering API

#100

Post by Rjevski »

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…

Disclose everything over Tor. The kind of scum that sends credit card data over insecure homebrew crypto deserves no mercy.
Post reply on HN