mobile10

OWASP MOBILE TOP TEN - IN MY OWN WORDS

1. Improper Platform Usage
2. Insecure Data Storage
3. Insecure Communication
4. Insecure Authentication
5. Insufficient Cryptography
6. Insecure Authorization
7. Client Code Quality
8. Code Tampering
9. Reverse Engineering
10. Extraneous Functionalities




----- 1. IMPROPER PLATFORM USAGE

	This vulnerability occurs when an application does not use the mobile  platform in a secure manner. Best practice and development guidelines are published by the platforms themselves, and applications that violate these guidelines are likely to be misusing the mobile platform itself. This can lead to the exposure of a web service or API call implemented using insecure techniques, which may produce a "standard" OWASP Top Ten Vulnerability.


Example: A bank's mobile app allows users to log in to their account from their mobile device and perform financial transactions. For convenience, the application implements a "remember me" feature, which stores the login information on the device itself. Instead of storing this information in the device's secure keychain, the application stores it among its resources on the devices file system. Data stored in local application storage is available in unencrypted backups, and may expose the user's account credentials.




----- 2. INSECURE DATA STORAGE

	This vulnerability includes insecurely stored or unintentionally leaked data. Developers may assume that their responsibility to keep data secure ends after transmission, and may not store data in a manner that would render it inaccessible to an attacker with physical access to a mobile device. Mobile file systems may not be obviously accessible, but can be easily accessed via external or third party applications.
	Unintended data leakage occurs most commonly during caching and data-gathering processes.  Leakage frequently occurs when the operating system, application framework, or third-party (advertising, social media, accessibility) frameworks cache data, images, key-presses, logs and buffers.

	To mitigate these risks, applications must employ secure storage mechanisms that employ reliable authentication, authorization, access control and encryption where needed. Data leakage is harder to predict, and may only be discoverable under empirical testing.

