InfoSec: Developing Secure Mobile App

Considerations in Mobile App Development

Security should be embedded into the development life cycle of mobile app so as to address compliance requirement and minimise security risk. The methodology on software development is evolving with new development style such as agile software development or DevOps (compounding “development” and “operations”) for continuous integration and continuous delivery to build mobile app faster using an iterative development process. It focuses on continuous communication, integration, measurement and delivery to foster the processes between app development, testing and quality assurance.

Following common stages and key security considerations are discussed to help understand relevant security concerns in mobile app development:

Requirement Stage

Design Stage

Development Stage

Testing Stage

Pre-Production Stage

Maintenance and Support Stage

Decommission Stage

Requirement Stage

Security should be considered during the requirement phase so that security is included throughout the development life cycle. Security requirements should be defined along with functional requirements and further incorporate security during other phases of software development. If the requirements are defined properly, identified risks could be addressed in early stages, which can greatly reduce extra work in later stages and remediation effort. The following areas should be considered for security requirements:

1.

Architecture, Design and Threat Modelling Requirements

Process should be in place to ensure the security concern has been explicitly addressed when planning the architecture and design of the mobile app. The functional and security roles of each component should be well defined. Topics such as threat modelling, secure development and should be covered. For example, apply relevant and sufficient security controls to safeguard the data and transactions before implementation.

2.

Data Storage and Privacy Requirements

Developer should have good understanding on the type and sensitivity of data to be handled and if any critical transaction would be involved. Sensitive data can be unintentionally exposed to other apps on the same device and data may also be leaked during transmission. Moreover, mobile devices are more easily lost or stolen compared to other types of devices. Developers should adhere to concerned laws and regulations on privacy, e.g., Personal Data (Privacy) Ordinance, in order to define a suitable data storage and privacy requirements. Privacy Impact Assessment (PIA) should be conducted if the mobile app has significant privacy implications.

3.

Cryptography Requirements

should be adopted in protecting the data stored and processed on a mobile device, or in transit between the device and servers. Ensure the mobile app uses cryptography according to industry best practices, including:

Use of proven cryptographic libraries.

Proper choice and configuration of cryptographic primitives.

Do not reuse the same cryptographic key for multiple purposes.

Generate random values using a sufficiently secure random number generator.

4.

Authentication and Session Management Requirements

User accounts and sessions should be properly authenticated and managed. This includes using randomly generated access to authenticate client requests, enforcing explicit password policy, and locking of user account when excessive login attempts are found, etc. Application should also be properly handled for change of states, such as require re-authentication when the app resumes from background.

5.

Network Communication Requirements

Developer should ensure the and integrity of information exchanged between the mobile app and remote service endpoints. Encrypted channel using the TLS protocol with appropriate settings should be used for handling all application data. When using TLS, the apps must enforce certificate validation functions and should not accept self-signed and/or un-trusted certificates. Apps should also be able to detect the use of unauthorised certificates to defend against network attack (e.g., man-in-the-middle attacks).

6.

Environmental Interaction Requirements

Platform application program interfaces (APIs) and standard components in a secure manner including communications between apps (inter-process communications) should be considered.

7.

Code Quality and Build Setting Requirements

Security coding practices should be followed in developing the app. For example, the app should be signed with trusted certificate. Mobile device default accessed entitlement should be reduced to minimum (e.g., disable camera/microphone and enable ”Do Not Track” by default).

8.

Resilience Against Reverse Engineering Requirements

If the mobile app will process or access sensitive information, protection measures should be applied to increase the app's resiliency against reverse engineering. A list of obfuscation controls such as “app isolation”, “impede dynamic analysis and tampering”, “device binding” and “emulator detection” should be considered.

Design Stage

The design stage involves designing the application architecture in accordance with the specifications aligned in the requirement stage. As application architecture is established, development team should review the system design by identifying possible compliance issues as well as security risks with reference to defined security requirements. This includes designing appropriate security controls for a given type of data and incorporating threat modelling to identify and address the risks associated with the application.

A security review should also be conducted in the design stage. It serves as a checkpoint to ensure necessary security requirements are identified and incorporated in the system design.

Development Stage

