Mobile app security doesn’t start when a new mobile app is released. Rather, mobile app security must be part of mobile app development from the start of the project.
“We need to teach developers to think about mobile app security from the start, not as a late occurrence.”Zubin Irani – Founder and CEO of cPrime (Agile Transformation Consultant)
This article is an introduction to the security section of mobile apps with Xamarin Forms. At first this article is divided into two parts:
- Introduction to Mobile Development Security (This article)
- Best Security Practices with Xamarin Forms (Coming Soon)
Let me know on my social media what you’d like me to talk about. This is a topic spoken by a few people but personally, I like it.
What is mobile app security?
When we talk about the security of mobile applications we focus on the security posture of the software and the process of developing mobile applications on various platforms such as Android, iOS, and Windows. This covers apps that run on mobile phones as well as tablets or iPads.
Security involves evaluating applications for security issues at:
- Contexts of the platforms on which they are designed to run.
- Frameworks with which they are developed.
- Group of users or testers.
Mobile apps are a critical part of a company’s online presence, and many companies rely entirely on mobile apps to connect with users around the world.
All mobile platforms provide security controls designed to help developers build secure apps. However, the developer is often left to choose from a variety of security options.
Note: In many cases, developers have no knowledge of how to protect their apps. Lack of research can lead to the implementation of security features that attackers can easily circumvent.
Top 10 major mobile app risks
According to Owasp Foundation (Open Web Application Security Project) and its latest mobile application survey presented you with the top 10 risks in mobile applications.
1: Improper Platform Use
In this section, we can see the misuse of a platform function or the lack of use of the platform’s security controls. It may include Android intents, platform permissions, TouchID misuse, or some other security control that is part of the mobile operating system.
Secure development and configuration practices on the server-side of the mobile app should be used to prevent these risks. Strengthen your app’s authentication and consider how you handle your local and remote files.
2: Unsafe Data Storage
Insecure data storage vulnerabilities occur when development computers assume that users or malware will not have access to a mobile device’s file system and subsequent sensitive information in the device’s datastores.
It is good to mention that file systems are easily accessible and even more so on mobile devices.
Note: Companies, organizations, or development teams should not expect a malicious user or malware to inspect sensitive data stores.
Poor encryption libraries should be avoided. Rooting or jailbreaking a mobile device bypasses any encryption protection.
When data is not properly protected, all that is needed are specialized tools to view application data.
3: Unsafe Communication
Mobile apps often don’t protect network traffic. They can use SSL/TLS during authentication, but not on every call.
This inconsistency carries the risk of exposing data and session IDs to interception. Using transport security does not mean that your application has successfully deployed it.
Note: To detect basic failures, observe the phone’s network traffic. The most subtle flaws require inspecting application design and application settings.
4: Unsafe Authentication
Poor or non-existent authentication schemes allow an adversary to anonymously run functionality within the mobile app or backend server used by the mobile app.
Weak authentication for mobile apps is quite common because you want a weak user entry barrier. This factor greatly encourages short passwords that are often based exclusively on 4-digit PINs.
Authentication requirements for mobile applications can be quite different from traditional web authentication schemes due to availability requirements.
In mobile apps, users are not expected to be online at all times during their session. Mobile Internet connections are much less reliable or predictable than traditional web connections.
Mobile apps may have uptime requirements that require offline authentication.
This offline requirement can have deep ramifications in aspects that developers should consider when implementing mobile authentication.
5: Insufficient Cryptography
Unsafe use of cryptography is common in most mobile applications that take advantage of encryption.
By default, iOS apps are protected (in theory) from reverse engineering through code encryption. The iOS security model requires apps to be encrypted and signed by trusted sources in order to run in jailbroken environments.
Note: Similarly iOS apps, with the right tools, can be decrypted.
Always assume that an adversary will be able to bypass any integrated code encryption offered by the mobile operating system.
6: Unsafe Authorization
It is important to recognize the difference between authentication and authorization. Authentication is the act of identifying a user. Authorization is the act of verifying that the identified person has the necessary permissions to perform an action. The two are closely related, as authorization checks should always immediately follow the authentication of an incoming request from a mobile device.
If an organization cannot authenticate a user before making an API call from a mobile device, then the code also automatically suffers from unsafe authorization. It is essentially impossible for authorization checks to be performed on an incoming request when the caller’s identity is not established.
7: Poor Code Quality
Quality issues in the code are quite common. The good news is that most code quality issues are fairly benign and result in poor programming practice.
It is usually difficult to detect such problems by manually reviewing the code. Instead, attackers will use third-party tools to identify memory leaks, cache overflows, and other less serious problems that result in poor programming practice.
8: Code Manipulation
Modifying app shapes is surprisingly more common than you think. There is an entire security industry built around detecting and removing unauthorized versions of mobile apps within app stores.
Depending on the approach taken to solve the problem of detecting code modifications, organizations or companies may have limited to highly successful ways to detect unauthorized versions of code in their applications.
Once the app is delivered to the mobile device, the code and data resources reside there. An attacker can directly modify the code, dynamically change the contents of memory, change or replace the system APIs used by the application, or modify the application’s data and resources. This can provide the attacker with a direct method of subverting the intended use of the software for personal or monetary benefit.
Warning: Although mobile code is inherently vulnerable, it is important to ask if it is worth detecting and trying to prevent unauthorized code modification.
Applications written for certain commercial verticals (games, for example) are much more vulnerable to the impacts of code modification than others (hospitality, for example). As such, it is essential to consider the commercial impact before deciding whether or not to address this risk.
9: Reverse Engineering
Generally, the entire mobile code is reversely engineerable. Some applications are more susceptible than others. Code is written in languages/frameworks that allow dynamic runtime introspection (Java, .NET, Objective C, Swift) are particularly at risk of reverse engineering.
Detecting susceptibility to reverse engineering is quite simple. First, decrypt the app store version of the app (if binary encryption is applied). Then, with the right tools, you can analyze the binary.
The code will be susceptible if it is quite easy to understand the path of the application control flow, the string table, and any pseudocode/source code generated by these tools.
10: Strange Functionality
An attacker will download and browse your mobile app within their own development environment. They will examine the log files, configuration files, and perhaps the binary itself to discover any hidden switches or test code that developers left behind. They will exploit these switches and the functionality hidden in the backend to perform an attack.
You’ve just seen only a few of the most common sections when it comes to mobile development security. Obviously, not all cases apply for all applications, everything will depend on the need posed.
In the second part of this section, we’ll take these concepts to the development area with Xamarin where we’ll see how we can securely protect ourselves.
I hope this article will be very useful to you, and for any comments leave it in the box below. If you want me to write about specific content let me know on my social media and if your request likes it very much it is very likely that we will see it here.
With nothing else to add, see you next time!