• 24 April, 2020

Top iOS Security Gotchas

Here's a list of the top 10 essential security mechanisms that Apple offers to up the security posture of your iOS applications. Adopting these technologies and APIs within your products is an effective step toward 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. This is an important security setting, however, it 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 apps’ network activities, a wide variety of data-in-flight compromises are mitigated. Additionally, organizations are recommended to leverage SSL pinning for maximum transport-layer security.
Deserialization Fails
The default protocol to serialize 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. To convert a serialized class to use the NSSecureCoding mechanism, Apple has outlined steps in its documentation. Making the recommended changes allows the system to enforce safe deserialization.
Opting Out of App Transport Security
App Transport Security (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 user's data is a no-brainer, but care must be taken to ensure that it's done 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. Be sure 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 personally identifiable information (PII) within an app, it can be tempting to store it in a convenient and straightforward way, such as using an NSUserDefaults entry. However, this approach allows any other app on the device to read this potentially sensitive data. Sensitive data, especially identifiable user information, 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 Apple 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 “kSecAttrAccessibleWhenUnlocked,” the strongest protection class, when saving items in the keychain. This protection class tells the system that 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 compromised through a MitM attack. Without a security audit of the SDKs used within the app, developers are blind to the potential vulnerabilities they are introducing.Allowing Third Party Keyboards on Sensitive Input FieldsWhile installing third party keyboards are useful for user customization, they introduce a new vector for data leakage. This is because the developer of a third party keyboard may be able to extract any information typed on the keyboard. As a result, it’s in the user’s best interest to disable these keyboards when handling sensitive data, such as identifiable information or credit card numbers.
Leaking PII to Device Logs
It’s all too easy to leave debug logging, which may include 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. Since logs may be visible to anyone with physical access to the device, it’s paramount to exclude sensitive data from them.Since adopting the newest technologies often introduces unforeseen risks, defensive security is a constant endeavor. However, following these top 10 tips will increase your organization’s security posture and reduce vulnerabilities introduced by iOS risks.