You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
@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 yourselfclient_secret='***',
redirect_uri='http://im-fluss.appspot.com/...')
try:
fromconfig_localimport*exceptImportError:
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.
I assume the following should be added to the README:
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.
The text was updated successfully, but these errors were encountered: