OWASP started in 2001 as an online community focused on delivering unbiased and free analysis and guidelines on cyber security. Since then, their famous Top 10 Web Application Vulnerability lists have received near universal praise and endorsement from numerous specialists in the field of cyber security and largely considered to be the standard to adhere to.
Their lists help with security awareness and clue developers on where to look and what to prioritize in order to create more secure web apps. Custom cyber security tools and clear technical guidelines, such as OWASP mobile security testing guide, make OWASP useful and trustworthy for technical communities.
And when it comes to OWASP mobile application security list, it is based on data carefully gathered from vendors and consultants over the course of the year, that is then analyzed and distilled to the 10 categories that encompass most common and most severe vulnerabilities out there.
You can find the full description of each category at the official OWASP website, coupled with details and other useful information. Now, let's look at these categories in more detail.
M1: Weak Server Side Controls M1 encompasses almost everything that a mobile application can do badly that does not take place on the phone. Experience suggests that several factors have lead to a proliferation of server-side vulnerabilities. These factors include:
Rush to market;
Lack of security knowledge because of the new-ness of the languages;
Easy access to frameworks that don’t prioritize security;
Higher than average outsourced development;
Lower security budgets for mobile applications;
Assumption that the mobile OS takes full responsibility for security; and
Weakness due to cross-platform development and compilation.
M2: Insecure Data Storage
It is important to threat-model your mobile app to understand the information assets it processes and how the underlying APIs handle those assets. These APIs should store sensitive information securely. Places OWASP most often sees data being stored insecurely include the following:
SQLite databases Log Files
Plist Files
XML Data Stores or Manifest Files
Binary data stores
Cookie stores
SD Card
Cloud synced
M3: Insufficient Transport Layer Protection
When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device’s carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it’s traveling across the wire. The following threat agents exist:
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.
M4: Unintended Data Leakage Unintended data leakage (formerly side-channel data leakage) includes vulnerabilities from the OS, frameworks, compiler environment, new hardware, etc. without a developers knowledge.
In mobile development, this is most seen in undocumented (or under-documented) internal processes such as:
The way the OS caches data, images, key-presses, logging, and buffers. The way the development framework caches data, images, key-presses, logging, and buffers. The way or amount of data ad, analytic, social, or enablement frameworks cache data, images, key-presses, logging, and buffers.
M5: Poor Authorization and Authentication
Avoid the following Insecure Mobile Application Authentication Design Patterns:
If you are porting a web application to its mobile equivalent, authentication requirements of mobile applications should match that of the web application component. Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through run-time manipulation or modification of the binary Ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. 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.
M6: Broken Cryptography
Insecure use of cryptography is common in most mobile apps that leverage encryption. There are two fundamental ways that broken cryptography is manifested within mobile apps. First, 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. Second, the mobile app may implement or leverage an encryption / decryption algorithm that is weak in nature and can be directly decrypted by the adversary. Some of the key points explore both of these scenarios in more depth such as:
Reliance Upon Built-In Code Encryption Processes
Poor Key Management Processes
Creation and Use of Custom Encryption Protocols
Use of Insecure and/or Deprecated Algorithms
M7: Client Side Injection
The best way to find out if an application is vulnerable to injection is to identify the sources of input and validate that user/application supplied data is being subject to input validation, disallowing code injection.Since data can come from many sources in mobile applications, it is important to list them delineated by what they are trying to achieve. In general, injection attacks on mobile devices target the following:
Data on the Device:
SQL Injection: SQLite) can be subject to injection just like in web applications. The threat of being able to see data using this type of injection is risky when your application houses several different users, paid-for/unlockable content, etc.
Local File Inclusion: File handling on mobile devices has the same risks as stated above except it pertains to reading files that might be yours to view inside the application directory. The Mobile Users Session:
JavaScript Injection (XSS, Etc): The mobile browser is subject to JavaScript injection as well. Usually the mobile browser has access to the mobile applications cookie, which can lead to session theft. The Application Interfaces or Functions:
Several application interfaces or language functions can accept data and can be fuzzed to make applications crash. While most of these flaws do not lead to overflows because of the phone’s platforms being managed code, there have been several that have been used as a “userland” exploit in an exploit chain aimed at rooting or jail breaking devices. Binary Code Itself:
Mobile malware or other malicious apps may perform a binary attack against the presentation layer (HTML; JavaScript; Cascading Style Sheets CSS) or the actual binary of the mobile app’s executable. These code injections are executed either by the mobile app’s framework or the binary itself at run-time.
How to prevent it?
In general, protecting you application from client side injection requires looking at all the areas your application can receive data from and applying some sort of input validation. In certain cases this is simple but for others it is more complex
Android Specific Best Practices:
SQL Injection: When dealing with dynamic queries or Content-Providers ensure you are using parameterized queries.
JavaScript Injection (XSS): Verify that JavaScript and Plugin support is disabled for any Web Views (usually the default).
Local File Inclusion: Verify that File System Access is disabled for any WebViews (webview.getSettings().setAllowFileAccess(false);).
Intent Injection/Fuzzing: Verify actions and data are validated via an Intent Filter for all Activities.
M8: Security Decisions Via Untrusted Inputs
Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:
If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications
Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks
Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios
How to prevent it?
iOS Specific Examples:
Do not use the deprecated handleOpenURL method to handle URL Scheme calls. This method does not contain an argument containing the BundleID of the source application. Instead use the openURL:sourceApplication:annotation method and validation the sourceApplication argument against a white-list of trusted applications Do not use the iOS Pasteboard for IPC communications, as it is susceptible to being set or read by all third party apps on the device.
M9: Improper Session Handling
Improper Session Handling typically results in the same outcomes as poor authentication. Once you are authenticated and given a session, that session allows one access to the mobile application. Mobile app code must protect user sessions just as carefully as its authentication mechanism.
Here are some examples of how it is often done improperly:
Failure to Invalidate Sessions on the Backend
Lack of Adequate Timeout Protection
Failure to Properly Rotate Cookies
Insecure Token Creation
How to prevent it?
To handle sessions properly, ensure that mobile app code creates, maintains, and destroys session tokens properly over the life-cycle of a user’s mobile app session.
M10: Lack of Binary Protections
If you are hosting code in an untrustworthy environment, you are susceptible to this risk. This includes mobile clients, firmware in appliances, cloud spaces, or datacenters within particular countries.
If you answer yes to any of these questions, you are vulnerable to a binary attack:
Can someone code-decrypt this app (iPhone specific) using an automated tool like Clutch Mod or manually using GDB?
Can someone reverse engineer this app (Android specific) using an automated tool like dex2jar?
Can someone use an automated tool like Hopper or IDA Pro to easily visualize the control-flow and pseudo-code of this app?
Can someone modify the app’s presentation layer (HTML/JS/CSS) of this app within the phone and execute modified JavaScript?
Can someone modify the app’s binary executable using a hex editor to get it to bypass a security control?