It occurs to me that to provide multi user support for an app using iCloud, a public access container could be used. From a security point of view, only my app has access to the container anyway.
I'm just wondering if this is a viable idea? Or are there implications I haven't considered / mentioned?
I was thinking I could cover the cost via a subscription. I guess I could also monitor usage and have heavy / light user subscription tiers.
This is a valid strategy. I've implemented something like this in an app by allowing the user to log in to "nearby classrooms" (accounts) that were guarded by a passcode. This requires your app client being the authority on whether or not the user can see a piece of data, though, where this is normally handled by the server.
Related
I've frequently heard that the main issue we need Firebase security rules is because an application contains all the configurations needed to connect to the database and thus users could do something like db.delete('*'), read/write whatever they want, etc. etc.
I can see how this is possible on a web app, as you could check out the requests being sent over the network and thus get the endpoint needed to connect to the database, but, on an iOS app, how would this be possible?
For instance, say I created some chat app with Firebase and released it to the App Store. When a user downloads it, how would he/she gain access to my database through an API other than the buttons etc I provide with them with? Is there something equivalent to the "Network" section in google chrome that shows all outgoing requests, and, from, this they could send a malicious request to my database? Would this require installing 3rd party software onto their device to see all outgoing/incoming requests and they could get the required endpoint/database connection info from there?
Thanks.
When a user downloads it, how would he/she gain access to my database through an API other than the buttons etc I provide with them with?
It's not hard to reverse engineer the contents of the IPA file to get both the configuration you provided, and also see what the code is that queries the database. The IPA file can be obtained pretty easily - there is not much protecting that, given the user effectively has full control over the device (e.g. jailbreak). Given that information, it's possible to simply invoke the public Firestore REST API to not just duplicate all the operations in the app, and but invent operations of their own.
Scenario:
I "control" two different apps, App A and App B, both which the user has installed
App A is running
App A needs to obtain a string that was set by App B when App B last ran.
After obtaining the string, App A will still be running
User should not receive any feedback this communication is happening. E.g. no "switching animations" between A or B, no pop-ups, etc.
Constraints:
Apps are released under different vendors
Apps are already in the app store; updated versions will have this communication ability.
It is acceptable for the data stored in App B to be accessible to other apps on the device.
It is not acceptable for the data stored in App B to be visible to general third parties (e.g. if an external server is used, there needs to be some sort of secured scheme)
The data read should be able to occur immediately upon App A being opened after install. For instance, I cannot require the user of App A to enter log in credentials for an external communication service.
Must work on non-jailbroken devices.
This is seeming rather difficult to pull off in iOS7. Help is appreciated.
Tricky work around. Not recommended, but it will get the job done if you can't afford servers.
On the first app create a contact in the user's contacts book. Give it a generic name like "000 - NameOfAppB Data - Don't Delete" (I start with "000" so it goes to the bottom of the users contact book so they never see it, I also add "don't delete" so if the user does somehow find it they don't delete it hahaha) (who looks at contact books anyways). In the contact info under notes add your NSData in string format.
Then when app A is opened search for that contact, read the data, then delete the contact.
Apple does allow you to create and delete users contacts without their permission. (At least in 2011 they did, this may have changed).
This might serve your purpose
https://developer.apple.com/library/ios/documentation/Security/Reference/keychainservices/Reference/reference.html
I am not sure of its limitations though, i have seen implementations where credentials have been shared between apps.
I have an app that is uniquely branded for each customer (think restaurants, etc.) I need to have the user be able to click on a link to my server that contains a unique code, stores that temporarily on the iOS device (cookie, etc.) and then directs them to the app store to download the app. Then when it is downloaded, the app grabs that cookie or temp. data on launch and brands the app for that customer. I know this is possible on Android, but is it on iOS?
Downloading the app first and then selecting the brand (or restaurant) is not feasible in this case, as the url wil be shared with other customers of the same business and we want to create a fluid experience, where they won't be able to "see behind the scenes" and choose a different branding.
Thanks
Edit
Thank you for all the replies. We've reevaluated and are considering having the url be opened on the device and grabbing the IP address or another unique id, and saving that along with the correct brand to a database. The app will then connect to the database on launch, and if the IP's match, will brand accordingly. We're looking for a more reliable identifier than IP, however. Now that UDID is deprecated, are there any other identifiers we can use?
I think the design you propose of a webserver link creating the code that needs to be read by the iOS app later is the issue. You should have a solution that is entirely app based. Perhaps you can have the same services on the website be available as one app which then sets up the code in pasteboard. The user then launches the actual app that looks at the pasteboard and skins itself accordingly.
That being said, data can be shared between apps from the same app seed ID by using UIPasteboard in addition to a few other ways.
I use the pasteboard to share info between apps quickly and easily using this class.
You can use identifierForVendor (UDID replacement) to identify individual devices. Are you planning on harvesting those identifiers prior to the end user "registering" the device at the final location? If not you'll never be able to determine which device belongs where.
What about having the end-user logging into your server as that restaurant? It can be a somewhat generic login per restaurant like "Wendys/Wendys5?" and "McDonalds/McDonalds7!" to determine their App Store URL. As long as the password is easy and non-programmatic to guess it would be unlikely they figure out how to register as a different restaurant. You could also do a simple restaurant selection screen coupled with a password specific to each chain but this would expose the user to which other restaurants are using the app. This way you won't have to continually add IPs if they expand locations and can revoke credentials if the login is compromised.
One question, though: Do all of your clients understand that they'll have to have an AppleID tied to each device? You can only shared a single AppleID across 20 devices.
I am developing a iOS/OS X application with a very "nice to have" feature: possibility to sync with non-iCloud clouds.(through web server in example).
The app design already is completely based on iCloud so I was thinking there might be a workaround I could use instead of writing code for one more data marshaling.
Basically what I need is to make some iCloud stored data available to the public OR get user's e-mail/password used for iCloud on iOS/OS X.
The reason why I need it - I'll have to sync data with another cloud and I want to keeps the app lightweight and so move everything to the server (I think I might need OS X server).
Anyways, any suggestion are appreciated a lot!
I can understand wanting to do that, but just because you want to do it doesn't mean that you can.
Basically what I need is to make some iCloud stored data available to the public
I don't believe that there's a way to do that. iCloud isn't a generalized internet hosting service; it's a service designed to make it easy for an individual user to share his/her private information among several devices. Creating the possibility of making information public would only undermine the trust that people put in the service.
OR get user's e-mail/password used for iCloud on iOS/OS X.
That'd put your users in direct violation of the iCloud TOS, which state in part:
You further acknowledge and agree that the Service is designed and
intended for personal use on an individual basis and you should not
share your Account and/or password details with another individual.
If you want users to be able to sync their data with other hosting services and you don't want to build that functionality into your mobile app, you might consider building a MacOS X app that the user could run to sync the data.
We are building a web based system where there are money involved and we want to avoid fraud implementing a system that is able to identify the IOS device from where the requests are sent.
The reason of this security is because we offer money for execute actions from a mobile and we only want the user to obtain the money once, if we are not able to identify the device the user can execute the action several times.
This unique identifier can use any HTML, JS, server side technique, but not any native IOS call due the application is web based and it runs in a normal Safari instance.
The unique identifier is not needed to be the official UUID.
The system doesn't need to be bullet-proof just a few more difficult to cheat than a normal cookie.
The system should works in separate sessions, like if the user comes back after one week.
Heuristic based systems are welcome, also any combination of LocalStorage with Cookies, ...
The only ways you can identify a unique user/device in a web application is to use cookies and or track the user's IP address.
Of course, the IP address of a device will change as the owner moves around and cookies can be cleared/disabled or will expire after a set time.
Letting web sites access a device unique identifier such as the UDID would be a huge security risk / privacy invasion. If you were to find such a way, I would say that you found a severe security hole in iOS.
If you are only interested in triggering i.e. an email alert when an account is suspected of being stolen, you could use a heuristic based on device type (user agent string) and geo-ip-lookup to detect if the user has suddenly changed device type and continent and ask the user to confirm that this is really the case. I believe this is what e.g. Google and Facebook does.