Observing secure coding standards can help improving security and reducing the number of common mistakes that may result in security breaches. Performing security assessments during the development stage also helps to identify necessary security controls, and provides timely feedback to developers regarding the security of their codes. Static Application Security Testing (SAST) should also be performed to provide an early indicator of code quality in order to deliver consistent, high-quality mobile apps.

Testing Stage

In addition to user acceptance test, system tests, stress tests, regression tests and unit tests are also useful in validating the performance and accuracy of system functionalities. Testing mobile apps could be more challenging than web apps due to the high variant of platforms and testing environment. A comprehensive testing plan should be established to design the testing approach and define the details on “what”, “when” and “how” to test.

Pre-Production Stage

A security risk assessment with security audit should be performed before the production launch and after any major changes. Each vulnerability fix may require updates to custom codes that could introduce new vulnerabilities. It is imperative to continuously assess the risk and impact to maintain secure mobile app.

Maintenance and Support Stage

New functionalities to the app or updates to existing functions may introduce changes in which security controls should be identified, documented, tested and reviewed to ensure that the system can be effectively protected from attacks or being compromised. Continuous testing is vital to maintain security assurance and protect the app where most attacks occur. The app should be regularly reviewed to ensure sufficient security is in place.

Decommission Stage

Consider decommissioning the app if it no longer meets the objectives, or when there are other apps that can better serve the purposes. Some suggestions on the decommission plan:

Develop communication strategy to inform all necessary stakeholders (e.g., app users).

Remove the app from the production environment (e.g., app store).

Security by Design and Data Privacy

Security by design and data privacy should be embedded into the whole app system design and development processes to protect the data and individual’s right to privacy. Developers should ensure that security issues are incorporated as part of the basic architectural design. Detailed designs for possible security issues should be reviewed, and mitigations for possible threats should be determined and developed. Related laws, regulations and ordinances (e.g., Personal Data (Privacy) Ordinance) should also be followed when defining the privacy requirements. Developers should pay attention to the following best practices during system design in order to protect users’ privacy.

User Notification

Inform users on what information / data that the app would collect, what purpose it serves on and how data would be handled.

Allow users to opt-out from any personal data access/use.

Offer users with option to delete all app-related data and account related information when he/she request to remove the app or delete the account.

Data Handling

Reduce the collection of personal data (especially for sensitive personal data) and permission of mobile devices features (e.g., camera and location tracking) to the absolute minimum.

Protect users’ personal data from unauthorised access, disclosure or use by using strong encryption and access control. Avoid storing personally identifiable information (PII) (e.g., ID, call logs) or other sensitive data on the user device.

Do not upload or synchronise sensitive information to external systems or devices without users’ permission.

Discard sensitive data after fulfilling the claimed data usage purpose (e.g., geo-location data).

Common Security Risks for Mobile App

Most critical mobile app security flaws are listed below, users and development team should review and define the security requirements of their applications. Moreover, application developers should be aware of these common security flaws and avoid such problems in their codes.

1.

Improper Platform Usage - The potential threat comes from the misuse of a platform feature and failure to use platform security controls, e.g., Android intents, platform permissions, misuse of biometric recognition features or other security controls of the mobile operating system. Misusing platform features may put the system under risk (e.g., cross-site scripting).

2.

Insecure Data Storage - Insecure data storage vulnerabilities occur when development teams assume that users or will not have access to a mobile device's filesystem and subsequent sensitive information on the device. This can result in data loss or extraction of the app's sensitive information via mobile malware, modified apps or forensic tools.

3.

Insecure Communication - Insecure communications from one point to another put the app data at risk of exposure, which may cause possible leakage of sensitive information over the network communication. The issue could be caused by poor handshaking, incorrect SSL versions, weak negotiation and plain text communication of sensitive assets.

4.

Insecure Authentication - Attackers might compromise passwords, keys, or to impersonate the identity of other users. The issue could be caused by the absence or improper implementation of authentication mechanisms and bad session management.

5.

Insufficient Cryptography - Attackers may steal or access poorly protected data, which could be due to not making proper use of cryptographic functions to encrypt sensitive information assets.

6.

Insecure - Attackers may bypass the authorisation mechanism and execute over-privileged functionality. The issue could be caused by the failure of a server to correctly enforce identity and permissions as defined by the mobile app, if the mobile app is only trusting the client-side authorisation but performs no server-side authorisation.

