When one starts out with iOS development, they don’t pay much attention to make the app secure because they think the OS will take care of it. But as the app scales and one submits the app for VAPT (Vulnerability Assessment and Penetration Testing), they realise how vulnerable their app really was !
The following practices/measures I have added are the ones that I have encountered and realised might be of vulnerability. You can feel free to comment yours and I will cover those in the next part.
Also, I will try and write separate articles on each of these mentioned points in near future so that you will have all the required details in a single place
Let’s begin!
Store sensitive data in keychain access
By default, iOS provides us with the following storage options:
UserDefaults
CoreData
FileManager
iCloud
Keychain
Out of the 5 options, I believe most would have worked with the first 2 or 3. We devs love saving our data in UserDefault because it’s easy but saving sensitive data such as passwords, credit card details, API keys etc in user defaults is RISKY!!!!
Whenever you want to save some sensitive information, always choose Keychain for it
If possible, don’t allow your app to be installed on a jailbroken device
Avoid installing your app on a jailbroken device. Since apps that get installed on the device that way are not validated and verified by Apple and can gain access to your app’s data and sensitive information
Use App Transport Security (ATS)
It’s a networking security feature that improves privacy by requiring that network connections made by the app are secured by the Transport Layer Security (TLS) protocol using reliable certificates
Its enabled by default for apps starting iOS 9.0
For apps with super secure data, like banking apps, check if network connection is secure
For super sensitive data related apps like banking apps, you can even check:
If the WiFi you’re connected on is secure
If the device that you are using the app on has an active network coverage
Enable SSL pinning
SSL pinning is a technique that prevents MITM(Man In The Middle) attack by allowing the application to only trust the valid or pre-defined certificate or public keys. How this works in a nutshell is defined below:
App sends a connection request to the server
Server gives a response that has public key and a certificate
App checks the certificate and sends an encrypted key to the server
Server decrypts the key and sends the encrypted data back to the app
App decrypts the encrypted data
Disable screen recording and screen capturing (screenshot)
If possible, disable screen recording and screenshooting capabilities. Some apps that implement this feature either disables this capability or notify the other user (in case of chat applications) that the capability has been used
One such app that I can think of is SnapChat. Most of the apps out there have no problem with users using this capability but in some cases, disabling this might be useful
Download API keys from server rather than storing in code
This one is a recommended approach when it comes to dealing with API keys/ Other sensitive keys as it makes the code less vulnerable. Downloading the API keys from server and saving it in Keychain, as discussed above, makes a lot more sense than hardcoding it in code
Obfuscating keys
If in case the API keys cannot be downloaded from the server and has to be kept in code, try obfuscating them. This means rather than saving it in plain string format, we convert and save them into a [UInt8] and while retrieving it, pass it through an obfuscater engine that converts is back to the string format and feeds it to the API that requires it
That’s it for Part 1 folks. A lot of you might already be aware of all these practices and will be using it in your apps but those who are not aware of these or are new to iOS development might find it helpful. I know there are a lot of other good measures as well which I might have not covered here; hence Part 1 !
Comments