Reverse-engineering the Starbucks ordering API • Hacker News Board

Re: Reverse-engineering the Starbucks ordering API

#101

Post by Sleeep » Thu, Jul 13, 2017, 10:37 AM UTC

iakh wrote: post #58

dsacco wrote: post #10

Solid writeup. From someone who does/did a lot of this professionally: 1. Android typically is easier for this kind of work (you don't even need a rooted/jailbroken device, and it's all Java/smali), 2. 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 and nop out all the function calls in the smali related to c…

I do this occasionally, and recently found our local real estate app that typically hides sales prices in the form of a range actually returns the actual value through their mobile API. For #2, you don't even need to recompile it, by the time you decompile the APK, you can usually just read the endpoints and parameters/data and reimplement in your language of choice.

Why would they hide sale prices like that? since it's public information.

Re: Reverse-engineering the Starbucks ordering API

#102

Post by mansilladev » Thu, Jul 13, 2017, 10:49 AM UTC

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…

"sig" hash's intention is to reduce risk of someone bookmarking and replaying same API call.

Re: Reverse-engineering the Starbucks ordering API

#103

Post by TomMarius » Thu, Jul 13, 2017, 10:51 AM UTC

BigJono wrote: post #81

thiagocsf wrote: post #79

Earlier quoted context omitted.

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.

The bacon is there so you pay something, a free pizza would be weird even to a minimal wage employee (not that they're dumb, but they probably don't care).

Re: Reverse-engineering the Starbucks ordering API

#104

Post by githubcomyottu » Thu, Jul 13, 2017, 11:05 AM UTC

Starbucks is nice for dessert, I wish they sold decent coffee though.

Re: Reverse-engineering the Starbucks ordering API

#105

Post by nailer » Thu, Jul 13, 2017, 11:14 AM UTC

From: https://github.com/tendigi/starbucks

> Once you've obtained your client_id, client_secret

I'd like to use this module. Question for author: what's the fastest way to get a CLIENT_ID and CLIENT_SECRET?

Re: Reverse-engineering the Starbucks ordering API

#106

Post by noway421 » Thu, Jul 13, 2017, 11:26 AM UTC

TeMPOraL wrote: post #94

BHSPitMonkey wrote: post #60

Earlier quoted context omitted.

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…

That makes me wonder, are the any commercial/consumer products that use that model?

Re: Reverse-engineering the Starbucks ordering API

#107

Post by noway421 » Thu, Jul 13, 2017, 11:29 AM UTC

userbinator wrote: post #51

1690v wrote: post #39

Earlier quoted context omitted.

It also expands the total attack surface of a system, which can lead to security problems. If you read some of the public disclosures from various bug bounty programs, neglected APIs have led to some serious vulnerabilities. "Underprotected APIs" is actually number 10 on the OWASP Top 10 for 2017.

The attack surface is the same whether the API is officially open/documented or not --- if you think that data received through a web API is somehow more trustworthy/less demanding of validation just because you haven't documented it and only release an app which uses it, you are doing it wrong . Conceptually, it's just a listening server on the public Internet, and will be subject to arbitrary data anyone willing to…

Published docs (auto generated or not) increase the risk of discovery. Security through obscurity, yeah, but it reduces chances.

Re: Reverse-engineering the Starbucks ordering API

#108

Post by ikeboy » Thu, Jul 13, 2017, 11:34 AM UTC

dsacco wrote: post #10

Solid writeup. From someone who does/did a lot of this professionally: 1. Android typically is easier for this kind of work (you don't even need a rooted/jailbroken device, and it's all Java/smali), 2. 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 and nop out all the function calls in the smali related to c…

I tried doing 2 recently, found the file with CertificatePinning in the name, found the part returning 1 and 0 based on whether the check passed and patched it to return 1 in both cases. It still didn't work and after a few hours, I gave up, grepped through the decompiled files for the website name, got an endpoint which turned out to work perfectly in a web browser and which led me to the ultimate endpoint I needed.

I could probably have gone deeper and found more functions to patch, but I don't know smali so everything was guessing and matching up to the java decompiled source (and the original source which seems to have been Moxie's?)

(>$100 billion company making the app with >1 million users.)

Re: Reverse-engineering the Starbucks ordering API

#109

Post by sbarre » Thu, Jul 13, 2017, 11:39 AM UTC

Sleeep wrote: post #101

iakh wrote: post #58

Earlier quoted context omitted.

I do this occasionally, and recently found our local real estate app that typically hides sales prices in the form of a range actually returns the actual value through their mobile API. For #2, you don't even need to recompile it, by the time you decompile the APK, you can usually just read the endpoints and parameters/data and reimplement in your language of choice.

Why would they hide sale prices like that? since it's public information.

My guess would be to trigger a phone call to a salesperson in the hopes of qualifying the lead etc..

Re: Reverse-engineering the Starbucks ordering API

#110

Post by ikeboy » Thu, Jul 13, 2017, 11:40 AM UTC

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've seen instances this works on gift cards.