Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cafebazaar iap is not efficient enough #15

Open
sijad opened this issue Jul 14, 2018 · 2 comments
Open

Cafebazaar iap is not efficient enough #15

sijad opened this issue Jul 14, 2018 · 2 comments

Comments

@sijad
Copy link

sijad commented Jul 14, 2018

I was looking for a way to contact with bazaar developers, so that's why I've open this issue, this is things that seems good in your iap REST API implementation:

  1. OAuth2 is overkill, a simple API key would be enough
    • OAuth2 is not very suitable in this case, created Client would have one user maximum (the Developer who created the Client)
    • protecting of refresh token is same as it takes for a simple API key, if refresh token get exposed Developer have to remove Client, create a new one, change credentials in server, re-login via OAuth2
    • for automation, OAuth2 is not good, you're just making it hard for developers
  2. REST api should return orderId
    • in your document you've stated that we should check if orderId is unique and didn't proceeded already, but this is DANGEROUS.
    • attacker can change orderId to a random value and send it back to the server, as server does not know it has been changed, will considers it as new order and will proceed it as valid order
    • if you return orderId via REST API we can use that instead, otherwise orderId is redundant and we have to save and check purchaseToken instead which is up to 1000 characters.
  3. checking RSA hash
    • this can fix above issue, but it didn't documented
    • only a link to this repo which is 5years old!
@sijad
Copy link
Author

sijad commented Jul 14, 2018

OAuth2 usually is suitable if there's a third party involved.
it's first time I've seen OAuth2 used in this situation (work with my own data), I can name cloudflare, digitalocean, and lot's of more big companies that let you have a just simple API code (as an alternative password) to interact with their API.

I'm complaining because we have to check if access_code expired or not every time!

@sijad
Copy link
Author

sijad commented Jul 14, 2018

after looking deeper at your IAP, sorry buy your whole RSA implementation seems silly, there's two situation here:

  1. APP is offline and purchases will verify in app itself
    RSA, obfuscate, etc can't do much, nothing will prevent an attacker to bypass those restrictions, sure it will make it hard but not impossible, by suggesting doing such things you're spreading bad practices.

  2. APP is online and purchases will verify in developer server
    RSA does not help much here either, it did't documented well and the only source code available is written in JAVA (this repo). purchases should be verified by a trustworthy party (YOU) via a secure way (HTTPS for instance).

a big company like yours should make better decisions, you're making developers to adopt bad practices, and it's hurting community, which is unforgivable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant