EC EHE - Mobile OWASP 10

 

Source: https://www.owasp.org

According to OWASP, the following are the top 10 mobile risks:

• M1—Improper Platform Usage

This category covers the misuse of a platform feature or the failure to use platform security controls. It includes Android intents, platform permissions, and the misuse of Touch ID, Keychain, or some other security control that is part of the mobile device’s OS. There are several ways in which mobile apps can be exposed to this risk.

• M2—Insecure Data Storage

Insecure data storage vulnerability arises when development teams assume that users and malware will not have access to a mobile device’s file system and subsequently to sensitive information in the device’s data stores. “Jailbreaking” or rooting a mobile device bypasses encryption protection mechanisms. OWASP recommends analyzing platforms’ data security application programming interfaces (APIs) and calling them appropriately.

Unintended data leakage occurs when a developer unintentionally places sensitive data in a location on the mobile device that is easily accessible by other apps on the device. Such leakage is normally caused by vulnerabilities in the OS, frameworks, compiler environment, new hardware, and so on without a developer’s knowledge. It is a significant threat to the OS, platforms, and frameworks; thus, it is important to understand how they handle features such as URL caching, browser cookie objects, and HTML5 data storage.

• M3—Insecure Communication

This category covers poor handshaking, incorrect SSL versions, weak negotiation, cleartext communication of sensitive assets, and so on. Such flaws expose an individual user’s data and can lead to account theft. If the adversary intercepts an admin account, the entire site could be exposed. A poor Secure Socket Layer (SSL) setup can also facilitate phishing and man-in-the-middle (MITM) attacks.

• M4—Insecure Authentication

This category captures notions of authenticating the end user or bad session management such as

1. 1. 1. Failing to identify the user when it is require
      2. Failure to maintain the user’s identity when it is required.
      3. Weaknesses in session management.

• M5—Insufficient Cryptography

The code applies cryptography to a sensitive information asset. However, cryptography is insufficient in some ways. This category covers issues in which cryptography is attempted but not performed correctly. This vulnerability will result in the unauthorized retrieval of sensitive information from the mobile device. To exploit this weakness, an adversary must successfully convert encrypted code or sensitive data into its original unencrypted form due to weak encryption algorithms or flaws in the process of encryption.

• M6—Insecure Authorization

This category captures failures in authorization (e.g., authorization decisions on the client side and forced browsing). It is distinct from authentication issues (e.g., device enrolment and user identification).

When an app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then it is an authentication failure and not an authorization failure.

• M7—Client Code Quality

This category covers “Security Decisions via Untrusted Inputs” and is one of the less frequently used categories. It is the catch-all for code-level implementation problems in the mobile client, which are distinct from server-side coding mistakes. It captures buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that is running on the mobile device. Most exploitations that fall into this category result in foreign code execution or DoS on remote server endpoints (and not the mobile device itself).

• M8—Code Tampering

This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.

Once an application is delivered to a mobile device, its code and data resources are resident on the device. An attacker can directly modify the code, change the memory contents dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources. Thus, the attacker can directly subvert the intended use of the software for personal or monetary gain.

• M9—Reverse Engineering

This category includes the analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insights into the inner workings of the application. Thus, he/she may exploit other nascent vulnerabilities in the application and uncover information about backend servers, cryptographic constants and ciphers, and intellectual property.

• M10—Extraneous Functionality

Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example involves the disabling of two-factor authentication during testing.

Typically, an attacker seeks to understand extraneous functionality within a mobile app to discover hidden functionality in the backend systems. Attackers will typically exploit such extraneous functionality directly from their own systems without any involvement by the end users.

 

Source: https://www.owasp.org

• Identify and protect sensitive data on the mobile device

1. 1. In the design phase, classify the data storage according to the sensitivity and then apply the controls. Process, store, and use data based on its classification
   2. Apply validation of the security of API calls to the sensitive data
   3. Store the sensitive data on the server instead of the client-side device, as it supports secure network connectivity and other protection mechanisms
   4. Use file encryption API provided by the OS or other trusted source when storing data in a device.
   5. Use encryption to store sensitive data and store it in a tamper-proof area if possible
   6. Restrict access to sensitive data based on contextual information, e.g., location
   7. Always make sure to turn off the location, GPS tracking, or other sensitive information when not in use
   8. Always be aware of the public shared storage as it is easily vulnerable to data leakage
   9. Apply the principle of minimal disclosure and identify the type of data needed in the design phase
   10. Use non-persistent identifiers wherever possible, which are not shared with other apps
   11. Applications should use remote wipe and kill switch APIs for removing sensitive information from the device in the event of theft or loss

