The vulnerabilities related to mobile apps have also grown as a result of the exponential rise in usage of mobile applications and the comfort and ease of use that customers find for various activities. One such list that emphasises the security issues & vulnerabilities developers need to guard their applications against is the owasp top 10 Mobile
Why Secure Mobile Apps?
The mobile security firm NowSecure examined 250 popular Android apps in November 2019 and discovered that 70% of them exposed sensitive user information.
To offer a personalised user experience, almost all modern apps use and store user credentials, financial information, and personally identifiable information. Developers must have a thorough awareness of the most important current and emerging security dangers due to the emergence of complex security threats. The OWASP Mobile Top 10 list turns into a crucial resource for security experts at this point.
What is OWASP?
The Open Web Application Security Project (OWASP), a group of developers that was established in 2001, develops methodology, documentation, tools, and technologies related to the security of web and mobile applications. Its Top 10 risk lists are regularly updated publications designed to educate the developer community about new security concerns to web and mobile applications. You can view OWASP’s complete list of projects.
What is OWASP Mobile Top 10?
OWASP Mobile Top 10 is a ranking of the top 10 security threats that mobile apps worldwide must contend with. Developers can use this list, which was last updated in 2016, as a reference while creating safe applications and using excellent coding practices. Since over 85% of the apps NowSecure examined were determined to be afflicted by at least one of the OWASP Top 10 threats, developers must comprehend each one of them and use coding techniques that minimise their occurrence as much as possible.
The top 10 hazards for OWASP Mobile are mentioned here, numbered from M1 to M10.
M1: Improper Platform Usage
This risk includes the improper use of platform security settings or the abuse of an operating system feature. This could involve Keychain access, Android intents, platform permissions, or other platform-integrated security measures. It frequently occurs, is only moderately detectable, and has the potential to hurt the apps that are affected.
Improper Platform Usage Risk
- Android Intent Sniffing
- iOS Keychain Risk
- iOS TouchID Risk
Best Practices to Avoid Improper Platform Usage
- iOS Keychain Best Practices
- iOS Android Intent Best Practices
- Android Intent Sniffing Best Practices
M2: Insecure Data Storage
M2 exploitability is rated as “easy,” prevalence as “common,” detectability as “average,” and effect as “severe” by OWASP.The developer community is made aware of the ease with which an adversary might access unprotected data on a mobile device thanks to this risk in the OWASP list. An opponent can access a stolen smartphone either physically or through malware or a repackaged app.
When a device is physically accessible, its file system can be accessed by connecting it to a computer. The adversary can access third-party programme directories and the personally identifiable information they contain using a variety of freely available applications.
Insecure Data Storage Risks
- Compromised file system
- The Exploitation of Unsecured Data
Best Practices to Avoid Improper Platform Usage
- iGoat iOS
- Android Debug Bridge
M3: Insecure Communication
A telecom carrier and/or the internet are typically used for data transmission to and from a mobile app. Hackers can access the network via routers, cellular towers, proxy servers, or malware by tapping into the local area network of users through a hacked Wi-Fi network, acting as an adversary sitting in the network, or tapping into the network through the compromised app.
Insecure Communication Risks
- Stealing Information
- Man in The Middle (MITM) Attacks
- Admin Account Compromise
Techniques to Prevent Unsafe Communication
To address insecure communication, developers should use the OWASP recommendations listed below:
- Assume that eavesdropping is possible and that the network layer is insecure.
- Keep an eye out for leaks in the traffic that is transmitted between an app and the server. Check the app’s holding device as well as any additional local devices or local networks, including wired ones.
M4: Insecure Authentication
When a mobile device incorrectly recognises a user, it permits an adversary to log into the app using default credentials. This usually occurs when an attacker impersonates or gets around authentication protocols that are either absent or poorly designed and communicates directly with the server using either malware that resides on the mobile device or botnets, preventing direct communication with the app.
Insecure Authentication Risks
- Input Form Factor
- Insecure User Credentials
Tips for Preventing Insecure Authentication
To find out if the app’s authentication process might be possibly attacked, carefully examine it and test it using binary attacks while offline. The security team should investigate whether the app permits the execution of a POST/GET command to connect to the server without using an access token. A successful connection reveals the app’s flaws. Passwords and security keys shouldn’t be kept locally on the mobile device, according to the developer. Such information is quite vulnerable to manipulation.
- To protect the mobile app from insecure authentication, the security team should aim to incorporate as many of the following strategies as possible:
- The online app’s security mechanisms should be as comprehensive and use the same authentication techniques as those of the mobile app.
M5: Insufficient Cryptography
Due to ineffective encryption/decryption techniques or flaws in the algorithms that initiate encryption/decryption techniques, data in mobile apps become susceptible. Hackers have several ways to obtain encrypted data, including direct access to the mobile device, network traffic eavesdropping, and malicious programmes installed on the device. Its goal is to either decrypt data to its original form so that it may be stolen or encrypt it using an adversarial approach so that the legitimate user cannot use it.
Lack of Cryptography Risks
- Stealing App and User Data
- Access Encrypted Files
Guidelines to Follow to Prevent Insufficient Cryptography
- Apps should be encrypted using current encryption techniques. This issue is largely addressed by the algorithm chosen, as the security community routinely tests an encryption algorithm from a reputable source.
- Periodically, the US government’s National Institute of Standards and Technology publishes cryptography standards and suggests encryption techniques. This document should be closely monitored by the developer to spot any new threats.
M6: Insecure Authorization
Since both risks include user credentials, many individuals mistakenly believe that the M4 risk is the same as the M6 risk. Developers should remember that, in contrast to insecure authentication, which involves the adversary attempting to log in as an anonymous user, insecure authorization involves the adversary taking advantage of flaws in the authorization process to log in as a legitimate user.
Insecure Authorization Risks
- Unregulated Access to Admin Endpoints
- IDOR Access
Guidelines to Follow to Prevent Insecure Authorization
- Run critical commands that are restricted for high-privilege users using low-privilege session tokens to continuously test user privileges. If commands can be successfully executed, check the app’s authorisation system right away.
- Developers should be aware that in offline mode, the user authorization technique frequently fails. Developers occasionally permit user rights and roles to be communicated to the server, albeit this can potentially lead to vulnerabilities in the authorization scheme.
M7: Poor Code Quality
Poor or inconsistent coding practices—where each member of the development team uses a different coding technique and introduces inconsistencies in the finished code or leaves insufficient documentation for others to follow—are a source of risk. The good news for developers in this situation is that although this risk is prevalent, it is difficult to detect. Hackers frequently need to conduct manual analyses, which are difficult to execute, in order to identify the patterns of bad coding. Fuzz testing is a technique used to find memory leaks or buffer overflows using automatic tools. These tools can help with information access but do not make it simple to run foreign code on a mobile device.
Poor Code Quality Risks
- Safe Web Code, Compromised in Mobiles
- Lacunae in Third-Party Libraries
- Client Input Insecurity
Methods to Prevent Bad Mobile-Specific Code Quality
- Static Evaluation: To find memory leaks and buffer overflows, the developer should often employ external tools for static analysis. The development team should make an effort to eliminate the discrepancy between the length of the target buffer and the entering buffer data.
- Logic Code: Simple logic is considered to be a hacker favourite on both iOS and Android devices, so the developer should avoid using it in their applications. Hackers can disable the entire security system by changing a value in the code using basic logic. Such routines are susceptible to attack at the runtime and assembly levels. By preventing untrusted sessions from activating rights at the device level and switching them to the server, the developer might block this leakage. It is also advised to defer granting access until a session has been authenticated by OTP, challenges, or secret questions.
M8: Code Tampering
Hackers prefer manipulating app code to other methods since it gives them unrestricted access to the app, user behaviour, or even the entire mobile device. Through phishing attempts and deceptive marketing, they frequently persuade users to download modified versions of popular programmes from third-party app stores.
Risks of Code Tampering
- Malware Infusion
- Data Theft
Best Practises to Prevent Runtime
- Detection of Code Tampering: The programme should be able to recognise code changes at runtime, according to the creator. It is advisable to notify the server of this compromise during runtime if a compromised programme wants to operate on a jailbroken or rooted device but the developer does not want to permit this form of execution. One such tool that programmers can use to quickly identify and prevent attack vectors is RASP.
- Changes in Checksum: Checksums and digital signature analysis should be used by the developer to determine whether file tampering has occurred. The checksum value is the simplest technique to identify adversary action because tampering with code and files almost always alters it.
M9: Reverse Engineering
Mobile code engineering is a frequently exploited phenomenon. To analyse the code patterns of the original programme and its connections to server processes, hackers frequently employ external, widely accessible binary inspection tools like IDA Pro, Hopper, otool, etc.
Risks of Reverse Engineering
- Runtime Dynamic Inspection
- Coding Thievery
- Premium features
Guidelines to Prevent Reverse Engineering
- Use comparable tools: Using the same tools that hackers use to do reverse engineering is the greatest approach to protect an app from it. To identify efforts at reverse engineering in real-time, developers can also use a tool called AppSealing.
- Coding Obscurity: Targeting particular sections of the source code, string tables, and techniques with the least negative effects on code performance should all be part of the obfuscation process. With de-obfuscation tools like IDA Pro and Hopper, the developer should make sure that the level of obfuscation they use cannot be easily reversed.
M10: Extraneous Functionality
The development team frequently stores code in an app before it is ready for production so that it can easily contact the backend server, generate logs to analyse failures, or store staging and testing information. When the app is in production, the intended user will not utilise this code, which is necessary for the app to function.
Risks of Extraneous Functionality
Most of the time, an adversary who gains access is not given any additional benefits by a benign code. But in some circumstances, this code may contain data about databases, user information, user rights, API endpoints, etc., or it may disable features like two-factor authentication.
Guidelines for Preventing Extraneous Functionality
The developer should be aware that automated technologies can fail to identify the M10 danger. The majority of the time, manual intervention is necessary before the app is uploaded to app stores. Before the programme is made available, the developer needs to execute the following actions:
- Ensure that the final build contains no test code;
- Verify that the configuration settings don’t contain any hidden switches;
- No descriptions of backend server processes, administrative rights, etc., should be found in logs;
- Logs shouldn’t typically be too descriptive; Make sure OEMs don’t let apps access complete system logs.
Appsealing is a thorough security solution for iOS and Android mobile apps that can shield them from the majority of OWASP Mobile’s Top 10 threats. By implementing the AppSealing security layer on top of the binaries, the developer may rapidly and easily secure applications in a solid manner without writing any code. Businesses may analyse potential risks and hostile efforts on their apps in real-time with the help of an easy-to-use dashboard.
Add that extra security layer to your mobile apps right away, with 600+ mobile apps already successfully protected by AppSealing!