7.

Client Code Quality - Poor client codes may lead to vulnerabilities such as buffer overflows and memory leaks by passing malicious input to the mobile app. This may result in foreign code execution or denial of service on remote server.

8.

Code Tampering - Attackers may modify a mobile app for personal or monetary gain via malicious forms of the app hosted in third-party locations. The attacker may also trick user into installing the app via attacks.

9.

Reverse Engineering - Attackers may analyse the core binary to determine its source code, libraries, algorithms and other assets with the aim of exploiting vulnerabilities, harvesting sensitive data or stealing intellectual property.

10.

Extraneous Functionality - Developers may create a hidden or functions in the development stage for application debugging. If the backdoor still exists in the production version, attacker would be able to make use of it to perform malicious actions.

Points to Note for Securing Mobile App Development

Mobile apps are subject to similar security considerations and risks as other applications, thus general best practices for application development are also relevant to mobile apps development. Due to varying use cases, usage patterns and various mobile platforms, mobile apps developers should also take note of the remote web services, platform integration issues and insecurity of mobile devices. Developer should consider the following areas to build a secure mobile app:

General Considerations

General Considerations in Mobile App Development

System / Software

Authentication and Session Management

Server Controls

Code Obfuscation / Reverse Engineering

Use of Third-Party / Open Source Libraries

Data

Data Storage and Protection

On-line Payment

Network Management

Communication Security

General Considerations in Mobile App Development

Adopt security in mind approach and apply adequate protection for sensitive data being handled.

Inform users on what information the app would access or upload, and for what purpose.

Provide a personal information collection statement if personal information will be collected.

Apply “least privilege” principle to run the app with the least amount of system privileges and access rights.

Develop and implement the app according to best practices.

Design and provision an app to allow updates for security .

Refuse executing the app or alerting users in case jailbreaking or rooting is detected if the app would process critical / sensitive data.

Validate all client provided data before processing with expected whitelist of data types, data range, and data length.

Inform users and obtain consent for any large data consuming app activities.

Authentication and Session Management

Avoid solely using device-provided identifier (like UID or MAC address) to identify the device, but rather leverage identifiers specific to the app as well as the device.

Adopt appropriate authentication mechanism, consider two-factor authentication based on risk assessment of the mobile app, such as processing sensitive or financial transactions.

Avoid storing passwords, wipe/clear memory locations holding passwords directly after their hashes are calculated.

Always make use of the latest security mechanism provided by mobile platform to protect user credentials.

Perform checking at the start of each activity/screen to see if the user is in a logged in state. If not, switch to the login state.

Discard and clear all memory associated with the user data, and any master keys used to decrypt the data when an app’s session is timed out or user logout.

Data Storage and Protection

Only collect and disclose data which is required for business use of the app.

Classify data storage according to sensitivity and apply controls accordingly. Process, store and use data according to its classification.

Application data should not be stored in external storage unless appropriate security measures (e.g., strong encryption) are applied.

Use encryption with appropriate algorithm and key length when storing or caching sensitive data to non-volatile memory and keep minimum necessary data for the use of mobile app for the sake of data protection.

Perform input validation and perform checking on related areas that the app can receive data to prevent client-side code injection or screen hijack.

Discard and clear all sensitive data from memory when no longer needed.

Adopt sandboxing technology to improve security by isolating an application to prevent other applications from interacting with the protected app.

Communication Security

Transmission of any sensitive data such as personal data or credit card information should be protected with end-to-end encryption (e.g., TLS).

Detect if the connection is not HTTPS with every request when it is known that the connection should be HTTPS.

When using TLS, the apps must enforce certificate validation functions and should not accept self-signed and/or un-trusted certificates.

Enable per-app VPN to secure access internal network resources from anywhere and on any mobile devices.

Server Controls

Assess backend services for mobile app for vulnerabilities and ensure that the backend system is running with a hardened configuration with the latest security patches applied.

Ensure sufficient logs or information are retained on the backend servers to detect and respond to incidents and perform investigation.

Review the code of the app to avoid unintentional data transfer between the mobile app and backend servers.

