Is it possible to uninstall application from an iPad remotely without user's permission?
The client wants an app for secure sharing company data through iPads and some server (something like Dropbox). The requirement form the client also is to wipe all application data from iPad and possibly uninstall application at all when employee is fired :-)
In my opinion neither the data wiping or remote uninstalling is possible. I am just curious if anyone can came with some solution.
I plan simply offer client to open all encrypted documents only inside an app and only when the app is connected to internet. Each time the document is about to be opened (even if the document is cached) authentication is required. When employee is fired documents can't be read.
You're right in your assumption that remote uninstalling is not possible. And data wiping isn't possible without the user's permission. (The only solution I can think of for this is to send a remote notification with instruction to delete files, but the user would have to open the application from that notification, they could just ignore it).
Authentication does sound like a viable solution. Ask the user to sign in when they open the application (and when the app returns from background) and authenticate the sign in remotely on a server. When the user leaves the company, invalidate their login. Encrypt files stored on the device for extra security.
You could do something where your app checks with a server, each time it is run, for a "kill flag". It could still have content on board but it just does not allow access until it has confirmed there is no kill flag. If there is a kill flag then it wipes all sensitive data.
Another thing to consider is that devices connected through Exchange can be remotely wiped by an administrator. If your client uses exchange and is ok with the idea of completely wiping the device this could be a procedure they could implement.
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.
Our iOS app has a kind of chat room, messaging service built into it, which is reflected on our website.
Sometimes we get a few users who come on just to stir up trouble, but lately there's been a few who we just can't shake. On the web we can restrict their IP, and recently we've been blocking them through the app via device ID.
Which worked for a while until they figured out that reinstalling the app reset it.
Is there anyway at all to identify these people, and permanently restrict their access?
You can store the device ID in the keychain, that way they have the same id even after deleting and reinstalling the app.
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.
We are developing an app for IOS.
Is there anyway I can check that the "identifierForVendor" that the device sends me in it's first connection to my server is actually valid?
If there isn't a way, how can I make sure someone is not just sending POSTS to my server and so making me create Device DB Objects that don't really exist?
The only secure way I have found is:
1- Make the App ask for a Device Token to APNs
2- Send it on it's first connection to my server.
3- Check with APNs Feedback Service
4- If token is ok, create the Device DB Object and continue from there.
Apple should let you know some Device-Vendor Id in a communication between Apple and your server every time someone downloads an app.
Thank you.
The simplest solution would be to append the "identifierForVendor" with something you can identify from your app. For example, if you append an alphanumeric string that looks like this: "A1B2C3D4E5F6G7" to be "A1B2C3D4E5F6G7-fromMyApp", then there is no way for someone to know what the custom appended string is, unless they have access to your code.
Of course there are more complex solutions, if you are genuinely concerned of people going so far as to monitor traffic from your app just to find the string.
Are you aware that registering for remote notifications prompts the user if they want to allow remote notifications for the app. If they choose no, there is no token generated.
Besides, they can sniff the token off the wire. Do you plan on tracking abuse and blocking users based on their token? Do you know that some actions cause a new token to be generated, such as resetting the device?
You can generate a unique ID (UUID) or use identifierForVendor, and store it in the user's key store and use that to track by device. It's still anonymous, and resetting the device resets this, but if you're tracking abusers, you can block them and they have to reset their device to try it again. This isn't much different from an APN token. It can still be sniffed, and they can still reset it. But at least the user doesn't have to say yes to allowing remote notifications.
If you're sending any kind of token, you should use HTTPS (SSL/TLS), not to protect the user from themselves (they can still sniff the token by doing their own man in the middle attack unless you are verifying the identify of the server), but this is to protect people from malicious users on the same network. You don't want to block some innocent user because they happened to use your app on a public network and inadvertently shared their token.
Of course, if we're talking a jail-broken device, all bets are off.
I have the following issue:
I've understood how to create a secure login between an iPhone app and a WebServer (SSL,Https).
My question is after creating the session token, how do I make sure that if a hacker intercepts it, in the subsequent POST requests I receive data from the same user?
I ask this because I would have to send the session token each time a request is made right? (to be able to identify the user).
I want to prevent multiple things:
Session hijacking where someone would sniff the users token and send data instead of him (like a highscore or something)
Data injection using data that would not be normally sent from my app like a 1.000.000.000 highscore (possible score but not easily attainable).
I have been looking at:
UDID
User Agent (if it's not from the app name of my app it's not good, the hacker would actually have to guess I do this check or download my php files somehow right?)
The app is from the AppStore. If the request comes from an app that hasn't been approved by Apple it's not ok. I'm not actually sure if you can test this or not. If this works a hacker would have to actually submit an AppStore and download it to insert faulty data into my database which I hope nobody has time for.
The MAC address. Not sure if allowed by Apple. The IP doesn't work because a valid user might change IP's.
Cookies from what I've seen can be easily traced and see what data is inside them.
Maybe I'm not asking the right question here so it could actually be how can I make sure the data I receive is from the correct user and the correct application?
The purpose of SSL around your POST requests is to prevent interception by a third-party in transit. If a hacker can get to it, it means the token was either leaked on the client (rooted device), server (insecure application logging/debugging) or they broke SSL. (unlikely)
You could perform some advanced checking by capturing device UDID (apple doesn't like this) or comparing to source IP, but it is going to be a lot of effort for questionable security improvement.
Just ensure everything sensitive is in SSL and you should be ok.