Mobile Security Best Practice
1. Data Storage
Apple’s iOS provides several mechanisms for protecting data. These built in protections are quite adequate for most consumer-grade information. For more stringent security requirements (e.g., financial data, personal information), additional protections beyond those provided by Apple can be built into an application.
Remediation
- An app should store locally only the data that is required to perform its functional tasks. This includes side channel data such as system logging.
- Plaintext data storage should always be avoided.
- Sensitive data should be stored in secure containers using Apple-provided APIs.
- Small amounts of Sensitive data, such as user authentication credentials, session tokens, etc., can be securely stored in the device’s Keychain.
- For larger or more general types of data, Apple’s File Protection mechanism can safely be used.
- More data that exceeds normal sensitivity, if it absolutely must be stored locally, consider using a third party container encryption API.
- For items stored in the keychain leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked (now the default in iOS 5/6/8/9/10/11/12).
- Avoid using NSUserDefaults to store sensitive pieces of information.
- All data/entities using NSManagedObects will be stored in an unencrypted database file.
2. Transport Layer Protection
Exposing sensitive data to eavesdropping attacks is a common issue with all networked applications.
Remediation
- Ensure SSL/TLS encryption is used when transmitting or receiving data.
- Ensure your app only accepts properly validated SSL certificates.
- Verify through dynamic testing that forged, self-signed, etc., certificates cannot be accepted by the app under any circumstances.
3. Data Injection Attacks
Exploiting URL schemes to send premium text messages or toll phone calls etc.
Remediation
- Perform positive input validation on all input data.
- Use regular expressions and other mechanisms to ensure that only allowable data may enter the application at the client end.
- Perform output encoding on untrusted data where feasible.
- Use parameterized queries, even for local SQLite/SQLcipher calls.
- When using URL schemes, take extra care in validating and accepting input, as any app on the device is able to call a URL scheme.
- When building a hybrid web/mobile app, keep the native/local capabilities of the app to a bare minimum required. That is, maintain control of all UIWebView content and pages, and prevent the user from accessing arbitrary, untrusted web content.
4. Authorization, Authentication & Session Handling
Although largely a server side control, some mobile features (e.g., unique device identifiers) and common uses can exacerbate the problems surrounding securely authenticating and authorizing users and other entities.
Remediation
- Never use a device identifier (e.g., MAC address, IMEI, IP number) to identify a user or session.
- Avoid when possible “out-of-band” authentication tokens sent to the same device as the user is using to log in (e.g., SMS to the same iPhone).
- Use only tokens that can be quickly revoked in the event of a lost/stolen device, or compromised session.
- Always use SSL/TLS when transmitting session token. Use only trustworthy sources for generating sessions.
- Implement strong server side authentication, authorization, and session management.
5. Side Channel Data Leakage
Side channels refer here to data I/O generally used for administrative or non-functional purposes, such as web caches (used to optimize browser speed), keystroke logs (used for spell checking), and similar. Apple’s iOS presents several opportunities for side channel data to inadvertently leak from an app, and that data is often available to anyone who has found or stolen a victim’s device. Most of these can be controlled programmatically in an app.
Remediation
- Design and implement all apps under the assumption that the user’s device will be lost or stolen.
- Never include sensitive data (e.g., credentials, tokens, PII) in system logs.
- Identify all potential side channel data present on a device. These sources should include, at a bare minimum: web caches, keystroke logs, screen shots, system logs, and cut-and-paste buffers.
- Control iOS’s screenshot behavior to prevent sensitive app data from being captured when an app is minimized.
- Disable keystroke logging for the most sensitive data, to prevent it from being stored in plaintext on the device.
- Disable cut-and-paste buffer for the most sensitive data, to prevent it from being leaked outside of the app.
6. Cryptography
Majority of cryptographic weaknesses in software result from poor key management, all aspects of a crypto system should be carefully designed and implemented.
Remediation
- Never “hard code” or store cryptographic keys where an attacker can trivially recover them. This includes plaintext data files, properties files, and compiled binaries.
- Use secure containers for storing crypto keys; alternately, build a secure key exchange system where the key is controlled by a secure server, and never stored locally on the mobile device.
- Use only strong crypto algorithms and implementations, including key generation tools, hashes, etc.
- Use platform crypto APIs when feasible; use trusted third party code when not.
7. Sensitive Information Disclosure
All sorts of sensitive data can leak out of iOS apps. Among other things to remember at all times, each app’s compiled binary code is available on the device, and can be reverse engineered by a determined adversary.
Remediation
- Anything that must truly remain private should not reside on the mobile device; keep private information (e.g., algorithms, proprietary information) on the server.
- If private information must be present on a mobile device, ensure it remains in process memory and is never unprotected if it is stored on the device.
- Never hard code or otherwise trivially store passwords, session tokens, etc.