On-line Payment

Warn users and obtain consent for any cost implications for app behaviour.

If paid-for resources are involved, security controls such as a whitelist model or re-authentication for paid-for resources should be implemented to prevent unauthorised or accidental access.

Use secure mobile payment services if online payment is required. Use application program interfaces (APIs)/templates provided by the official providers and follow closely their guidelines for implementation.

Inform user the minimum technical specifications that a mobile device must support for the payment service (e.g., TLS supports).

Adhere to the specific data security standard (e.g., PCI DSS) on developing a mobile app with on-line mobile payment.

Code Obfuscation / Reverse Engineering

Verify the app signature on start-up to ensure that the code has not been altered or corrupted.

Use obfuscation software to protect source code and hide the app details as far as possible if it is not compiled to machine code format to prevent reverse engineering.

Implement anti-debugging techniques (e.g., prevent a debugger from attaching to the process) for apps containing sensitive data.

Use of Third-Party / Open Source Libraries

Use reliable and/or official versions of software development tools (e.g., software development kits, software libraries) to avoid introducing or backdoors unknowingly.

Track third-party frameworks/ APIs used in the mobile app for security patches and perform upgrades.

Validate all data when received from and send to un-trusted third-party apps (e.g., ad network) before incorporating their use in the mobile app.

Testing for Mobile App Development

Testing mobile apps on mobile devices can be more challenging than testing web applications on personal computer due to wide varieties of mobile OS, hardware components and network environment, etc. The following areas should be considered in mobile app testing cycle.

Testing Mobile App Functionality

To make sure the mobile app functions properly on supported device, functional testing should be conducted to verify the mobile app features specification. There are also different types of mobile app testing that need to be considered:

1.

Compatibility testing: Ensure the mobile app functions properly on supported device with different mobile platform such as iOS and Androids, and with different screen sizes and versions of operating systems.

2.

Performance testing: Measure the app performance such as response speed, acceptable user load and app stability, etc.

3.

System testing: Ensure the mobile app catches and handles possible exception and recover properly from accidental termination.

Testing Code Quality

Developers use a wide variety of programming languages and frameworks in mobile app development. Common vulnerabilities such as injection flaws, memory corruption, and cross-site scripting, may manifest in apps when failed to follow secure programming practices. For example, injection attacks against a mobile app are most likely to occur through inter-process communication (IPC) interfaces, where a malicious app attacks another app running on the device. Testing should be conducted to identify possible entry points for untrusted input or to identify known, dangerous library / application program interface (API) calls.

Cryptography in Mobile Apps

Cryptography is crucial in securing the user's data in a mobile environment, where attackers may have physical access to the user's device. Proper encryption or appropriate key storage APIs should be adopted for storing sensitive information. Not to use any cryptographic algorithms or protocols that contain known weaknesses. Adopt the best practices and security configurations to ensure the cryptographic algorithms are up to date and in-line with industry standards. Outdated ciphers such as DES, or hashing function such as SHA1 must not be used. Other configuration issues such as insufficient key length, hard-coded cryptographic keys and weak key generation functions should be checked.

Mobile App Authentication

Appropriate authentication methods should be integrated and performed by both front-end client and back-end server to protect against attacks such as password dictionary attack or brute force attack. In general, username/password authentication is considered for apps that are not sensitive; two-factor authentication is generally considered for protecting sensitive app (e.g., SMS and token). Testing should be conducted to ensure the authentication procedure is consistently enforced on both front-end client and back-end server.

The following steps should be tested on authentication and authorisation:

Identify the additional authentication factors the app uses.

Locate all endpoints that provide critical functionality.

Verify that the additional factors are strictly enforced on all server-side endpoints.

Testing Network Communication

Network communication between mobile device and server usually takes place over untrusted networks. It may put the mobile app at risk of network-based attacks such as packet sniffing or man-in-middle-attacks. Encrypted connection (e.g., HTTPS) should be used to ensure confidentiality and integrity of the network data while handling sensitive data. Intercept the tested app's incoming and outgoing network traffic and make sure that the traffic is encrypted, such as capture the network traffic with packet analyser and display the captured traffic in a human-readable format with network protocol analyser. After all, verify that the server is configured according to best practices.