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

Add a security statement to README #8

Open
mdornseif opened this issue Oct 26, 2013 · 2 comments
Open

Add a security statement to README #8

mdornseif opened this issue Oct 26, 2013 · 2 comments

Comments

@mdornseif
Copy link
Contributor

I assume the following should be added to the README:

Identifier and URL scheme should be considered secret. Anybody knowing these two and your App Identifier can create requests seeming to originate from your App,

I'm not totally sure about this. To my understanding the combination of Identifier (net.app.client.abx), URL scheme (adn123) and App Identifier (com.example.myapp) is used to identify and authenticate the app. I assume that at least for AdHoc builds an attacker can have complete control about the App Identifier (com.example.myapp) and so can impersonate an existing app.

This should not be considered an security vulnerability because given enough resources any client side secrets can be extracted although FailPlay makes it somewhat harder.
But Identifier and URL scheme should be considered secret by the developer and thus not published. See http://developers.app.net/docs/authentication/flows/app-access-token/ for documentation about this in a different context.

Than again, I might just be wrong about what is happening there.

@berg
Copy link
Member

berg commented Oct 26, 2013

It's actually trivial to extract the identifier and URL scheme from the app's IPA -- they have to be listed in the Info.plist file to work.

The theory behind how this works is that much like the theory of the OAuth 2 implicit grant flow -- we assume that the user agent is trusted. We do lean on FairPlay to ensure that, under normal circumstances, Store and Enterprise-signed builds use bundle IDs which are guaranteed to be unique by Apple. In the case of Ad Hoc signing identities, we assume that if you have permission to install 'em on a victim's device, you have the ability to otherwise compromise the device which would yield the appropriate credentials.

@mdornseif
Copy link
Contributor Author

@berg the scenario I'm concerned with is something else:

I build the "cool ADN App for iOS(TM)" which contains identifier and URL scheme bound to my account. I open source that App by putting it on GitHub. Everybody using that code now can do requests to ADN under my developer identity and without paying ADN for an developer license.

Also unfortunately to my limited understanding of Xcode it is not easy to hide identifier and URL scheme in a separate (not checked in) file. Compare that to Python, where you can do something like this:

APPNET_CONFIG = dict(
    client_id='***',  # set this in config_local.py with you must create yourself
    client_secret='***',
    redirect_uri='http://im-fluss.appspot.com/...')

try:
    from config_local import *
except ImportError:
    pass

I wouldn't know how to do something like this for Xcode/ADNlogin. Which is ok, but should be an issue everybody is made aware of.

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

2 participants