OWASP Top 10 Mobile Risks

This is a summary of the OWASP Top 10 Mobile Risks Project for 2017.

M1 - Improper Platform Usage

Threat Agents

  • Misuse of a platform feature or failure to use platform security controls (Include Android intents, platform permissions, misuse of TouchID, the Keychain etc).

Weakness

  • The organization must expose a web service or API call that is consumed by the mobile app.

  • The exposed service or API call is implemented using insecure coding techniques that produce an OWASP Web Top Ten or Cloud Top Ten within the server.

Vulnerabilities

  • Violation of published guidelines

  • Violation of convention or common practice

  • Unintentional Misuse

Prevention Techniques

M2 - Insecure Data Storage

Threat Agents

  • An adversary that has attained a lost/stolen mobile device

  • Malware or another repackaged app acting on the adversary’s behalf that executes on the mobile device.

Weakness

  • Development teams assume that users or malware will not have access to a mobile device’s filesystem and subsequent sensitive information in data-stores on the device

  • Usage of poor encryption libraries

  • Rooting or jailbreaking a mobile device circumvents any encryption protections

Vulnerabilities

  • Data stored insecurely includes, but is not limited to, the following:

    • SQL databases

    • Log files

    • XML data stores ou manifest files

    • Binary data stores

    • Cookie stores

    • SD card

    • Cloud synced

  • Unintended data leakage includes, but is not limited to, vulnerabilities from:

    • The OS

    • Frameworks

    • Compiler environment

    • New hardware

Prevention Techniques

  • Understand the information assets the app processes and how the APIs handle those assets. E.g.

    • URL caching (both request and response)

    • Keyboard press caching

    • Copy/Paste buffer caching

    • Application backgrounding

    • Intermediate data

    • Logging

    • HTML5 data storage

    • Browser cookie objects

    • Analytics data sent to 3rd parties

M3 - Insecure Communication

Threat Agents

  • An adversary that shares your local network (compromised or monitored Wi-Fi)

  • Carrier or network devices (routers, cell towers, proxy’s, etc)

  • Malware on your mobile device

Weakness

  • Do not protect network traffic

  • Use SSL/TLS during authentication but not elsewhere

  • The use of transport security does not mean the app has implemented it correctly

Vulnerabilities

  • Lack of certificate inspection

    • the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server

  • Weak handshake negotiation

    • The client successfully negotiates with the server to use a weak cipher suite that results in weak encryption that can be easily decrypted by the adversary.

  • Privacy information leakage

    • The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL.

Prevention Techniques

  • General Best Practices

    • Assume that the network layer is not secure and is susceptible to eavesdropping.

    • Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive data to a backend API or web service.

    • Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.

    • Use strong, industry standard cipher suites with appropriate key lengths.

    • Use certificates signed by a trusted CA provider.

    • Never allow self-signed certificates, and consider certificate pinning for security conscious applications.

    • Always require SSL chain verification.

    • Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.

    • Alert users through the UI if the mobile app detects an invalid certificate.

    • Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).

    • If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrypted data will provide a secondary defense against confidentiality violation.

  • iOS Specific Best Practices

    • Ensure that certificates are valid and fail closed.

    • When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.

    • After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.

    • Consider using certificate pinning by doing the following: export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.

  • Android Specific Best Practices

    • Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.

    • If using a class which extends SSLSocketFactory, make sure checkServerTrusted method is properly implemented so that server certificate is correctly checked.

M4 - Insecure Authentication

Threat Agents

  • Through automated attacks that use available or custom-built tools

Weakness

  • Poor or missing authentication schemes

  • Authentication requirements for mobile apps can be quite different from traditional web authentication schemes due to availability requirements.

  • Mobile apps may have uptime requirements that require offline authentication

Vulnerabilities

  • The mobile app is able to anonymously execute a backend API service request without providing an access token

  • The mobile app stores passwords or shared secrets locally on the device

  • The mobile app uses a weak password policy to simplify entering a password

  • The mobile app uses a feature like TouchID

Prevention Techniques

  • Authentication requirements of mobile applications should match that of the web application component

  • Authenticating a user locally can lead to client-side bypass vulnerabilities.

  • Where possible, ensure that all authentication requests are performed server-side.

  • If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials.

  • Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device

  • Ideally, mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user

  • Do not use any spoof-able values for authenticating a user (like device identifiers or geo-location)

  • Persistent authentication within mobile applications should be implemented as opt-in and not be enabled by default

  • If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords

  • Developers should assume all client-side authorization and authentication controls can be bypassed by malicious users. Authorization and authentication controls must be re-enforced on the server-side whenever possible

  • Due to offline usage requirements, mobile apps may be required to perform local authentication or authorization checks within the mobile app’s code. If this is the case, developers should instrument local integrity checks within their code to detect any unauthorized code changes.

