January 16, 2020

Proactive iOS App Security Measures for 2020

By Phillip Tennen

Data Theorem

Ensuring the security of user data within your app is critical to building trust in your business and contributing to the online safety of your customers. As we dive into the new year, here’s a brief list of essential security mechanisms that Apple offers to up the security of your iOS applications. Adopting these technologies and APIs within your products is an effective step towards writing more secure applications, giving you a lower risk of potential data compromise and increased confidence in your security posture.

Opting out of system data protection

iOS provides the Data Protection setting, a robust way to automatically encrypt any files created by your app. However, this setting is turned off by default, and many developers never enable it. Leveraging the system’s Data Protection mechanism is an easy win for increasing the security of user data within your app.

Transmitting data over insecure connections

It’s critical to ensure that any data-in-flight is transmitted over secure connections. By using encrypted HTTPS connections for all of the app’s network activity, a wide variety of data-in-flight compromises are mitigated. Additionally, leverage SSL pinning for maximum transport-layer security.

Deserialization fails

The default protocol to serialise and deserialize data on iOS, NSCoding, is vulnerable to object substitution attacks, which could potentially allow an attacker to gain remote code execution. Apple offers a near drop-in replacement, NSSecureCoding, which is not vulnerable to this attack.

Apple also made the upgrade path from NSCoding to its secure counterpart as pain-free as possible. To convert a serialized class to use the NSSecureCoding mechanism, follow these steps:

1) Change the base-class of the serializable structure from NSCoding to NSSecureCoding.

2) Override the class-method `+ (BOOL)supportsSecureCoding` to return YES.

3) Replace any calls of `- (id)decodeObjectForKey:(NSString*)key` with `- (id)decodeObjectOfClass:(Class)c forKey:(NSString*)key`

Making these changes allows the system to enforce safe deserialization on your behalf. For more information, check out [Apple's full documentation](https://developer.apple.com/documentation/foundation/nssecurecoding?language=objc#)

Opting out of App Transport Security

App Transport Security, or ATS, is a mechanism provided by Apple to mediate all network connections made by the app and validate that data is being transmitted securely. Opting out of ATS by use of `NSAllowArbitraryLoads`, or similar exemptions, is an easy way to shoot yourself in the foot and turn off a powerful security mechanism.

Cryptography API Misuse

Encrypting your user's data is a no-brainer, but care must be taken to ensure that you're doing so in a cryptographically secure way. Some system APIs, such as CommonCrypto, are easy to misuse. This results in the illusion of security, while still allowing an attack vector for user data to be compromised. Take care to use these APIs with secure options, and never statically embed encryption keys or use an encryption key which is trivially derived.

Leaking PII to NSUserDefaults

When handling PII within an app, it can be tempting to store it in a convenient and straightforward way, such as an NSUserDefaults entry. However, this approach allows any other app on the device to read potentially sensitive data. Sensitive data, especially identifiable user info, should always be stored in a secure location, such as the device's keychain, and encrypted when necessary.

Unsafe Keychain Usage

While the keychain is the most secure store of data on the device, developers must still take care to ensure they're using it correctly. It's possible for developers to save data to the keychain in such a way that the data is always unencrypted and accessible, even when the device is locked and data would otherwise be encrypted. When saving sensitive data to the keychain, ensure that you're using the strongest possible data-protection settings to maximize security.

Wherever possible, utilize the `kSecAttrAccessibleWhenUnlocked`, the strongest protection class, when saving items in the keychain. This protection class tells the system that your data should be encrypted when the user is not actively using your application.

If your app needs to access this data while running in the background, you may need to fall back on the `kSecAttrAccessibleAfterFirstUnlock` protection class, which ensures the data is encrypted only until the user has unlocked the device after boot.

Embedding Vulnerable SDKs

When an SDK is linked into your application, you're also implicitly exposing your app to any potential vulnerabilities in the SDK. Compromised SDKs have led to a variety of mobile app attacks, such as a vulnerable AFNetworking version leading to data-compromise through a MitM attack. Without a security audit of the SDKs used within the app, developers are blind to the potential vulnerabilities their dependencies are introducing.

Allowing 3rd Party Keyboards on Sensitive Input Fields

While installing 3rd party keyboards are useful for user customisation, they introduce a new vector for data leakage. As the developer of a 3rd party keyboard may be able to extract any information typed on the keyboard, it's in the user's best interest to disable these keyboards when handling sensitive data, such as identifiable info or credit card numbers.

Leaking PII to device logs

It's all too easy to leave debug logging which includes PII in production builds. Before release, validate that any log statements which might include sensitive data are scrubbed from the code. This might be achieved by way of flags which only enable these log statements in debug builds. As logs may be visible to anyone with physical access to the device, it's paramount to exclude sensitive data from them.

While adopting the techniques laid out above is a great start towards writing secure code with confidence, defensive security is a constant endeavor. For more information on designing secure iOS apps, check out my “How to Leverage iOS 13 for App Security” webinar, or feel free to reach out on Twitter @phillipten.