Secure Mobile Development Guide

Restricting debuggers

Trace Checking

Optimizations

Stripping binaries

Consider a better programming paradigm, where privileges are enforced by the server when the session is not trusted, or by preventing certain data from being decrypted or otherwise available until the application can determine that the session is trusted using challenge/response, OTP, or other forms of authentication

it is recommended to declare all sanity check functions static inline.

more sophisticated approaches founded in secure coding principles may be worth further investigation.

Security auditing must thoroughly test third-party libraries and functionality as well

Upgrading to a new version of a third-party library (or OS version) should be treated as version of your app

On iOS, statically compile third-party libraries to avoid LD_PRELOAD attacks

Use checksums, digital signatures and other validation mechanisms to help detect file tampering.

Android Sample

Nullify any variables that hold keys after use

Avoid using immutable objects for sensitive keys or passwords such as in Android java.lang.String and use char array instead.

Operate under the assumption that any data written to a device can be recovered

Wherever possible, avoid storing sensitive data on the device

Use secure POST to send user data, with XSRF token protection.

Encrypting data using a non-zero initialization vector and temporary session keys can also help prevent a replay attack.

query string data can be encrypted using a temporary session key negotiated between hosts using secure algorithms, such as Diffie-Hellman

Add an additional layer of verified, third-party encryption (e.g., SQLCipher) to the data as device encryption is not sufficient

Android

The Set-Cookie headers should use the “Secure” and “HTTPOnly” settings.

use certificate pinning to protect against MITM attacks

If certificate pinning cannot be implemented for any app functionality that handles highly sensitive data, implement proper certificate validation

Android

iOS

Serve all traffic, even non-sensitive traffic,over TLS

Validate that SSL/TLS is active

Android recently added android:usesCleartextTraffic

iOS 9 and above require that you manually add exceptions for plaintext traffic.

avoid using any device-provided identifier to identify the device, especially if it’s integral to an implementation of device authentication.

recommend the creation of an app-unique "device factor" at the time of registration, installation, or first execution.

Apple recommends using the advertisingIdentifier - a unique identifier shared across all apps in the system.

avoid storing GPS data

Unless required, do not log or store GPS information.

Cameras often geo-tags images. If this is a concern, make sure to strip the EXIF data from the image

Do not activate GPS in applications that will run at or near secure locations, whose coordinates or wireless network topology should not be reported back to vendors.

Any time the app is not used for more than 5 minutes, terminate the active session, redirect the user to the log-in screen, ensure that no app data is visible, and require the user to re-enter log-in credentials to access the app

After timeout, also discard and clear all memory associated with user data including any master keys use to decrypt that data

Also, make sure the session timeout occurs on both the client side and the server side

When sensitive data or transactions are involved, implement two-factor authentication

may not be feasible every time a user logs in but can be used at intervals or when accessing selected functions

Consider step-up authentication methods to provide normal access to non-transactional areas but require a second layer of authentication for sensitive functions

Compile settings into the code when possible

Don’t store any critical settings in dictionaries or other files unless encrypted first

Ideally, encrypt all configuration files using a master key encrypted with a passphrase that is supplied by the user, or with a key provided remotely when a user logs into a system

displaying partial numbers

store the partially hidden numbers

instead of account numbers, tokens be assigned to each account and provided to the client

Use SSL/TLS either with standard trust validation, or, for increased security, implement certificate pinning

For highly sensitive values, implement additional encryption in transit

all input from the client should be must be treated as untrusted.

Services must thoroughly filter and validate input from the app and user.

Android

iOS

Prevent HTTP caching

avoid caching of URL history and page data for any Web process such as registration.

Ensure released apps are built without warnings and are thoroughly tested to avoid crashes.

Consider disabling NSAssert for iOS

avoid sending crash logs over the network in plaintext

Use secure development tools like clang-analyzer, coverity, ASAN and other linting utilities in order to identify all possible operations that can make the app crash

If the app is obfuscated and stripped, the developer will need keep an address-to-symbol database in order to recover meaningful backtraces in crashlogs

store a masked username instead of the actual username, and replace the username value in authentication with a hash value

REMOVE METHOD CALLS TO THE LOG CLASS IN RELEASE BUILDS

SET THE “ANDROID:DEBUGGABLE” FLAG TO “FALSE” IN PRODUCTION BUILDS

On iOS disabling the NSLog statements on will remove potentially sensitive information which can be intercepted and as an added benefit may slightly increase the performance of the app.

Disable the auto-correct feature for any sensitive information, not just for password fields.

Add an enterprise policy to clear the keyboard dictionary at regular intervals.