M5 - Insufficient Cryptography

Threat Agents

  • Anyone with physical access to data that has been encrypted improperly

  • Mobile malware acting on an adversary’s behalf

Weakness

  • Weak encryption algorithms or flaws within the encryption process

Vulnerabilities

  • The mobile app may use a process behind the encryption / decryption that is fundamentally flawed and can be exploited by the adversary to decrypt sensitive data

  • The mobile app may implement or leverage an encryption / decryption algorithm that is weak in nature and can be directly decrypted by the adversary

  • Poor Key Management Processes

    • Including the keys in the same attacker-readable directory as the encrypted content

    • Making the keys otherwise available to the attacker

    • Avoid the use of hardcoded keys within your binary

    • Keys may be intercepted via binary attacks

  • Creation and Use of Custom Encryption Protocols

  • Use of Insecure and/or Deprecated Algorithms

    • RC2

    • MD4

    • MD5

    • SHA1

Prevention Techniques

  • Avoid the storage of any sensitive data on a mobile device where possible

  • Apply cryptographic standards that will withstand the test of time for at least 10 years into the future

  • Follow the NIST guidelines on recommended algorithms

M6 - Insecure Authorization

Threat Agents

  • Through automated attacks that use available or custom-built tools

Weakness

  • Poor or missing authorization schemes

  • Authorization requirements are more vulnerable when making authorization decisions within the mobile device instead of through a remote server

Vulnerabilities

  • Presence of Insecure Direct Object Reference (IDOR) vulnerabilities

  • Hidden Endpoints

  • User Role or Permission Transmissions

Prevention Techniques

  • Verify the roles and permissions of the authenticated user using only information contained in backend systems. Avoid relying on any roles or permission information that comes from the mobile device itself

  • Backend code should independently verify that any incoming identifiers associated with a request (operands of a requested operation) that come along with the identify match up and belong to the incoming identity

M7 - Poor Code Quality

Threat Agents

  • Pass untrusted inputs to method calls made within mobile code

  • Poor code-quality issues are typically exploited via malware or phishing scams

Weakness

  • Memory leaks, buffer overflows, and other less severe issues that result in bad programming practice

Vulnerabilities

  • Using the wrong API, using an API insecurely, using insecure language constructs, or some other code-level issue

Prevention Techniques

  • Maintain consistent coding patterns that everyone in the organization agrees upon

  • Write code that is easy to read and well-documented

  • When using buffers, always validate that the the lengths of any incoming buffer data will not exceed the length of the target buffer

  • Via automation, identify buffer overflows and memory leaks through the use of third-party static analysis tools

  • Prioritize solving buffer overflows and memory leaks over other 'code quality' issues

M8 - Code Tampering

Threat Agents

  • Via malicious forms of the apps hosted in third-party app stores

  • Trick the user into installing the app via phishing attacks

Weakness

  • An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application’s data and resources.

Vulnerabilities

  • Technically, all mobile code is vulnerable to code tampering

  • It is important to ask yourself if it is worth detecting and trying to prevent unauthorized code modification.

Prevention Techniques

  • Try and detect compromised environments (rooted/jaibreak) at runtime and react accordingly (report to the server or shutdown)

M9 - Reverse Engineering

Threat Agents

  • Download the targeted app from an app store and analyze it within their own local environment using a suite of different tools.

  • Relatively affordable and well-understood tools

    • IDA Pro

    • Hopper

    • otool

    • strings

Weakness

  • Code written in languages / frameworks that allow for dynamic introspection at runtime (Java, .NET, Objective C, Swift) are particularly at risk for reverse engineering.

Vulnerabilities

  • Generally, most applications are susceptible to reverse engineering due to the inherent nature of code.

  • An app is said to be susceptible to reverse engineering if an attacker can do any of the following things

    • Clearly understand the contents of a binary’s string table

    • Accurately perform cross-functional analysis

    • Derive a reasonably accurate recreation of the source code from the binary

Prevention Techniques

  • Use an obfuscation tool

M10 - Extraneous Functionality

Threat Agents

  • An attacker seeks to understand extraneous functionality within a mobile app in order to discover hidden functionality in in backend systems

Weakness

  • Functionality that exposes information related to back-end test, demo, staging, or UAT environments should not be included in a production build

  • Administrative API endpoints, or unofficial endpoints should not be included in final production builds

Vulnerabilities

  • Developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment

  • Leaving functionality enabled in the app that was not intended to be released

Prevention Techniques

  • Examine the app’s configuration settings to discover any hidden switches

  • Verify that all test code is not included in the final production build of the app

  • Examine all API endpoints accessed by the mobile app to verify that these endpoints are well documented and publicly available

  • Examine all log statements to ensure nothing overly descriptive about the backend is being written to the logs