Mobile devices and mobile apps are part of our daily lifestyle. We as the users expect that our data is private and safe. How does a developer start with writing secure mobile apps?
This comic above describes a typical scenario at many mobile companies. The manager asks the developer to create an app with hundreds of features and make the app secure. Before we continue, and I assume the biggest audience for this article are engineers, how would you approach this problem? Where would you start?
Please take your time and think about it for a minute or two.
Ready? If your list is relatively thin or quite vague, this article is for you. And I can’t blame you. Security seems like a dry and complicated topic. The good news is that there is a lot of information available. The goal of this article is to show you a clear path where and how to start. Bear with me. Let’s do it.
Why security Link to heading
As the author Simon Sinek preaches, let’s start with the why: Why security? We can take two perspectives here: The user and the apps’ developer.
App user perspective Link to heading
Our mobile phones became our daily companions. According to this Forbes article, in 2020, we spend around 4.3 hours on our phones every day. Thanks to Covid, this number increased by 25 percent compared to the year before. This time is spend while using different apps. Usage of those apps leaves a trail of data. We trust the developers as the users of those apps to keep our data safe. Security issues like possible leakage of our secrets can lead to a loss of trust in the app and the company behind the app.
App provider perspective Link to heading
A poorly secured app allows the attackers to reverse engineer the intellectual property of your company with ease. Disclose sensitive data on the mobile device is another serious business threat and can lead to revenue loss.
App security is different Link to heading
What makes the security of mobile apps different from the web or online services? The attack vector differs from other security-relevant usage types like web and online services.
Google and Apple offer great and safe operating systems and the tools to allow the developers to write beautiful and useful apps. The operating system provider learned from the past and granted each of the app its own space, a container that the app can use to store any information. Most of the apps use this container to keep some sensitive data inside. Let’s take an editor app as an example. You, as the user, write your notes and generate data. Depending on the app’s kind, your writings might only be stored locally or uploaded to a remote server. The local storage is what I describe as locally cached data. If the editor app uploads your data remotely, it would require some authentication information. This authentication information is needed to identify the user on the remote service-side and store it into the right bucket.
Another common attack vector is the intellectual property that the attacker can gain by reverse engineer the way the app functions.
Let’s summarise all the most significant attack vectors for mobile app security:
- Local stored data and authentication
- Intellectual property
This gives us a good overview of why security is essential and the biggest security threats for a mobile app. Let’s define next the steps on how we can improve the app security and reduce the attack surface.
Reduce the surface Link to heading
At the beginning of this article, I promised to show how to write secure apps. Let’s unveil this secret or introduce you to the whole group of brilliant people who share their knowledge and that for free: OWASP organization.
OWASP Link to heading
What is OWASP? OWASP is an acronym for Open Web Application Security Project and is a non-profit organization that works to improve software security. They are an excellent source for tools and resources around the security topic. That is why it is an ideal place for us to explore as well.
OWASP offers a wide range of security projects. The most common ones are the OWASP Top Ten or the OWASP Web Security Testing Guide. Besides that, and more relevant as part of this article, are the standard (MASVS) and the guide (MSTG).
The Standard - MASVS Link to heading
Photo by MASVS stands for Mobile AppSec Verification or fully expanded Mobile Application Security Verification Standard. It is the standard that defines the baseline security requirements for mobile apps.
The whole guide is open-sourced on GitHub or, even more conveniently, is available as a GitBook.
It covers a wide range of topics about architecture and building your mobile app as secure as possible. It covers all the most prominent attack vectors that we’ve identified earlier and goes even beyond that by describing requirements on other app security topics like:
- Architecture and design
- Data storage and privacy
- Cryptography
- Authentication and session management
- Network communication
- Platform interaction
- Code quality and build settings
- Resilience
Deeper Dive Link to heading
Storing sensitive data is a common task for a mobile app. Sensitive data includes:
- Personal information - PI for short
- Confidential information
- Bank and card data
- General customer information
Let’s take a look at what the standard recommends on how to store sensitive data:
Image from the guide on Data Storage and Privacy Requirements
These are great recommendations. In case you wonder what the L1 and L2 stand for:
- L1 defines Standard Security. Every mobile app out there should use and follow this standard.
- L2 is defined as Defense-in-Depth and covers more advanced topics that should be used by apps that are handling highly sensitive data, like banking apps.
Another great thing about the OWASP is that they provide us with the standard, but they also offer the checklist to follow up on all the requirements. The checklist can be found as Excel sheets on GitHub: OWASP Mobile Security Testing Guide
That is excellent stuff. The standard and the checklists provide us with the right direction on what is considered a good base for our security needs. Let’s move on to the guide.
The Guide - MSTG Link to heading
Photo by Clayton Robbins on Unsplash
MSTG stands for Mobile Security Testing Guide.
It is the guide the testers use to test your app for any security issues. The best thing about the MSTG guide is that it is quite extensive and surfaces all the testers’ knowledge. Let’s stick to our storing sensitive data example. The guide offers you an in-depth overview of how to store the data for both commonly used devices:
Each chapter contains code examples and diagrams - profound and extensive knowledge right there, offered for you for free. Just read and follow the best practices.
The authors of the guide and the standard are using the same ids for easier referencing. You can find the ID that is used in the standard by searching in the guide. Very helpful for even faster access.
There we have it. The OWASP standard and the guide contain all the knowledge we need to answer the original question about implementing secure mobile apps.
But iOS is safer Link to heading
This one goes out to all the iOS developers who are still not entirely convinced that we need all the effort described in the first part. Some of you might like to point out that the iOS platform is more secure than the Android platform, and that is why as an iOS developer, you don’t need to worry that much?
Each app is a container, and accessing all the information stored in this container is quite tricky without a Jailbroken phone. Jailbreaking used to be a big thing a while ago and lost popularity since many things the Jailbreaking of the device offered are integrated into the latest iOS (iOS 14.4 is the most current released operation system at the moment I’m writing this article). Despite the loss of popularity, Jailbreaking is still a thing and is very much possible even with iOS 14. A quick google search for Jailbreak and iOS 14 will confirm this statement.
But what if I tell you that I don’t need to Jailbreak my phone to spy on your app? Say hello to FRIDA.
FRIDA Link to heading
FRIDA is a free dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers. FRIDA is a runtime that can be compiled into an app and lets you:
- Inject scripts
- Hook into any function
- Spy on crypto APIs
- Trace private application code
You might wonder, wait, runtime, you said? That means you would need to inject the runtime into the app first. Yes, you are correct. That is not challenging. Let me introduce you to another tool that is a great companion to FRIDA: Objection. Objection makes the life of anyone interested in your app (security researchers, testers, or any dubious characters) relatively easy. With Objection, you can unzip, inject the FRIDA runtime, and the re-code sign from the Terminal with just a couple of statements. Tools like iOS-deploy let you install the app on the phone and spy on the app with the injected FRIDA runtime. All this without jailbreaking my phone.
Android Link to heading
The FRIDA toolkit works on Android as well. There are plenty of YouTube videos demonstrating the bypassing of the SSL pinning with FRIDA runtime with very little effort.
Takeaways Link to heading
Think security first. Security people call it “Shifting left”.
- Use the MASVS as the base.
- Introducing security afterward is hard.
- There is a lot of great stuff available for free out there.
- Make you all aware that a lot of smart people thought about how to make secure apps. Use their ideas and practices - It’s all free!