Where appropriate, disable copy/paste for areas handling sensitive data

Use X-FRAME-OPTIONS HEADER

Header add X-FRAME-OPTIONS "DENY"

Basic frame busting javascript

if( self != top ) {
  top.location = self.location ;
}

Each form submission should contain a token which was loaded with the form or at the beginning of a user session. Check this token on the server when receiving POST requests to ensure the user originated it.

When storing data in the keychain, use the most restrictive protection class (as defined by the kSecAttrAccessible attribute) that still allows your application to function properly

To prevent the exposure of keychain items via iTunes backup, use the ThisDeviceOnly protection class where practical

Finally, for highly sensitive data, consider augmenting protections offered by the keychain with application-level encryption.

To protect sensitive data, block caching of application snapshots using API configuration or code

When applicationDidEnterBackground: method returns, the snapshot of the application user interface is taken, and it’s used for transition animations and stored in the filesystem. This method should be overridden and all the sensitive information in the user interface should be removed before it returns.

Enable ARC

Implement full ASLR protection

Implement stack-smashing protection

set the cachePolicy property of the NSURLRequest to disable the caching of HTTP(S) requests and responses

Enable ATS globally by linking to the iOS 9.0 or later SDK and NOT setting the NSAllowsArbitraryLoads key to Yes or True

When using Touch ID for authentication, store the app’s secret in the Keychain with an ACL assigned to that item.

Developers can use Touch ID enrollment changes to detect and prevent a physically proximate attacker from enrolling their own fingerprint in order to gain access to protected Keychain items.

Do not create files with permissions of MODEWORLD_READABLE or MODE_WORLD_WRITABLE unless it is required as any app would be able to read or write the file even though it may be stored in the app’s private data directory

Do not use modes such as 0666, 0777, and 0664 with the chmod binary or syscalls accepting a file mode

Components accessed via Intents can be public or private. it is easy to mistakenly allow the component to be or become public.

If a component does not need to be accessed by all other apps, consider setting a permission on the component declared in the Manifest

Data received by public components cannot be trusted and must be scrutinized

Activities can ensure proper behavior by checking internal app state to verify they are ready to load

input validation is recommended when operating on data provided by an untrusted source

Avoid intent filters on Activities if they are private, instead use explicit intent

Use permissions to protect Intents in your application

Use PendingIntents as delayed callbacks to private BroadcastReceivers or broadcast activities, and explicitly specify the component name in the base Intent

When calling a service with sensitive data, validate that the correct service is being called and not a malicious service

Do not pass sensitive data between apps using broadcast intents. Instead, use explicit intents

Do not give a content provider write access unless it’s absolutely necessary

Limit access to the minimum required for an operation

Treat parameters passed to content providers as untrusted input and don’t use them directly in SQL queries without sanitation

Content providers that serve files based on a file name being passed to the provider should ensure path traversals are filtered out.

Disable JavaScript and Plugin support if they are not needed.

Disable local file access.

Disallow the loading of content from third-party hosts.

Do not transmit a check image using non-volatile storage on the device where check image artifacts may be left behind.

Quit the app entirely when the user logs out.

Any time an activity is initiated or a screen is accessed, execute a check to determine whether the user is in a logged-in state

Nullify the data on a GUI screen before leaving the screen or logging out

Sign a production app with a production certificate, not a debug certificate

Make sure the certificate includes a sufficient validity period (i.e., won’t expire during the expected lifespan of the app)

Google recommends that your certificate use at least 2048-bit encryption

Make sure the keystore containing the signing key is properly protected

Also, restrict access to the keystore to only those people that absolutely require it

disable verbose errors

return the minimum amount of information in server responses.

change any default directories.

Administration or other restricted areas should not be publicly web-accessible unless absolutely necessary, and must be resistant to brute force attacks.

Ensure SSL certificates are properly installed and configured for the highest encryption possible.

TLSv1 is more than 10 years old and was found vulnerable to a “renegotiation attack” in 2009

Avoid weak ciphers, such as:

Avoid weak protocols, such as:

Web languages (e.g. Java, .NET) offer session management, which is well-developed and security tested

Keep server software up-to-date with security patches

Ensure the size of the session cookie is sufficient

web server must be thoroughly tested and hardened against malicious attack

Production server software should be updated to the latest versions, and hardened to prevent information disclosures regarding server software and interfaces

Authentication forms should not reflect whether a username exists

All login forms and forms/pages exchanging sensitive data should implement and require HTTPS

should be blocked from external access.

Any resource that does not require public Internet access should be restricted using firewall rules and network segmentation.