This is an article from DZone’s 2022 Enterprise Application Security Trend Report.
For more:
Building secure mobile applications is a difficult process, especially in the cloud. We must consider that mobile platforms, like iOS and Android, have completely different architectures and quality guidelines. Also, we need to take care of our cloud architecture on the back end. In this article, we will have a look at the top six security vulnerabilities, OWASP’s best practices for building/testing iOS and Android applications, and guidelines for iOS and Android. Last but not least, we will explore an example of DevSecOps for mobile applications.
Top Three Attack Examples
To understand the importance of security for mobile apps, let’s first look at three of the most prominent hacks of mobile apps that led to huge financial and marketing issues for the affected companies.
ParkMobile Breach
In the cyber attack on the ParkMobile app in 2021, hackers managed to steal 21 million user accounts. According to Security7, hackers managed to steal telephone numbers, license plate numbers, and email addresses. It seems like all the unencrypted data were stolen passwords. However, credit cards were encrypted, so hackers didn’t manage to encrypt data as the keys weren’t stolen.
Juspay Data Leak
Juspay, a payment operator that provides services for Uber, Amazon, Swiggy, and Flipkart, was hacked through their mobile app in August 2020. The hacker stole 35 million records, including credit card data, fingerprints, and masked card data.
Walgreens Mobile App Leak
In 2020, Walgreens’ mobile app had integrated malware that watched personal messages and info. It resulted in a lot of user data being compromised, including names, prescription numbers, and addresses.
Top Six OWASP Security Vulnerability Types in iOS and Android
Before we jump into iOS and Android guidelines and OWASP Testing Guides, let’s look at the top six OWASP vulnerability types:
| Vulnerability Type | Description |
|---|---|
| Authentication issues, insecure communication | A mobile application has unencrypted UI forms, algorithms, and protocols to authenticate. An attacker uses the fake app/malware to scan and observe the application transport layer. Also, weak passwords, using geolocation to authenticate users, or using persistent authentication may lead to sensitive data leaks. |
| Reverse engineering | This vulnerability allows an attacker to analyze and obfuscate the targeted application. This may lead to sensitive data leakage that is hard coded in application configuration variables or constants. In addition, attackers may find URLs and configs to the back-end servers. |
| Data storage security vulnerability | This vulnerability allows attackers to steal data from data storage. We partially link it with “improper platform usage.” To prevent data leakage, we should use only encrypted data storage, avoid storing sensitive data (passwords, card numbers) in the device, encrypt data transfer, and use only encrypted storage OS features (e.g., iOS Keychain). We can reference CWE-922 of the mobile vulnerability registry. |
| Improper platform usage | This type of attack relies on the issue of developers not using (or improperly using) security features that are included in the operation system. Security features include Face ID, iOS Keychain, and Touch ID. For example, developers may use insecure local storage instead of iOS Keychain to store sensitive data. |
| Code tampering | Code tampering is when an attacker downloads an app and makes code changes. For example, they create fake registrations or payment forms and then upload apps back to the market or create cloned ones. It can also be a fake app (such as free mobile cleaning tools or free games in app stores) that can modify the code of another app. Usually, banking apps are one of the scenarios to target, and Mobile ZeuS or Trojan-Spy can be used to steal mobile TAN code. |
In my opinion, this is a list of the most important vulnerability types. However, OWASP provides a list of 10, and it also provides standards and testing guides. We will cover these in the next section.
OWASP Mobile Application Security Fundamentals
OWASP mobile application security fundamentals consist of several sources and contain OWASP Mobile AppSecurity Verification Standard (MASVS), OWASP Mobile Application Security Testing Guide (MASTG), and the Mobile Security Checklist. Below in Figure 1, you will see the fundamentals of mobile application security in detail:
Figure 1: OWASP mobile app security fundamentals
Let’s have a more detailed look at the mobile app checklist.
Mobile Application Security Checklist
The Mobile Application Security Checklist is a part of the MASTG. It is a set of rules/checks that a dev team should include when securing a mobile app. It contains more than 100 rows and is organized by the following categories:
- Architecture, Design, and Threat Modeling Requirements
- Data Storage and Privacy Requirements
- Cryptography Requirements
- Authentication and Session Management Requirements
- Network Communication Requirements
- Platform Interaction Requirements
- Code Quality and Build Setting Requirements
- Resilience Requirements
Each rule (or check) has an identification code and description. All rules have priority marks. “L1” or “L2” means that the application should have the rule/check implemented. “R” means that it is required, so the team must implement everything marked “R.” Download the full example on OWASP’s website.
Next, let’s focus on guidelines for specific platforms, with attention to the most popular ones: iOS and Android.
Secure Mobile Apps in iOS and Android: Guidelines
As we have already partially touched some iOS security APIs, we will continue discussing it with the addition of Android. In the first section below, I’ve gathered guidelines and best practices about iOS API security features.
Apple App Sandbox, Data Protection API, and Keychain
The Apple App Sandbox provides an API to isolate an app and prevent access to the main system or other apps. It’s based on UNIX’s user permission and ensures that apps get executed with a less privileged “mobile” user. Also, it includes address space layout randomization (ASLR) and ARMs Never eXecute, which prevent memory-related security bugs and stops malicious code from being executed.
The Data Protection API allows an app to encrypt and decrypt its files, and it may solve several security issues like authentication and reverse engineering. Each file has four available protection levels, and by default, it’s encrypted with the first user authentication. However, we should increase the level to provide the highest protection.
Last but not least, the keychain. It provides secured hardware-accelerated data storage. iOS provides this API to store certificates and passwords with the highest level of security. For each item in the keychain, we can define specific access policies. Especially when the user needs to request Face ID or Touch ID, the biometric enrollments won’t change since the item was added to the keychain.
Figure 2: Keychain API
Android-Encrypted Key-Value Storage, File Encryption, and Cryptographic APIs
Same as iOS, Android also has many similar features to store data securely. The first one is key-value storage. It allows storing data using SharedPreferences to set a scope of visibility for items in the storage. We need to keep in mind that stored values are not encrypted by default. Therefore, malware may have access to the data.
If we need to encrypt data manually, we benefit from using Cryptographic API. We can generate a secure key with KeyGenerator, then save and extract the encrypted value to Android Keystore. To work securely with files and external storage, Android has the Cryptography Support Library. It supports a lot of cryptography algorithms to encrypt/decrypt files.
HTTPS, SSL Pinning, and Push Notifications
A secured communication layer is the next big milestone to a secured app. First, we need to ensure that we are using HTTPS. iOS has a feature called App Transport Security (ATS) that blocks insecure connections by default, so all connections must use HTTPS/TLS. In addition, the SSL pinning feature helps to prevent man-in-the-middle attacks. It will validate the system certificate if it were signed by a root certificate authority.
To use this feature, the app should run additional trust validation of server certificates. Push notifications are another part that should be secured. We should use Apple’s Push Notification service (APNs) and the UNNotificationServiceExtension extension . This will allow us to use placeholders for sensitive mobile app data and send encrypted messages.
Also, consider using Apple’s CryptoKit. It is a new API introduced in iOS 13 that provides the following features:
- Hashing data
- Authenticating data using message authentication codes
- Performing key agreement
- Creating and verifying signatures
Android has similar options. It allows only HTTPS to transport encrypted data with TLS. And it is the same story for SSL pinning. To prevent man-in-the-middle attacks, we can perform additional trust validations of the server certificates.
Secure Mobile Apps in Azure and AWS
To build secure applications, Azure has services such as the Azure App Center. It allows for the building and distribution of mobile apps and provides a lot of security options:
- Data transit encryption – support HTTPS using TLS 1.2 by default; also encrypted at rest
- Code security – provides multiple tools to analyze code dependency to detect security vulnerabilities
- Authentication – contains features like Microsoft Authentication Library (MSAL), which supports multiple authorization grants and associated token flows
Alongside Azure, AWS has some powerful services to consider when building a secure mobile app. Take AWS Cognito as an example. It is a user-state service with options to develop unique identities for users. It supports:
- Secure app authentication
- Enabling developers to include user sign-up
- Easy sign-in and access control focused on web and mobile apps
AWS has one unique service with the name AWS Device Farm. It provides not only automated testing and simulation environments, but also contains features to validate app dependencies and run security checks. Now let’s move on to an example of building a DevOps process with security features.
An Example of DevSecOps for Mobile Applications
In this section, I’ve created an example of a DevSecOps scenario to deliver secure mobile applications (see Figure 3). This process can be reused within the most popular CI/CD platforms and cloud providers:
- Git operation steps – Contains standard commit/push operations when the source control triggers a build.
- Run static analyses and code linting steps – Validates the code styles, usability, data flow issues, and security issues (e.g., Xcode Static Analyzer).
- Dependency validation step – Provides excessive validation checks through the library tree used in the app. This validation step may reveal a fake, malicious library that can manipulate code or even steal personal user data.
- Application log validation step – Checks if logs contain sensitive data like environment passwords, test tokens, or authorization data. After the dev/test process, the application package may contain some sensitive data as developers may not notice it after debugging the app. (This step can be run after deployment to the dev/test environment as well).
- QA steps:
– Deploy the app to the dev/test environment for the QA team to test.
– Promote and deploy the app to the marketplace validation.
Figure 3: Common DevSecOps process of a secure mobile app
Conclusion
In this article, I’ve provided a short guide on secure mobile applications. We discovered that the OWASP community has major security fundamentals, and OWASP can be used as a strong base for building a new app or refactoring an existing one. Knowing cloud services and examples of DevSecOps allows us to start building secure mobile apps with minimum effort and makes it harder for an attacker to compromise our app. Also, we went through iOS and Android security features, security APIs, and discovered how to use them properly.
This is an article from DZone’s 2022 Enterprise Application Security Trend Report.
For more:
