The development of any mobile application requires serious attention to privacy and security. This is especially important for applications that work with personal information. This article reviews the main criteria for ensuring the security of iOS applications.

Data storage

iOS always has excellent attention to information security. Nevertheless, some serious vulnerabilities have been identified, which have resulted in leaks of user data. If it contains personal information, it should be stored strictly in Keychain. If you need to use the database such as Core Data and Realm, make sure it is encrypted.

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

The mobile app should not keep logs using the hard drive. It should not include personal details. Also, it is advised to disable the caching of web-requests, as they also get saved to the drive.

Server Connection

With the launch of iOS 9, Apple implemented strict requirements for network connection and developed the App Transport Security (ATS) rules. It requires that all Internet requests be made via HTTPS and get encrypted using TLS 1.2.

App developers can set the parameters for all connections, as well as for requests to specific domains. These are located in the app's Info.plist file. The main parameter here is the NSAllowsArbitraryLoads, which may disable all ATS regulations (it is turned off by default). If it is enabled, you will have to provide the justifications for it upon the app's review in the App Store.

This is a necessary step as it cannot be guaranteed that the browser pages that are opened in the application comply with all Apple security requirements. It is critical to enable the NSAllowsArbitraryLoads to allow webpages to be open in iOS 9.

SSL Pinning

Even with the use of HTTPS connections, there is a risk of third parties viewing data exchanged with the server. For example, a Cyber attacker can monitor traffic on public wi-fi networks using Man-in-the-middle attacks. This can be prevented by using the SLL pinning technique

This can be used in different ways; by storing the certificate file, or its hash, or public key within the application. If you are using the Alamofire library for network connections, you can use the ServerTrustPolicyManager that supports all of these pinning options.

Authorization

Authorization in many applications occurs via a 4-6-character pin-code that is chosen by the user upon registration. Of course, you cannot store this code unencrypted on the device or server.

The verification of the pin-code must occur on the server side using PBKDF2. This algorithm requires salt: a collection of random symbols generated upon registration and its subsequent use in further authorizations.

This salt must be stored in the application database. However, some applications have the option of authorization with the combination use of Touch ID and Face ID when the user gains access to his account. In this case, both the pin-code and the hash must be stored in the Keychain. The number of attempts to enter the pin-code is limited, and this parameter is implemented by the server.

After the authorization on the server, a token is created for all subsequent Internet requests. It should be valid for a limited time. If the token expires, the user should enter a new pin-code to receive a new token. The token may expire on the server (in 10-15 minutes), as well as in the application (in about 2 minutes) if there are no requests made or activity conducted, respectively.

The token should not be kept in between sessions, which means that a new one must be generated by entering the pin-code each time the application is launched.

Touch ID & Face ID

Biometric authentication makes it much easier to sign in to mobile applications. According to Apple, the chances of a user's fingerprint matching another person is 1 to 50,000, while the probability of matching facial scans is 1 to 1,000,000.

All the transactions related to this take place in a Secure Enclave that is completely isolated from the operating system. As a result, it becomes almost impossible to gain access to a user's biometric data. However, there are some important issues which need to be reviewed.

For example, if a Cyber attacker discovers the phone pin-code, he or she can then add his fingerprint to the list. This way they can authorize the app to be launched without knowing the pin-code. To solve this problem, a hash called the "evaluatedPolicyDomainState" lists the current set of fingerprints.

This hash can be stored on the drive upon the first successful authorization and can compare/verify its value during future authorizations. If they are different, the Touch ID gets disabled, and the user is forced to re-enter the pin-code. The same rule applies to the Face ID as well.

Jailbreaking

If the user decides to jailbreak his or her iOS device, the majority of the iOS safety functionalities will automatically be disabled. Thus, Jailbreaking has become less popular, primarily because it has become harder to deploy on the latest iOS versions.

If jailbreaking is detected, strict limits can be imposed, such as blocking certain parts of the application or preventing the user from gaining access to it. The best way to perform a Jailbreak check is to use the Cydia package.

It is worth mentioning that by using it, the applications cannot be 100% protected, but it can complicate the Jailbreaking process.

Anti-Fraud

Even if a Cyber attacker gains full access to the user's phone or account, there are established methods of blocking him or her from being able to perform malicious operations within the application.

For example, the device information (such as the ID, model, version of iOS) can be sent to the server. In case the user loses access to his phone, the device can be blacklisted at this level.

Also, the server may receive the user's geolocation data, provided that the user has given such permission. If an out of the norm geographic location is detected, the service will be suspended until the user confirms that he or she is indeed the one that is using the application.

Also, all of the settings and operational changes must be confirmed via the usage of SMS verification codes. The number of attempts to use it should also be limited.

Data Entry

It is also imperative to ensure the security of data entry within the application. For example, in most text fields, it is highly recommended that the autocomplete feature (UITextField autoCorrectionType) should be disabled.

If this is not done, the input data will be indexed by the operating system, and thus, it will be utilized by the autocomplete feature in other applications. Also, all text fields needed for password entry must be masked and should not support the copy/pasting option.

To avoid the threats by posed by key-loggers, the pin-code entry must take place via the number pad on the screen and not on the system keyboard.

Other iOS Features

When the user minimizes a particular application, the operating system takes a screenshot, which is then displayed in the list of minimized applications. This screenshot is kept in the smart phone's folder, and thus poses a serious security vulnerability.

These risks can be mitigated by making the screen content look blurry, even put a "shutter" on top of the minimized application. The goal is to ensure that no personal data is visible in the screenshot.

For important actions and operations, it is not recommended to use WebView, since various JavaScript vulnerabilities have been discovered on it. It is also highly recommended to use SSL-pinning with a set of trusted certificates on third-party sites.

Code Security

It is impossible to protect an application from being reverse-engineered completely, but there are definitely ways to complicate this process. For example, a debugger can be used upon the application's initial launch. If it is detected, the application should immediately shut down.

If Objective-C was used as the source code for the app, then code obfuscation will further complicate the reverse-engineering process. There is no need to do it with Swift since the compiler performs the obfuscation itself when in Release-mode.

Conclusion

In many cases, an application is just a part of some bigger project in which there is a server connected to it. To ensure full protection of the service, all components must comply with information security requirements. Nevertheless, it is impossible to guarantee 100% security.

The possibility of a Cyber-attack always exists. All the points reviewed in this article above merely reduce the risk of it from happening. Therefore, the following principles should be adhered to in the development process:

1. the application code should be considered public;
2. The best place for secure data storage is on the server;
3. Any protective measures taken should be made complex to frustrate the Cyber attacker and thus, make him or her give up.