• Handle password credentials securely on the device

1. 1. Use longer term authorization tokens instead of passwords as per the OAuth model and encrypt tokens in transit using SSL/TLS
   2. Leverage the encryption and key-store mechanisms provided by the mobile OS to securely store passwords and authorization tokens
   3. Ensure that capabilities such as secure element are used to store keys, credentials, and other sensitive data
   4. Allow access to mobile users for changing the passwords on the device
   5. Make sure to use measures that allow repeated patterns to curb smudge attacks
   6. Make sure that no password or key is visible in the cache or logs
   7. Do not store any passwords or secrets in the mobile application binaries, as they can be easily downloaded and reverse engineered

• Ensure sensitive data are protected in transit

1. 1. Enforce the use of an end-to-end secure channel such as SSL/TLS when sending sensitive information over the network
   2. Use complex and well-known encryption algorithms such as AES with appropriate key lengths for enhanced security
   3. Ensure the use of certificates signed by trusted CA providers and do not disable or ignore SSL chain validation
   4. A secure connection should be established only after verifying the identity of the remote end point for reducing the risk of MITM attacks
   5. Sending sensitive data using SMS or MMS from or to the mobile end points should be avoided

• Implement user authentication, authorization, and session management correctly

1. 1. The authentication mechanism strength must depend on the sensitivity of the data being processed by the application and its access to valuable resources
   2. Ensure that session management is handled properly after the initial authentication using appropriate secure protocols
   3. Use unpredictable session identifiers with high entropy and repeated application of SHA1 for combining random variables
   4. Use contexts such as IP location for adding security to authentication
   5. Ensure the use of additional authentication factors for mobile applications that give access to sensitive data using voice, fingerprint, or other behavioral inputs
   6. Use authentication that depends on the end-user identity rather than the device identity

• Keep the backend APIs (services) and the platform (server) secure

1. 1. Perform detailed code checking for sensitive data that is transferred unintentionally between the mobile device, web-server backend, and other external interfaces
   2. All the backend services for the mobile apps should be tested for vulnerabilities periodically using any static code analyzer tools and fuzzing tools
   3. Ensure that the backend platform is running with a hardened configuration with the latest security patches applied to the OS and web server
   4. Adequate logs are reserved at the backend for detecting and responding to incidents and for performing forensics
   5. Use rate limiting and throttling on a per-user/IP basis for reducing the risk of DDoS attacks
   6. Ensure testing for DoS vulnerabilities that make the server flooded with resource-intensive application calls
   7. Perform use case testing and abuse case testing to determine the vulnerabilities; also perform testing of the backend web services/REST

• Secure data integration with third-party services and applications

1. 1. Always scrutinize the authenticity of any third-party code or libraries used in the mobile application
   2. Regularly update the latest security patches and keep track of all the third-party APIs and framework
   3. Validate all the data received and sent before processing for non-trusted third-party applications

• Pay specific attention to the collection and storage of consent for the collection and use of the user’s data

1. 1. Create a privacy policy that covers the usage of personal data and make it available to users when making consent choices such as at install time or at run time or via opt-out mechanisms
   2. Check if any application is collecting Personally Identifiable Information (PII)
   3. Review the communication mechanisms to check for any accidental leaks
   4. Always preserve the record of consent to the transfer of PII
   5. Ensure that the consent collection mechanism does not overlap or conflict and try to resolve any conflicts

•  Implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls, etc.)

1. 1. Maintain access logs to paid-for resources in a non-repudiable format and make them available for end-user monitoring
   2. Regularly check for any abnormal usage patterns in paid-for resource usage and activate re-authentication
   3. Ensure use of the white-list model by default for addressing paid-for resources
   4. Authenticate all the API calls to paid-for resources
   5. Ensure that the wallet API callbacks do not permit cleartext passwords and other sensitive information
   6. Caution users and obtain permission for any type of cost implications for app performance
   7. Implement best practices such as low latency and caching to minimize the signaling load on the base stations

• Ensure secure distribution/provisioning of mobile applications

1. 1. The applications must be designed and provisioned to allow updates for security patches
   2. The app stores should monitor the apps for vulnerable code and should be able to remove apps remotely at short notice in the case of an incident
   3. Provide a feedback channel for the users to report security problems with the apps

• Carefully check any runtime interpretation of code for errors

1. 1. Minimize runtime interpretation and the capabilities offered to runtime interpreters and run interpreters with minimum privileges
   2. Outline comprehensive escape syntax as appropriate
   3. Use fuzz test interpreters and sandbox interpreters