Some might not be aware of what the OWASP Foundation is. The Open Web Application Security Project (OWASP) is a non-profit, international, community-led, open-source software project with tens of thousands of members working to improve software security. It acts as a source for developers and technologists to secure web and mobile applications.
What is OWASP Mobile Top 10?
The OWASP Mobile Security Project is a centralized resource that intends to provide developers and security teams the resources they require to build and maintain secure mobile applications. This project aims to identify and classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
The OWASP Mobile Top 10 is a part of the OWASP Mobile Security Project. OWASP Mobile Top 10 is a list that identifies the various types of security risks faced by mobile applications. It acts as a guide for developers to incorporate best coding practices while securing and building applications. Each of the OWASP Mobile Top 10 consists of:
Exploitability: Easy
Prevalence: Common
Detectability: Average
Technical Impact: Severe
1: IMPROPER PLATFORM USAGE
This has been ranked as the most prevalent mobile security vulnerability by OWASP Mobile Top 10 2016 list. This threat arises when iOS or Android platforms are not created per the developmental guidelines provided for security purposes. The applications available on the App Store or Play Store unexpectedly defy the developmental guidelines, implementation process, or best practices, resulting in improper platform usage.
This threat refers to the misuse or improper use of any platform feature or security control of iOS and Android mobile operating systems, like requesting surplus or incorrect platform permissions; misuse of the touch ID, which leads to unauthorized access of the device; or a public Android intent may reveal some critical sensitive information, or even permitting unauthorized execution.
A few steps to mitigate improper platform usage are:
- Only the whitelisted traffic should be allowed to take the permissions so that application communications are restricted.
- Encrypted keys should be kept in the mobile device only instead of encrypting server routes for iOS Keychain.
- Explicit intents should be defined with well-defined intent objects to block other components’ access to the intent information.
- User authentication policy of the access control list must be enforced to store the Keychain application secret.
Get Started With The "OWASP Top 10" Course Now >>
2: INSECURITIES- DATA STORAGE
In case our mobile device is lost or stolen, the attacker mustn't leak our personal information or gain access to any sensitive data stored on the mobile, even after exploiting vulnerabilities or using malware.
Though it is not practical for apps to store all the data on the mobile, it is crucial that, if the data is being stored, it should be secure and shouldn’t be accessible to anyone or any other app. Attackers tend to root or jailbreak the device to bypass the encryption protection and might even gain access to the filesystem. So, developers must secure the data to the highest degree possible.
A few steps to mitigate insecure data storage are:
- Developers must use android Debug Bridge to check file permissions, database management, and error logs of the application to check whether security information is not being leaked.
- Android Device Monitor and Memory Analysis Tool must be used to make sure only intended data is being stored in the device’s memory for a specified duration such that an attacker cannot exploit it.
- iOS developers should use iGoat (vulnerable mobile application) by OWASP to model their applications and development frameworks. Developers will also benefit by understanding in detail how APIs deal with application processes and information assets.
3: INSECURITIES- COMMUNICATION
Insecure communication refers to unencrypted plaintext data traveling within a network as it can be easily captured and read by an attacker who monitors the network.
Since mobile apps communicate by exchanging data using a client-server model from the device to the carrier network through the internet, the communication needs to be secure. The traffic must not be easily intercepted by proxies or attackers who misuse the transferred data.
A few steps to mitigate insecure communication are:
- Strong cipher suites must be used, and only certificates signed by a trusted CA provider must be accepted.
- The mobile app should use SSL/TLS to transmit sensitive data to the backend API.
- SSL sessions should not be mixed because they may reveal the user’s session id.
- An additional layer of encryption must be applied to sensitive data, and it should only be transmitted through SSL.
4: INSECURITIES- AUTHENTICATION
Authentication means that the user’s identity should be verified. In this case, authentication refers to mobile apps verifying the user’s identity before being granted access. They should maintain a record of the user’s identity during the transfer of critical data. When the authentication is insecure, attackers perform an authentication bypass by leveraging existing vulnerabilities.
Some steps to mitigate insecure authentication are:
- Ensuring periodic authentication of user credentials and logout from the server side.
- App data should only be loaded after user authentication is complete, and it shouldn’t be stored locally.
- Users must be required to use an alphanumeric password, and at least two-factor authentication must be enabled.
- If app data is stored locally, it must be encrypted with a key made from the user’s login credentials.
5: INSUFFICIENT CRYPTOGRAPHY
Insufficient cryptography is when the mobile’s cryptography reveals sensitive data about the algorithm being used for encryption and decryption, or the cryptographic process is revealed, exposing implementation flaws. The disclosure of such critical information assists the attacker in bypassing the encryption algorithm if it is weak, using deprecated encryption protocols for malicious purposes, or mishandling the user’s digital keys.
A couple of steps to mitigate insufficient cryptography are:
- The latest encryption algorithm must be used to encrypt applications, making them less vulnerable to threats.
- Developers must consider emerging threats and recommended encryption algorithms published by NIST(National Institute of Standards and Technology) before choosing an encryption algorithm.
6: INSECURITIES- AUTHORIZATION
Generally, there are two types of users: normal and admin. Normal users have regular permissions and privileges, whereas admin users require elevated permission and privileges. Insecure authorization refers to the failure in verifying the user’s identity and failure in enforcing identity-related permissions. Suppose the mobile device cannot verify the type of user asking for resource access or permission. In that case, attackers may use this to their advantage by logging in as a legitimate user and performing privilege escalation attacks.
A few steps to mitigate insecure authorization are:
- Proper authorization checks for user permissions and roles must be done at the server since hackers prefer exploiting legitimate backend users because of their higher privileges.
- User authentication schemes, permissions, and roles should not be sent to the server as it might give rise to an exploitable vulnerability.
- The authorization scheme of the app must be thoroughly examined, i.e., low privilege session tokens must not be able to execute sensitive commands.
7: CLIENT CODE QUALITY
Mostly, mobile client issues are caused by faulty code implementations. This faulty code needs to be fixed locally as it is generated on the client and is distinct from server-side coding errors. Compromised quality of the client code may enable an attacker to permit malicious inputs to the app function calls to execute and analyze the app’s behavior to them. These inputs enable the attacker to perform remote code execution and buffer overflow on the app.
Several steps to mitigate client code quality are:
- Developers must enforce privileges for untrusted sessions at the device level instead of the server and shouldn’t grant privileges until the session is authenticated.
- Poor code issues on the mobile side must be solved by rewriting the code.
- Developers must use libraries from trusted sources only and periodically check for the newer versions of the libraries incorporated in the app.
- Developers might use third-party tools for static analysis to find out any buffer overflows or memory leaks.
- Developers must stop all unauthorized access by setting up permission flags and also validate all the inputs coming into the app.
8: CODE CORRUPTION
Sometimes the App Store and Play Store contain tampered versions of mobile apps, which the attacker uses to their advantage. Tampered apps may have modified the app’s binary data to incorporate a backdoor or malicious content. Attackers can also re-sign these fake apps, making them look authentic, publishing them on third-party app stores, or manipulating the user to download the app through a phishing attack.
Some steps to mitigate code tampering are:
- Evaluation of digital signatures and checksums must be done to check the code or application files for tampering.
- On detecting tampering, the app data, keys, and code must be automatically erased.
- Developers must use RASP (Runtime Application Self-Protection) for detecting and deterring any attack vectors in real-time. An app must be able to detect code changes at runtime.
9: REVERSE ENGINEERING
The attacker uses reverse engineering to decompile the app, perform code analysis, and modify it using binary inspection tools. Once an attacker understands the code, it is easy for him/her to incorporate malicious functionality into the code. The attacker generally uses tools like Hopper and IDA Pro. When the app starts to function in the desired way, the attacker recompiles, and tests the app.
A few steps to mitigate reverse engineering are:
- Developers must use languages like C and C++ as they offer runtime code manipulation and protect from reverse engineering tools. Objective C may be used to integrate them.
- Developers must perform obfuscation on specific parts of the source code which have the least code performance. Code obfuscation will be useful only if it is not easily reversed by a deobfuscation tool.
- Developers must use tools like AppSealing to detect reverse engineering attempts on the app in real-time.
10: EXTRANEOUS FUNCTIONALITY
The developers’ team often codes the app so that they have access to a backend server, creating logs for error finding, or carrying staging and testing details, which sometimes act as backdoors for the attackers. This is an extraneous functionality, as this is useful only during the development of the application and not during production.
Attackers use these extraneous functionalities to their advantage by exploiting them directly since they don’t even require user participation. All the attackers need to do now to implement an attack is thoroughly examine the configuration files and working of the app’s backend system.
A few steps to mitigate extraneous functionality are:
- App logs must not be descriptive, and full system logs must not be exposed.
- The app should consist of well-documented API endpoint access.
- Developers must ensure that test code and hidden switches are not present in the final build.
OWASP Top 10 for Mobile is a course specifically designed to strengthen the basics of OWASP Mobile top 10 for a beginner. Mobile Security Fundamentals will be a great start for beginners to strengthen their mobile security concepts. Combine it with Mobile App Security Training to know more about Mobile App Security best practices because they are essential nowadays.
REFERENCES
https://owasp.org/www-project-mobile-security/ (Image 1) https://www.appsealing.com/owasp-mobile-top-10-a-comprehensive-guide-for-mobile-developers-to-counter-risks/ (Image 2) https://sectigostore.com/blog/owasp-mobile-top-10/
