In our previous blog https://blog.nashtechglobal.com/security-in-mobile-application/, we already discussed how we chose the right approach to implement the security requirements in mobile applications with OWASP MASVS. To apply all requirements from OWASP MASVS is time consuming job, but it will help us to maximum the power of the app to protect users from vulnerabilities.
OVERVIEW
If we need to select high priority items to implement, what should we start? Let’s discuss it on this blog which tips should be taken care of. The most of vulnerabilities related to:
INSECURE STORAGE: the usage of insecure storage will cause the app to be stolen the data from hackers. By default, storages in the mobile could be categorized into the public and private storage, the public storage will be shared with other applications, and the private storage will be only accessed by the app. But using private storage does not prevent the app 100% from being stolen, the developer should be aware of purpose of each storage and how to protect data in these storages.
WEAK CRYPTOGRAPHIC USAGE: though we already apply cryptographic functions to encrypt sensitive data in storage or via network communication but reply on weak encryption methods will also open a door for attackers to decrypt them when they steal your data.
WEAK AUTHENTICATION AND AUTHORIZATION MECHANISMS: when developing mobile apps we may implement local authentication, remote authentication and also authorization mechanisms to provide user access services in the app with assigned permissions. If we don’t have the right approach to implement these mechanisms, the app may be bypassed by hidden users, they then access services we don’t intent to provide with their default permissions.
INSECURE NETWORK COMMUNICATION between the mobile app and remote endpoints, Nowadays most networking libraries provide us networking APIs using the https enabled by default, but this is not enough to protect our app data from compromised. The attackers may apply a technique called the man in the middle attack to listen our app data transmission, so that we should add more layer communication channels to secure our application data.
MISSING OR INSECURE CONFIGURATION SETTINGS may result in unexpected behavior when communicate with platform APIs or exposed to other applications in the same device.
MISTAKES FROM DEVELOPERS when they develop the app such as the application logs exposed to outside, these logs may contain sensitive information or debugging steps that the attacker can use to understand sensitive application flow such as payment flow with payload is exposed.
MISSING DEFENDS FROM REVERSE ENGINEERING TOOLS OR HOOKING SERVICES which attackers usually use to compromise the app. Especially on rooted or jailbreak devices, they can change the app logic and repackage to tampered or fake version of our app.
Above are high level of type of the most vulnerabilities, now let’s zoom tips we can apply to improve the application security:
1. Using System credential storage to store sensitive data or cryptographic keys
This means that sensitive data, such as user passwords and credit card numbers, etc.., should not be stored in the app’s memory or on the device’s file system. Instead, it should be stored in a secure system credential storage facility, such as the Keystore or Keychain. This will help to protect this data from unauthorized access, even if the device is lost or stolen.
Sensitive data must be stored in secure system storage, such as the Keychain on iOS and the Key Store on Android.
In general, sensitive data stored locally on the device should always be encrypted, and any keys used for encryption methods should be securely stored within the Android Keystore or iOS Keychain.
Plain sensitive data should NOT be stored in common databases below:
- Android share-preference, iOS NSUserDefault.
- Plain text in CoreData (CoreData does not encrypt it’s data by default).
- Plain text in SQLite Databases.
- Plain text in Firebase Databases. (Hackers can obtain this data if it is misconfigured)
- Plain text in Internal Storage.
- External Storage.
2. Sensitive transactions require step-up authentication
Sensitive transactions in mobile applications should be required to step-up authentication. Step-up authentication is a security measure that requires users to provide additional authentication factors to access sensitive information or perform high-risk transactions.
In mobile applications, sensitive transactions might include operations such as making a financial transaction, changing account settings, or accessing personal information. By implementing step-up authentication for these sensitive transactions, mobile app developers can reduce the risk of unauthorized access, account takeover, and financial fraud.
The development team needs to identify the transactions in their mobile application that require step-up authentication. These transactions should be evaluated based on their risk level and the potential impact of unauthorized access.
3. Use strong implementations of cryptographic functions
When an app uses cryptographic primitives, it means that it is implementing a set of fundamental cryptographic functions or operations that are essential for secure communication, such as encryption, decryption, hashing, and digital signature generation and verification.
Proven implementations of cryptographic primitives means that the cryptographic algorithms and protocols used in the app have been tested and reviewed by experts in the field of cryptography and have been shown to be secure and effective. These implementations have undergone rigorous testing and scrutiny to ensure they are resistant to attacks and provide strong security guarantees.
Should use official cryptography libraries provided by Apple for iOS and Google for Android. The app must ensure that the security of the app is based on strong, well-established crypto methods that will be recommended by OWASP such as AES-GCM-256, SHA-256.
4. Encrypt data on the network using TLS. The secure channel is used consistently throughout the app
Data is a crucial resource of any organization, and if it is lost, compromised, or stolen, the effect on a business can be devastating. So, you must protect data at rest or in transit from unauthorized access.
Data that is moving from one place to another, such as when it is transmitted over the internet, is referred to as data in transit or data in motion. Encryption method such as SSL/TLS are often used to protect data in transit.
Make sure that sensitive information is sent over secure channels by using HttpsURLConnection or SSLSocket (for socket-level communication using TLS).
Be aware connections have to be securely implemented. For instance, SSLSocket doesn’t verify the hostname. Use getDefaultHostnameVerifier to verify the hostname.
Ensure that the app does not allow cleartext HTTP traffic.
Make sure all requests are made via HTTPS instead of HTTP.
5. The app only requests the minimum set of permissions necessary
The objective of this tip is to ensure that the mobile application requests and uses only the minimum set of permissions necessary to perform its intended functions. This reduces the attack surface of the application, limiting the potential impact of any security vulnerabilities or attacks that may be present.
The guideline provides recommendations for implementing the principle of least privilege, such as auditing the application’s permission usage, minimizing the number of permissions requested, and providing clear explanations to users regarding why specific permissions are required.
6. Pay attention of application logs for debugging code and developer assistance code (e.g., test code, backdoors, hidden settings) have been removed
Developers often include debugging code, such as verbose logging statements (using NSLog, println, print, dump, and debugPrint) about responses from their APIs and about their application’s progress and/or state. Furthermore, there may be debugging code for “management-functionality”, which is used by developers to set the application’s state or mock responses from an API. Reverse engineers can easily use this information to track what’s happening with the application.
7. Detects and responds to rooted or jailbroken devices
The mobile application should detect the presence of a rooted or jailbroken device and respond to it appropriately. This is important because rooted or jailbroken devices can pose a significant security risk, as they can potentially bypass or disable the security mechanisms implemented by the mobile application.
Appropriate techniques are applied to detect whether the device has been rooted or jailbroken. This may include checking for the presence of root or jailbreak-related files, monitoring system calls or processes, or using third-party detection tools.
If a rooted or jailbroken device is detected, the mobile application should respond by alerting the user and potentially terminating the app. This can help to prevent the application from being used to compromise sensitive data or perform unauthorized actions.
CONCLUSION
There are many more requirements for security that should be taken when dealing with security in mobile applications, I hope that tips above will give you a first look for what should we care about when working on sensitive mobile applications. In our company we have a guideline document which includes these tips and much more to support client in protect their applications from vulnerabilities. Let’s safe your application to protect your users.