How to Secure iOS Apps?

This is the mobile era and pretty much everything these days can happen from our smart phone. Thanks to millions of apps out there which help us in accomplishing anything we want. Whether it is maintaining your schedule (calendar) to managing financial information on the go, all things can be done by mobile apps running on our smart phones. Since these apps have access to so much of confidential information, as developer when we make an app we need to follow highest security standards so that information is not accessed by someone who is not entitled for it. 

When it comes to iOS devices there are more than billion active devices that use iOS apps on daily basis.  Here I am compiling the different security practices that an iOS developer should always keep in mind while developing apps.

1. Enable ATS in mobile apps 

With launch of iOS 9 and ELCapitan Apple launch ATS (Apple Transport Security) which forces apps to only connect to secure network. This means any connection that application makes to outside world must use HTTPS protocol and TLS1.2. 

In other words, ATS forces app to only make secure connection, and not use HTTP. There is an option to explicitly mention exception if need be by making explicit entry in plist.

2. SSL Cert Pinning

This technique is very effective to deal with MITM(Man in the Middle) attacks. SSL works on the basis of "chain of trust".  When app/client connects to a server, the client checks if the received server's SSL certificate is trusted by any SSL Certificate Authority. 

This makes sure app only communicates to designated server. App/Client bundles the SSL certificate of the designated server, so that it can match the SSL cert received while connecting to server and local cert. Details of this requires an article by itself. Stay tuned, as I will be writing an article on these details in the future.

3. Storing info in KeyChain rather than NSUserDefaults

NSUserDefaults provides us a way to save small bits of information that needs to be persisted between app launches and device restarts. All the info saved as part of UserDefaults is saved as plain text in plist which is not encrypted and can be read by anyone who has access to the device. 

If we want to save information in encrypted form, we need to use KeyChain, an encrypted container to store passwords for applications and secure services. Apple use the same technology for password management in Mac OS and iOS.

4. Avoiding confidential info as part of code repository

Any secret info shouldn't be part of repo/code base, instead we should use configuration file or environment variables that are injected while building apps. A good option is Xcode Config files which maintains info pertaining to a specific target. One use case is API keys, we shouldn't put API keys as part of code base. We could use a config file that contains the API keys. This file can be hosted internally on company network and can be read while building the app and injecting as part of build process.

5. Jailbreak Detection

Application behavior and logic can be easily compromised by a hacker with little effort on a jailbroken device. As a developer, we need to make sure we make it as difficult as possible for a hacker to get to internal details of the app. We should definitely add the logic to check for jailbroken device as the first thing when we fire the app. And after informing the user, probably kill the app. Here is the link to detail article to implement it

6. Debug Logs Only

Developers use debug messages as a great way to log the behavior of the app. This is very useful while the app is under development. When the app is under development we tend to log some information to help the developers build the features. But, if it becomes accessible to a hacker it can expose confidential info and internal working of the app. In order to make sure we don't log the message on the version of the app that we submit to store we just to put a basic check to log only while app is in Debug mode by simply doing the following. 

#if DEBUG
print("log")
#endif

We can take a step further and make a logger which will take care of every log going through it. Stay tuned, I will write a detail article separately to cover this.

7. Third Party Library Usage

Third party libraries are a great way to avoid recreating a lot of things that we want to do in our mobile app. They definitely save us a lot of time, at the same time there are some things that we need to be careful while using third part apps. There is always a risk of those libraries injecting harmful code into our code base. We should always go through Github link, license and code/security review of any 3rd party app before actually integrating it.

8. File Data Protection

Whenever we are saving any file in our app, we should use of these options to save information is a secure way

• Complete Protection (NSFileProtectionComplete)
• Protected Unless Open (NSFileProtectionCompleteUnlessOpen)
• Protected Until First User Authentication (NSFileProtectionCompleteUntilFirstUserAuthentication)
• No Protection (NSFileProtectionNone)

NSFileProtectionNone is easiest to use but most vulnerable for security risk. We should always use NSFileProtectionCompleteUnlessOpen or NSFileProtectionCompleteUntilFirstUserAuthentication as default file protection level option.

9. Screen Recording & Capturing

A lot of sensitive information can be exposed from app by screen recording or screen shots. This security check plays a very crucial role in banking applications where secured transaction details can be compromised if screenshot or screen recording is performed. We can listen/observe for notifications such as userDidScreenShotNotification to act appropriately on these events. Here is the link to a detailed implementation of it

Conclusion

As a developer we should always try to make it as hard as possible for data/info to be compromised from our app. We can certainly do this by following standard practices for app security. I usually follow the list I mentioned above, and I'm very curious to hear what security best practices you follow in your own apps. Please let me know your thoughts and stay tuned for future detailed articles on some of these security practices.