Example: (Same example as #1)


----- 3. INSECURE COMMUNICATION

	Data between mobile clients and a server must travel through the internet and a mobile carrier's network.  Along the way, this data may become vulnerable to interception. Interception can occur within a local network, in a carrier or network device, or on a device itself that is infected with malware. Mobile applications often do not employ TLS as often as their desktop counterparts - it may only be used during sensitive steps such as logins or authentication. This leaves the application's traffic open to interception.
	This possibility has many negative implications. Traffic is now suspect, as interception calls into question data's integrity, confidentiality and origin. Data may be eavesdropped on, altered in transmission, captured, or used in replay attacks.
	This vulnerability affects all transmission technologies a mobile device might use: Wifi, Bluetooth, SMS, 3G, LTE, TCP/IP, etc. All TLS, NFC, Wifi and Bluetooth concerns fall into this category.

	To mitigate these risks, applications must be designed with the assumption that all networks are susceptible to eavesdropping and interception. TLS must be correctly implemented on all channels using industry-strength cipher suites. Applications must only accept certificates from trusted authorities, forbid self-signed certificates and alert users when a certificated is untrustworthy or invalid. Sensitive data must not be sent over alternate channels such as SMS, and if possible, sensitive data should be covered by an additional layer of encryption.


Example: The bank app sends requests to its server over HTTP without employing TLS. Packet sniffing of the local network allows an attacker to simply pull the packet containing a user's banking information out of the air, potentially in plaintext.


---- 4. INSECURE AUTHENTICATION

	Authentication, along with authorization and permissions checking determine what actions a user is able to execute within an application or on its server. Insecure authentication can set off a chain reaction that leads reasonable doubt of a user's identity and the possibility of an attacker doing things that only administrators should be able to do.			Authentication schemes for mobile applications commonly does not keep pace with desktop applications due to the form factor of mobile devices. Numeric pads and small, teeny on-screen keyboards make it difficult input passwords.Mobile networks are far less predictable than stationary desktop internet connections. This requires mobile applications to  employ offline authentication which may only use local resources.

	To mitigate these risks, mobile authentication must be up to par with  desktop standards, and should rely on offline and client-side authentication as much as possible. If client-side data storage is required, data must be encrypted using a securely stored and generated key derived from the user's login credentials to ensure that data can only be accessed after successful authentication. "Remember me" functionality should avoid storing credentials on the device when possible, or do so securely if not. Applications must never use spoof-able values for authentication, such as location or IP address. Mobile application's should utilize device-unique authentication tokens that can be revoked by the user on request. If offline usage is required, mobile applications should require local authentication and authorization checks and implement binary integrity checks to detect code changes.






----- 5. INSUFFICIENT CRYPTOGRAPHY

	Application data can, and should be encrypted when possible. Without adequate encryption, data is vulnerable to exposure. This vulnerability manifests in two fundamental ways: exploitation of insecure processes that runs behind encryption, or exploitation of a weakness in the encryption algorithm itself. In addition, mismanagement of cryptographic keys can render encryption useless.

	Mobile platforms may provide encryption by default, but applications must not rely on these processes, which may be circumvented if a device has been rooted or jailbroken. Only modern, strong, approved algorithms should be used. Obsolete algorithms are still available, but should not be used. Check standards like NIST for approved algorithms, and developers should never use algorithms that they "rolled" themselves in production.
	Keys must be stored, shared and implemented securely. Keys must never be stored in the same location as encrypted content. Hard-coded credentials must never be included in the binary, and care must be taken against binary attacks that may reveal the keys themselves.
	Whenever possible, it is best to avoid storage of sensitive information on the device.

Example: The developers of the banking application store their application data using a custom algorithm that first encodes the data as base64, then applies an OTP cipher using the current time as the key. An attacker is able to see what time the file was "encrypted," and is thus able to determine the key and un-encrypt the data.



---- 6. INSECURE AUTHORIZATION

	Due to a heavy reliance on a limited, tap-centric interface and the necessity to run offline, authorization in mobile applications requires special attention. While running offline, applications cannot query a server for authorization checking and must instead perform the functions locally. While running in offline mode, an attacker will be able to perform automated inspection of the application without detection and may quickly discover resources with misconfigured access privileges. These resources may be misconfigured based on a developer's assumption that due to the limited interface available on mobile devices, only resources presented to the user intentionally can be accessed. If developers assume that only authenticated, authorized users can access a resource, they may not bother to verify interaction with it. This could lead to unauthorized access to sensitive information and administrator functionalities.
	An attacker may be able to execute a privileged functionality via a POST/GET request using a session token belonging to a low-privilege user. An application has an Insecure Direct Object vulnerability, where an application exposes a direct reference to an internal object, are likely not performing adequate authorization checking.


	Mobile applications should never transmit user roles or permissions to a back-end system as part of a request, as those can be forged or intercepted. Applications should verify roles and permissions of authenticated user using information contained in back-end systems whenever possible, and never rely solely on client or application-side roles and checks. Back-end code must independently verify identifiers contained in requests and ensure that they belong to the supposed user.

Example: From within the bank's mobile app, the "change your password" function can only be reached once a user has logged in. Assuming that requests could only be submitted by authenticated users, the back-end does not require authentication to perform deliver on this request, and only requires that a username be included in the request. An attacker may be able to intercept one of these requests and alter it to arbitrarily change the password of any user they know the username of.


---- 7. POOR CODE QUALITY

	Mobile devices are computers, and may contain application vulnerabilities such as memory leaks and buffer overflows. Any client-side code run on the device may contain insecure instructions that could be manipulated by an attacker in the same way they are on a non-mobile device. Any code-level implementation problems on the mobile client fall into this category. If a rewrite of application code would fix a problem, it would fall here. These vulnerabilities refer to problems in the application's language itself, not the way it interacts with the platform

	Code quality is a team effort that requires cooperation and consistency. Code must be well documented, easily read, and follow best practices and consistent design patterns agreed upon by all developers. Manual and automated code review is a must. Automated tools should be used to identify buffer overflows and memory leaks, all inputs must be validated, and prevention of buffer overflows must be a top priority.


Example: (C buffer overflow)


----- 8. CODE TAMPERING

	This vulnerability occurs when an attacker is able to make direct changes to an application's core binary and resources, or redirect/replace system APIs to an interception point. Attackers may create malicious clones of, "extensions" for  or "updates" to popular applications. These may be placed in third party app stores, or distributed via social engineering. This category covers binary patching (modifications to binaries), local resource modification, method hooking (intercepting function calls) and method swizzling (altering an existing function)

	All applications are vulnerable to tampering, but mitigation is possible. At runtime, an application must be able to detect any integrity changes since it compiled. If an integrity change is detected, the user must be alerted and potentially given the option to re-compile the application from an official source.


Example: The bank application offers a premium functionality that lets a user skip the customer support queue. In a third party app store, a malicious actor has created a copy of the application that claims to provide this functionality free of charge. This clone creates a backdoor to the user's device.



----- 9. REVERSE ENGINEERING

	Attackers can use widely available, and often open-source tools to attempt to reverse-engineer the application in a controlled environment. An attacker may be able to determine a functions original string table, source code, libraries, algorithms and embedded resources.

	Reverse engineering efforts can be made on any application, but some are more susceptible than others. Languages and frameworks that allow for dynamic introspection at runtime (Like Java, .NET, and SWIFT) are at particularly high risk.  The same metadata and language features that assist with debugging can also be used in reverse engineering.

	Obfuscation methods can be used to mitigate reversing. Good obfuscation software can apply obfuscation to a narrow selection of methods and segments, balance the degree of obfuscation with performance impacts, obfuscate both string tables and methods, and stand up to de-obfuscation attempts by common tools.


Example: In an attempt to increase security, the bank application contains code that will not allow use on a jailbroken device. Since this jailbreak protection is in place, the developers have relied on platform-based encryption to protect sensitive resources. Using a commercially available code analysis tool, an attacker is able to discover and disable jailbreak detection, and access the sensitive information on a jailbroken device.



----- 10. EXTRANEOUS FUNCTIONALITY

	Developers may include non-essential functionalities, often for debugging purposes, that often survive into production. Developers may intentionally include these functions for their own use, but store them in locations they believe to be inaccessible to the user.

	An attacker will run the application in a controlled environment and examine log, configuration and binary files to discover hidden switches, test code, or sensitive comments left behind by the developers. Automated tools can be used in this process. Extraneous functionalities may be exploitable, and if the developer believed they were secret, the likelihood they are vulnerable is higher.

	Functionalities that expose information related to back-end testing, demonstration, staging or user testing, as well as administrative APIS should not be included in production. Developers must be aware that these functionalities pose a risk, and must attempt to keep them out of production builds. Security and subject matter experts should manually review code and configurations and verify that no hidden switches, test code, undocumented API endpoints are included, and that sensitive data is not written to logs.