OWASP Mobile Security Project
- Top 10 Mobile Risks
- Mobile Security Checklist
- Mobile Application Security Verification Standard
- Mobile Security Testing Guide
- Secure M-Development
- Top 10 Mobile Controls
- M-Threat Model Project
OWASP Mobile Security Project
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
Our primary focus is at the application layer. While we take into consideration the underlying mobile platform and carrier inherent risks when threat modeling and building controls, we are targeting the areas that the average developer can make a difference. Additionally, we focus not only on the mobile applications deployed to end user devices, but also on the broader server-side infrastructure which the mobile apps communicate with. We focus heavily on the integration between the mobile application, remote authentication services, and cloud platform-specific features.
This project is still a work in progress. We are small group doing this work and could use more help! If you are interested, please contact one of the project leads or feel free to visit the mailing list as well!
Please visit the project page for current information.
About this list
In 2015, we performed a survey and initiated a Call for Data submission Globally . This helped us to analyze and re-categorize the OWASP Mobile Top Ten for 2016. So the top ten categories are now more focused on Mobile application rather than Server.
Our goals for the 2016 list included the following:
This list has been finalized after a 90-day feedback period from the community. Based on feedback, we have released a Mobile Top Ten 2016 list following a similar approach of collecting data, grouping the data in logical and consistent ways.
Feel free to visit the mailing list as well!
Top 10 Mobile Risks - Final List 2016
Top 10 Mobile Risks - Final List 2014
The checklist is hosted on the OWASP MSTG project page.
The standard is hosted on the OWASP MSTG project page.
The OWASP Mobile Security Testing Guide is now a separate project - check the OWASP MSTG project page for details.
The OWASP Mobile Security project has a long history. It has been a source for many projects their predecessors as is clearly visible in the archive.
iMAS is a collaborative research project from the MITRE Corporation focused on open source iOS security controls. Today, iOS meets the enterprise security needs of customers, however many security experts cite critical vulnerabilities and have demonstrated exploits, which pushes enterprises to augment iOS deployments with commercial solutions. The iMAS intent is to protect iOS applications and data beyond the Apple provided security model and reduce the adversary’s ability and efficiency to perform recon, exploitation, control and execution on iOS mobile applications. iMAS will transform the effectiveness of the existing iOS security model across major vulnerability areas including the System Passcode, jailbreak, debugger / run-time, flash storage, and the system keychain. Research outcomes include an open source secure application framework, including an application container, developer and validation tools/techniques.
The source code for iMAS is available on GitHub: iMAS Source Code
OWASP GoatDroid is a fully functional and self-contained training environment for educating developers and testers on Android security. GoatDroid requires minimal dependencies and is ideal for both Android beginners as well as more advanced users. The project currently includes two applications: FourGoats, a location-based social network, and Herd Financial, a mobile banking application. There are also several features that greatly simplify usage within a training environment or for absolute beginners who want a good introduction to working with the Android platform.
As the Android SDK introduces new features, the GoatDroid contributors will strive to implement up-to-date lessons that can educate developers and security testers on new security issues. The project currently provides coverage for most of the OWASP Top 10 Mobile Risks and also includes a bunch of other problems as well.
You can find GoatDroid on GitHub: GoatDroid Source Code
iGoat is a learning tool for iOS developers (iPhone, iPad, etc.). It was inspired by the WebGoat project, and has a similar conceptual flow to it.
As such, iGoat is a safe environment where iOS developers can learn about the major security pitfalls they face as well as how to avoid them. It is made up of a series of lessons that each teach a single (but vital) security lesson.
The lessons are laid out in the following steps:
Step 4 is optional, but highly recommended for all iOS developers. Assistance is available within iGoat if you don't know how to fix a specific problem.
iGoat is free software, released under the GPLv3 license.
The iGoat source code is available on Google Code iGoat Source Code
Damn Vulnerable iOS Application
Damn Vulnerable iOS application is a project started by Prateek Gianchandani which gives mobile testers and developers an iOS application to practice attacking/defending skill sets. Each challenge area corresponds to an in-depth article designed to teach the fundamentals of mobile security on the iOS platform. Some challenge categories include multiple challenge types.
The current challenge categories:
The MobiSec Live Environment Mobile Testing Framework project is a live environment for testing mobile environments, including devices, applications, and supporting infrastructure. The purpose is to provide attackers and defenders the ability to test their mobile environments to identify design weaknesses and vulnerabilities. The MobiSec Live Environment provides a single environment for testers to leverage the best of all available open source mobile testing tools, as well as the ability to install additional tools and platforms, that will aid the penetration tester through the testing process as the environment is structured and organized based on an industry‐proven testing framework. Using a live environment provides penetration testers the ability to boot the MobiSec Live Environment on any Intel-based system from a DVD or USB flash drive, or run the test environment within a virtual machine.
MobiSec can be downloaded from Sourceforge: MobiSec Download Repository
Androick is a collaborative research project from PHONESEC Ltd. With our tool, you can evaluate some risks on Android mobile applications. Androick is a tool that allows any user to analyze an Android application. It can get the apk file, all the datas and the databases in sqlite3 and csv format. Only for Pentesters or Researchers.
NowSecure App Testing Community Edition
The NowSecure App Testing Community Edition is the freely downloadable version of the powerful App Testing suite. Users are offered a number of features such as network capture, automation, import / export, and reporting to test and secure mobile apps.
It provides the opportunity to complete mobile app security tests on any application on Android or iOS mobile devices (or installed in an emulator).
The suite is provided as a preconfigured virtual machine (VM). After downloading the VM and licensing your version of the suite you will have everything you need to test the security of mobile apps.
Built in emulator - Don’t have a device? No worries. The suite includes a built in Emulator that may be used to test the security of your mobile applications.
OWASP SeraphimDroid is educational, privacy and device protection application for android devices that helps users learn about risks and threats coming from other android applications. SeraphimDroid is also an application firewall for android devices not allowing malicious SMS or MMS to be sent, USSD codes to be executed or calls to be called without user permission and knowledge.
OWASP Summer of Code 2008
The OWASP Foundation sponsored the OWASP Application Security Verification Standard Project during the OWASP Summer of Code 2008.
Secure Mobile Development Guidelines Objective
The OWASP Secure Development Guidelines provides developers with the knowledge they need to build secure mobile applications. An extendable framework will be provided that includes the core security flaws found across nearly all mobile platforms. It will be a living reference where contributors can plug in newly exposed APIs for various platforms and provide good/bad code examples along with remediation guidance for those issues.
Mobile Application Coding Guidelines
The purpose of this section is to provide application developers guidelines on how to build secure mobile applications, given the differences in security threat between applications running on a typical desktop as compared to those running on a mobile device (such as tablets or cell phones).
Using the guidance provided here, developers should code their applications to mitigate these malicious attacks. While more general coding guidelines should still be followed as applicable, this page lists additional considerations and/or modifications to common guidelines and is written using the best knowledge available at this time.
Authentication and Password Management
This is a set of controls used to verify the identity of a user, or other entity, interacting with the software, and also to ensure that applications handle the management of passwords in a secure fashion.
This is a set of controls used to prevent reverse engineering of the code, increasing the skill level and the time required to attack the application.
This is a set of controls to help ensure the software handles the sending and receiving of information in a secure manner.
Data Storage and Protection
This is a set of controls to help ensure the software handles the storing and handling of information in a secure manner. Given that mobile devices are mobile, they have a higher likelihood of being lost or stolen which should be taken into consideration here.
This is a set of practices to ensure the application properly enforces access controls related to resources which require payment in order to access (such as access to premium content, access to additional functionality, access to improved support, etc…).
This is a set of practices to ensure the server side program which interfaces with the mobile application is properly safeguarded. These controls would also apply in cases where the mobile application may be integrating with vended solutions hosted outside of the typical network.
This is a set of controls to help ensure mobile applications handle sessions in a secure manner.
Use of 3rd Party Libraries/Code
This is a set of practices to ensure the application integrates securely with code produced from outside parties.
Mobile Application Provisioning/Distribution/Testing
This is a set of controls to ensure that software is tested and released relatively free of vulnerabilities, that there are mechanisms to report new security issues if they are found, and also that the software has been designed to accept patches in order to address potential security issues.
OWASP and the European Network and Information Security Agency (ENISA) collaborated to build a joint set of controls. ENISA has published the results of the collaborative effort as the "Smartphone Secure Development Guideline": http://www.enisa.europa.eu/activities/application-security/smartphone-security-1/smartphone-secure-development-guidelines
This document has been jointly produced with ENISA as well as the following individuals:
Top 10 mobile controls and design principles
Risks: Unsafe sensitive data storage, attacks on decommissioned phones unintentional disclosure: Mobile devices (being mobile) have a higher risk of loss or theft. Adequate protection should be built in to minimize the loss of sensitive data on the device.
2. Handle password credentials securely on the device
Risks: Spyware, surveillance, financial malware. A user's credentials, if stolen, not only provide unauthorized access to the mobile backend service, they also potentially compromise many other services and accounts used by the user. The risk is increased by the widespread of reuse of passwords across different services.
￼￼￼Smartphones secure development guidelines for app developers ￼the user credentials initially. The tokens should be time bounded to the specific service as well as revocable (if possible server side), thereby minimizing the damage in loss scenarios. Use the latest versions of the authorization standards (such as OAuth 2.0). Make sure that these tokens expire as frequently as practicable.
3. Ensure sensitive data is protected in transit
Risks: Network spoofing attacks, surveillance. The majority of smartphones are capable of using multiple network mechanisms including Wi-Fi, provider network (3G, GSM, CDMA and others), Bluetooth etc. Sensitive data passing through insecure channels could be intercepted. (9) (10)
Reference: Google vulnerability of Client Login account credentials on unprotected wifi - 
4. Implement user authentication,authorization and session management correctly
Risks: Unauthorized individuals may obtain access to sensitive data or systems by circumventing authentication systems (logins) or by reusing valid tokens or cookies. (13)
5. Keep the backend APIs (services) and the platform (server) secure
Risks: Attacks on backend systems and loss of data via cloud storage. The majority of mobile applications interact with the backend APIs using REST/Web Services or proprietary protocols. Insecure implementation of backend APIs or services, and not keeping the back-end platform hardened/patched will allow attackers to compromise data on the mobile device when transferred to the backend, or to attack the backend through the mobile application. (14)
6. Secure data integration with third party services and applications
Risks: Data leakage. Users may install applications that may be malicious and can transmit personal data (or other sensitive stored data) for malicious purposes.
7. Pay specific attention to the collection and storage of consent for the collection and use of the user’s data
Risks: Unintentional disclosure of personal or private information, illegal data processing. In the European Union, it is mandatory to obtain user consent for the collection of personally identifiable information (PII). (15) (16)
8. Implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls etc.) Risks: Smartphone apps give programmatic (automatic) access to premium rate phone calls, SMS, roaming data, NFC payments, etc. Apps with privileged access to such API’s should take particular care to prevent abuse, considering the financial impact of vulnerabilities that giveattackers access to the user’s financial resources.
9. Ensure secure distribution/provisioning of mobile applications
Risks: Use of secure distribution practices is important in mitigating all risks described in the OWASP Mobile Top 10 Risks and ENISA top 10 risks.
10. Carefully check any runtime interpretation of code for errors
Risks: Runtime interpretation of code may give an opportunity for untrusted parties to provide unverified input which is interpreted as code. For example, extra levels in a game, scripts, interpreted SMS headers. This gives an opportunity for malware to circumvent walled garden controls provided by app-stores. It can lead to injection attacks leading to Data leakage, surveillance, spyware, and diallerware.
Appendix A- Relevant General Coding Best Practices'
Some general coding best practices are particularly relevant to mobile coding. We have listed some of the most important tips here:
system. Be aware of privileges granted by default by APIs and disable them.
Use the communication mechanisms provided by the OS.
including sensitive user information.
￼￼￼￼Smartphones secure development guidelines for app developers
￼*12. NIST Computer Security. [Online] http://csrc.nist.gov/publications/nistpubs/800-57/sp800- 57_PART3_key-management_Dec2009.pdf.
Mobile Application Threat Model - Beta Release
This is the first release (February 2013) of the Mobile Application Threat Model developed by the initial project team (listed at the end of this release). Development began mid-2011 and is being released in beta form for public comment and input. It is by no means complete and some sections will need more contributions, details and also real world case studies. It's the hope of the project team that others in the community can help contribute to this project to further enhance and improve this threat model.
Mobile Threat Model Introduction Statement
Threat modeling is a systematic process that begins with a clear understanding of the system. It is necessary to define the following areas to understand possible threats to the application:
Target Audience for the Mobile Threat Model
This model is to be used by mobile application developers and software architects as part of the “threat modeling” phase of a typical SDLC process. The model can also be used by Information Security Professionals that need to determine what typical mobile application threats are and provide a methodology for conducting basic threat modeling.
How to Use the Mobile Threat Model
This threat model is designed as an outline or checklist of items that need to be documented, reviewed and discussed when developing a mobile application. Every organization that develops mobile applications will have different requirements as well as threats. This model was designed to be as organizational and industry agnostic as possible so that any mobile application development team can use this as a guide for conducting threat modeling for their specific application. Real world case studies as examples will be integrated to this threat model in the near future.
Mobile Application Architecture
The mobile application architecture should, at the very least, describe device specific features used by the application, wireless transmission protocols, data transmission medium, interaction with hardware components and other applications. Applications can be mapped to this architecture as a preliminary attack surface assessment.
Although mobile applications vary in function, they can be described using a generalized model as follows:
Interaction with on device applications/services
Interaction with off device applications/services
This section defines what purpose does the app serve from a business perspective and what data the app store, transmit and receive. It’s also important to review data flow diagrams to determine exactly how data is handled and managed by the application.
Threat Agent Identification
What are the threats to the mobile application and who are the threat agents. This area also outlines the process for defining what threats apply to the mobile application.
Identifying Threat Agents
The process of identifying a threat agent is very simple and have been mentioned in the below steps:
S1: Take the list of all sensitive data (or information to protect) listed down from Section 2 – Mobile Data
S2: Make a list of all the ways to access this data
S3: The medium used to access the same listed in S3 is the Threat Agent to be identified
Threat Agent Identification Example
Let us understand it in a better way using an example of a Financial Application (specifically a Banking Application). Following the process as mentioned above:
S1: Sensitive data present in the application has been listed as: Beneficiary Details stored in some form in the Phone Application Memory and User Credentials used for authentication transmitted to the server. S2: List the various ways of accessing information:
Listing of Threat Agents - By Category
Below is a diagram illustrated to understand the Threat Agents and Threats in a visual manner:
Figure 1 : Pictorial Representation of Threats and Agents
Methods of Attack
In this section, we will observe different methods an attacker can use to reach the data. This data can be sensitive information to the device or something sensitive to the app itself.
Destruction of the asset is normally classified as attack. Attack can be further categorized as a planned attack or an unplanned one. Unintended attacks are normally caused due to some form of accidental actions.
Figure 2: Attack Workflow
“Method aimed to read the local application memory”
The above mentioned attack methodology is the one in which the data which is targeted is application specific memory and the method used is memory based analysis. The attacker steals any sensitive data like passwords, userid, user account information which is stored in the application memory by reading the device memory.
We have listed down other methods below which can be mapped with the second section in a similar fashion:
The classification of attacks based on the way data is handled:
What are the controls to prevent attacks. This is the last area to be defined only after previous areas have been completed by the development team.
Special thanks to the following team members who contributed to the initial release of the threat model: