It’s not surprising to find that mobile device attacks are on the rise given that 45% of the world’s population owns a smartphone.
As mobile apps have grown in popularity and consumers have found ways to use them more conveniently and easily, some of their vulnerabilities have also increased. The OWASP Mobile Top 10 lists the security flaws and vulnerabilities developers should be aware of when developing mobile applications.
Why Secure Mobile Apps?
Despite being supported by established global brands, mobile devices and applications seem secure at first glance. Real-life, however, offers little assurance.
It was revealed by NowSecure that about 70% of popular Android apps exposed personal data in November 2019.
Identity thefts in the United States accounted for nearly 14.4 million incidents in the 2019 Javelin Strategy & Research Identity Fraud Study. Mobile phone accounts were compromised in many of these thefts.
To provide a personalized user experience, most contemporary apps monitor and store user credentials, bank details, and otherwise identifiable information. Developers must be familiar with top emerging and existing security threats, thanks to the advent of complex security threats. For security professionals, the OWASP Mobile Top 10 list becomes indispensable.
What is OWASP?
With 30 years of experience developing methodologies, documentation, tools, and technologies for web and mobile applications, the Open Web Application Security Project (OWASP) was founded in 2001. There are Top 10 lists of threats on its website which are constantly updated to create awareness within the developer community of emerging security threats. This page lists all of OWASP’s projects.
What is OWASP Mobile Top 10?
The OWASP Top 10 Mobile App Security Risks is a global list of security threats faced by mobile applications. A list of best coding practices and secure development guidelines from 2016, serves as an active guide for developers. The OWASP Top 10 risks have been found to affect almost 85 percent of NowSecure’s tested apps, thus making it essential that developers have a thorough knowledge of all of them and adopt the coding practices to nullify their occurrence as much as possible.
The following table presents the top 10 mobile security risks for OWASP Mobile, listed from M1 to M10.
M1: Improper Platform Usage
This risk covers the misuse of an operating system feature or a failure to use platform security controls properly. This may include Android intents, platform permissions, the Keychain, or other security controls that are part of the platform. Its occurrence is common, with average detectability, and can cause a severe impact on the affected apps.
Improper Platform Usage Risks
Data Leakage by Exploiting Android Intent
Intents provide a way for Android activities to communicate through messages. Many of these actions occur in the background while the mobile device or another application is running, such as talking to background services, accessing the mobile device’s storage space or another app’s web server, or opening an activity such as a browser or another application. Aside from the endless possibilities for intent usage, the likelihood of data loss during message exchange becomes high as well.
Android Intent Sniffing
Android apps are often designed to steal information primarily from intents. In transit between legitimate apps and other Android components, these apps can search for URL patterns or user information.
iOS Keychain Risk
Mobile users can create difficult-to-remember passwords, which are more difficult to crack, through the Keychain, which makes third-party accounts – such as bank and email accounts – accessible via mobile devices more secure. Keychain encryption comes standard with iOS so that developers don’t have to implement their own encryption methods. Developers can opt to encrypt or not encrypt data via access control lists and Keychain access groups. Users may intuitively select easy-to-remember passwords if they do not opt for the Keychain method, which could be exploited by hackers.
iOS TouchID Risk
Mobile app developers can authenticate their apps using TouchID on iOS. Hackers can gain access to personal information when the TouchID option is bypassed.
Best Practices to Avoid Improper Platform Usage
iOS Keychain Best Practices
Keep the encrypted keys on one device only, rather than allowing encryption of your Keychain through the server, so that it cannot be exploited in other devices or the server.
Make sure the app’s secret and access control list are stored in the Keychain. User authentication policies are enforced by the OS for access control lists.
iOS Android Intent Best Practices
By enforcing permissions, apps can be restricted from communicating with their app – essentially blocking all requests from nonwhitelisted traffic. In addition, Android components that don’t need to communicate with the app can be prevented from being exported for the intent of either or all of activities, services, or broadcast receivers in the Android framework.
Android Intent Sniffing Best Practices
Explicit intents, where the object of the intent can clearly be defined, can be used to control leakage. This blocks every other component from accessing the intent’s contents. Be sure that all file permissions are set correctly before publishing your app.
M2: Insecure Data Storage
It specifies that M2 exploitability is “easy”, prevalence and detection, “common”, and Impact “severe”. This level of risk in the OWASP list informs developers about easy ways an attacker could access data on mobile devices. Physically stealing a device or using malware or repackaged apps are two ways in which an adversary can access it.
After attaching the device to a computer, the file system on the device can be accessed if it can be physically accessed. Access to specific directories of third-party applications and to personally identifiable information may be obtained by freely available software.
Insecure Data Storage Risks
Compromised File System
The loss of the personal information of the user is the obvious adverse effect of a compromised file system, but the owner of the app may stand to lose too if mobile malware, modified apps or forensic tools are used to browse the app’s sensitive data. Users could suffer identity theft, privacy violations, and fraud if their data is compromised, and companies could experience reputation damage, policy violations, and material losses if the data is compromised.
A compromised device is scanned for unsecured data in many places by an adversary. Databases, log files, XML data stores, binary data stores, cookie stores, and cloud-syncs may all be compromised, as well as operating systems, frameworks, compiler environments, new hardware, and jailbroken/rooted devices.
The exploitation of Unsecured Data
Because developers were not aware of how devices stored cache data, images, key presses, and buffers, unsecured data could be exploited. A lack of adequate technical documentation aids developers in ignoring the security processes of operating systems and development frameworks, facilitating the manipulation of data and processes within them.
Best Practices to Avoid Insecure Data Storage
iGoat iOS
Apple recommends that software developers test their apps and development frameworks by using malicious mobile apps such as iGoat, which has been specially designed to be a vulnerability on iOS.
In this process, API developers learn about how APIs handle data assets and application processes, this includes URL caching, key-press caching, buffer caching, Keychain usage, background applications, logging, data storage, browser cookie handling, server communication, and traffic sent to third parties.
Android Debug Bridge
Developers can check file permissions with Android Debug Bridge (ADB) shell, and check database encryption with a database management system, such as sqlite3. Developers can also use ADB’s logcat command to examine Android logs and error logs that leak sensitive information to malware. Though extensive error logs are often used to help developers, if they are left unattended, they can compromise an application or data. An Android developer should also use tools like Android Device Monitor and Memory Analysis Tool to ensure that there is no unintended data in the device’s memory for an unspecified period of time, which could be exploited by a hacker or someone with physical access to the device.
M3: Insecure Communication
Generally, data transmission for mobile apps is done via the internet or a telecom provider. Hackers can intercept data in a variety of ways including from local area networks of users through unencrypted Wi-Fi networks, from cellular towers and routers, and even from exploiting malicious mobile apps through malware.
Insecure Communication Risks
Stealing of Information
One of the easiest ways for an adversary to obtain personal information is to monitor traffic through compromised or unsecured Wi-Fi networks. In fact, OWASP requires developers to monitor TCP/IP, Wi-Fi, Bluetooth, SMS, Bluetooth LE, GSM, NFC, audio, infrared, 3G, and virtually all other outbound and inbound traffic to mobile devices.
Man in The Middle (MITM) Attacks
The vast majority of mobile developers are aware of SSL/TLS for authentication, but they do not properly verify these certificates, leaving attackers open to mounting man-in-the-middle (MITM) attacks. By using such attacks, an adversary is able to see and modify the traffic sent between an app and its server, as well as intercept session IDs. Testing servers do not have access to security certificates since they are domain-specific. On production servers, developers use self-signed certificates when testing code. Self-signed certificates are just as good as unencrypted or plaintext connections, which leaves a hole for MITM attacks. Attackers often profit from developers’ permissive hostname verifier option when they disallow self-signed certificates. By allowing all hostnames between the app server and a browser, attackers can use any certificate issued by a certificate authority to control the traffic between the server and the browser.
Admin Account Compromise
Rather than stealing user data, a MITM attack will allow for data theft of the admin account when the channel is not secure. In the worst-case scenario, all sensitive information on the website can be hacked. In addition to encryption keys and passwords, such an attack may impact or steal private user information, account numbers, session tokens, documents, and metadata.
Best Practices to Avoid Insecure Communication
In order to address insecure communication, developers should incorporate the following suggestions from OWASP:
• Let’s assume that the network layer isn’t secure and that eavesdropping can occur through it
• Keep an eye out for leaks in the communication between an app and a server. Check the app’s device as well as another local device or local network, including a wired network
• Use SSL/TLS to protect communication channels between the mobile app and the backend API or web service for the transmission of sensitive data
• When an application uses the browser/WebKit to run a routine, account for third-party analytics companies, social networks, etc. by using their SSL versions.
• Session IDs may be exposed if mixed SSL sessions are used
• Make use of robust cipher suites with long key lengths
• Trusted CAs should sign your certificates
• Verify the identity of the endpoint server with trusted certificates in the key chain before establishing a secure connection
• The UI should alert users when the application detects an invalid certificate
• Sending sensitive data over alternate channels (e.g. SMS, MMS, or notifications) is not recommended.
• Any sensitive data should be encrypted separately before going through the SSL channel. It will serve as a secondary defense against disclosure of confidential information if future vulnerabilities are discovered in SSL implementation
M4: Insecure Authentication
An adversary is able to use default credentials when a mobile device cannot properly recognize the user. It is common that an attacker can interact directly with the server by way of malware that is on the device or through botnets, which do not directly connect to the app, in order to bypass authentication protocols that may be missing or poorly implemented.
Insecure Authentication Risks
Input Form Factor
Mobile platforms and app makers often promote four- or six-digit passwords that are easily accessible for ease of use as input form factors. Aside from the wireless input form factor, the lack of internet connectivity forces developers to rely on offline-online authentication for sessions on mobile devices.
Insecure User Credentials
Because insecure authentication results in apps being unable to determine a user’s credentials correctly, they cannot accurately record user activity. As a result of such misuse, the security team is unable to identify the attack source and nature. In addition, an insecure authentication will also cause the operating system to have difficulty assigning user permissions to an unauthorized user.
Best Practices to Avoid Insecure Authentication
To determine if an app can be potentially exploited, carefully examine the app’s authentication scheme and test it with binary attacks in offline mode. If the app permits POST/GET requests to be issued without an access token, the security team should investigate. The app becomes vulnerable when a connection is successful.
If the developer stores passwords or security keys on the mobile device, this should be avoided. The data can be easily manipulated.
As many of these methods as possible should be used to protect your mobile app from malicious authentication:
• In terms of complexity and authentication methods, the web app security protocols should match those of the mobile app;
• Just as in a web browser, use online authentication methods. In mobile devices, if ease of access is more important than security, guard against binary attacks, which are detailed in M10 risk;
• Authenticate the user session before allowing the server to load app data. It is possible to speed up the loading of an app by storing data locally, but the user’s security may be compromised;
• Should you wish to store any app data locally, you should encrypt it with a key derived from the user’s login details, forcing the app to verify its authenticity at least once;
• Server-side persistence should be employed for persistent authentication requests instead of local storage. Whenever the user opts in for the remember-me feature, be sure to caution them;
• In order to avoid vulnerabilities, the security team should avoid implementing tokens centric to devices in the app. If a new owner of a device changes the device access password, an app with a device-centric authorization token will be unable to be accessed.
• Mobile devices are commonly accessed through physical means; therefore, security teams need to enforce periodic authentication of credentials as well as periodic logouts from the server;
• Passwords should be assigned alphanumeric characters so that the user is forced to pick one. A simple letter combination is not as secure as these. Additionally, a developer can insist that the user identify an image or word before the app will be allowed access. Two-factor authentication is becoming increasingly popular.
M5: Insufficient Cryptography
Data security can be compromised by inadequacies in encryption/decryption processes or algorithms. Hackers can physically access the device, spy on its traffic, or use a malicious app to access encrypted data. Its goal is to exploit encryption flaws to create an adversarial process so that it can encrypt or decrypt data in order to steal it or render it useless to legitimate users.
Insufficient Cryptography Risks
Stealing App and User Data
Mobile apps on both Android and iOS are encrypted with trust certificates that are decrypted by users once they execute the app and verify the encryption signature. It is not a widely available method, even though many tools can bypass it. Using these tools, a jailbroken device can download an app, which can be decrypted, then a snapshot can be taken off the decrypted app and the original device can then execute it. After the app is executed in this compromised state, a hacker can better analyze it by conducting binary attacks or stealing data from its users. The default encryption process of the operating system will make developers susceptible to code manipulation.
Access Encrypted Files
Developers mishandle encryption keys, so adversaries can access encrypted files, even if they use the best possible algorithms. The developers of the application also tend to save keys alongside encrypted data. The keys are thus easier to access by hackers who can use them to decrypt information.
Best Practices to Avoid Insufficient Cryptography
• Encrypt apps using modern encryption algorithms. Since an encryption algorithm from a trusted source is typically tested frequently by the security community, this vulnerability is addressed to a large extent by the algorithm that is used
• Cryptographic standards and algorithms are recommended by the Federal government’s National Institute of Standards and Technology from time to time. Watch this document for emerging threats as a developer.
M6: Insecure Authorization
M4 and M6 risks share a common feature: both of them pertain to user credentials. When using insecure authorization, a hacker will take advantage of vulnerabilities in the authorization process to create a false user account, unlike when using insecure authentication, where a hacker tries to bypass the authentication process by using an anonymous user account.
Insecure Authorization Risks
Unregulated Access to Admin Endpoints
M6 requires an attacker to force-browse to a web server in order to gain access to a legitimate app so that it can execute administrative commands as a legitimate user. An attacker typically exploits authorization vulnerabilities by using malware on mobile devices or botnets. As a result of the security compromise, an attacker can use this device to carry out binary attacks.
IDOR Access
It is possible that an adversary can achieve access to an object, like databases or files, simply by providing user inputs. This process is known as insecure direct object references or IDOR. This can cause the operation of the whole system to become unstable or lead to the loss of data and reputation.
The Best Practices for Avoiding Insecure Authorization in Mobile Apps
• You should run low-privilege session tokens for commands that are reserved for high-privilege users as a means of constantly testing user privileges. Once commands have been successfully completed, verify the app’s authorization scheme
• As developers, it is crucial to remember that in offline mode, user authorization commonly goes awry. Developers, however, sometimes send permissions and roles to the server, which can also make the authorization scheme vulnerable.
• You should check a user’s roles and permissions on the server, not on the mobile device. When users are verified at the backend rather than within the mobile device, the chances of authentic users exploiting high-privilege functionalities are reduced.
M7: Poor Code Quality
Inconsistent coding practices, or poor coding practices, are a major source of the M7 risk, since each developer follows a different coding practice and reduces the quality of the final code, or does not provide enough documentation for others to follow. While this risk is common, its detectability is low, which is a saving grace for developers. Hackers often need to perform manual analysis in order to uncover patterns in poor coding, which is not straightforward for them. Automated tools, such as fuzz testing, can be used to locate memory leaks and buffer overflows in mobile devices. However, they cannot easily be used to run foreign code.
Poor Code Quality Risks
Safe Web Code, Compromised in Mobiles
By letting a threat agent push untrusted inputs whenever certain code subsets are called in the context of a mobile device, mobile code can compromise an otherwise secure app that performs well in web browsers. Despite the fact that such a mobile code is not malicious in general, it can compromise a user’s privacy if it allows untrusted code to run on the device. An example of a vulnerability in this category is a memory leak or a buffer overflow.
Lacunae in Third-Party Libraries
Incorporating popular libraries into apps should be handled with caution. App developers face a security issue when even established players provide compromised libraries unknowingly. Developers often overlook updates to third-party libraries where the library developer has corrected the bad code of an earlier version, which leaves an application vulnerable to attacks that could have been avoided.
Client Input Insecurity
A developer creates a safe input code for an app created specifically for a customer. Since content provider calls can contain sensitive information, this practice can lead to content provider attacks. Alternatively, an attacker can contact a content provider and obtain access to unsecured information.
Best Practices to Avoid Poor Code Quality
Mobile-Specific Code
Fixing this issue is as simple as rewriting the code in the mobile device rather than trying to fix it on the server. In contrast to poor coding on the client side, developers should keep in mind that poor coding on the server can be just as detrimental. It is possible for a coding issue at the server-side of the app to appear in the web version too, but it has no impact on the mobile version.
Static Analysis
Static analysis tools should be used by developers to identify memory leaks and buffer overflows. It would be beneficial to try to eliminate the mismatch between the length of data in incoming buffers and the length needed for the target buffer.
Code Logic
In iOS and Android devices, developers should refrain from coding simple logic because hackers have been known to favor it. Logic can be used by hackers to change the value of a code and circumvent the security system as a whole. At both assembly and runtime levels, such codes can be exploited. This leakage could be controlled if the developer prevented untrusted sessions from accessing device privileges and instead activated them at the system level. In addition, permissions should be withheld until the authentication process has been completed with a passcode, secret question, or challenge.
Library-Version
Even if it has used only libraries from trusted sources, the development team should keep track of updated third-party libraries and periodically verify that the apps are using the latest versions.
Content Provider
Developers should consider all client input as untrusted and validate it regardless of how it is collected or received. To prevent all unauthorized access, they should set permission flags on content provider inputs carefully.
M8: Code Tampering
The reason coders favor manipulating apps over other types of hacking is that the manipulation of code allows them to gain access to applications, user behavior, or even the entire device. In order to lure users into downloading altered versions of well-known apps, some of these apps pop up as fake advertisements or phishing attacks.
Code Tampering Risks
Malware Infusion
In the case of an app that was successfully downloaded and installed, the user’s binary or resource package has been modified. Hackers can change APIs in tampered apps so as to execute malicious foreign code on mobile phones. Among other things, hackers usually manipulate binary code, modify resident code, and modify memory in order to gain access to the device.
Data Theft
Modified apps often offer additional features that don’t exist in the original apps, which is an incentive for users to adopt them. Among the most common types of tampered apps are duplicate apps in app stores, which are detected and removed from app stores, as well as education about possible data theft scenarios.
However, their code is housed in an environment that is completely outside their control. An operating system flaw can be exploited by hackers to affect a legitimate app. Furthermore, when users root or jailbreak their devices, they knowingly allow third parties to alter resident codes on the device.
In short, developers shouldn’t assume that all tampering is bad. The purpose might be inconsequential in some cases, while in other cases, the users may have been deliberately malicious. Developers should pay extra attention to financial or gaming apps, however. Users can bypass freemium options in some gaming apps, for example, and move on to the next level without having to pay. The hacker could easily gain access to user information through such an attractive offer for users.
Best Practices to Avoid Code Tampering
Runtime Detection
Runtime code change detection should be built into the app. It is advisable to report the compromise at runtime if the developer doesn’t want the app to run on a jailbroken or rooted device. A real-time attack vector detection and prevention technique known as RASP can be used by developers for this purpose.
Checksum Changes
Checksums and digital signatures can be used to determine if files have been tampered with. Almost always, tampering with code or a file affects the checksum value, which can help determine the type of action taken.
Data Erasure
In the case of tampering, the app code, key, and data should be deleted. By introducing such a provision, hackers will be discouraged from tampering again with the same app.
M9: Reverse Engineering
An exploitable vulnerability in mobile code is reverse engineering. A majority of hackers use external, commonly available tools to inspect the original app’s code patterns and connections to the server, such as IDA Pro, Hopper, and otool, etc.
Reverse Engineering Risks
Dynamic Inspection at Runtime
Reverse engineering is easier in some languages – like Java, Objective C, .NET, Swift – because those languages permit dynamic inspection at runtime. As well as damaging servers and mobile devices, reverse engineered code may affect the ability of servers to detect jailbroken or rooted devices as well as the security of the server.
Code Stealing
It is possible for app competitors to reverse engineer an app’s functionalities and copy some features secretly. By doing so, new code can be created at a lower cost.
Premium Features
In this way, hackers can bypass the authentication process to gain access to the premium features of the app. Through this method, game cheats can unfairly gain an upper hand over their competitors.
Best Practices to Avoid Reverse Engineering
Use Similar Tools
To protect an application against reverse engineering, make sure that you use the same tools as hackers do. The code is compromised if these tools are able to analyze string tables, logic flow paths, data ciphers, metadata, and more. It is also possible for developers to detect reverse engineering attempts in real-time using a tool like appealing.
Code Obfuscation
Targeting certain segments of the source code, string tables, and methods that least impact performance is a key element of the obfuscation process. De-obfuscation tools, such as IDA Pro and Hopper, should not be able to unobfuscated the developers’ obfuscation efforts.
Use C Languages
Consider using C and C++, which can greatly assist you in runtime manipulation. A similar approach for Android apps can be to utilize its Java Native Interface. These two languages are well suited for Objective C libraries. It is also used to protect runtimes and reverse-engineering tools like class-dump, class-dump-z, Cyscript, and Frida.
M10: Extraneous Functionality
To make it easy for the development team to have easy access to the backend server, create logs for error analysis or carry staging information and testing details, code is often placed in an app before it is ready for production. During the development cycle, this code isn’t necessary to the functioning of the app, so once the app gets into production it is no longer necessary for users.
Extraneous Functionality Risks
When an adversary gains access to a benign code, they usually do not gain any benefit from it. Certain cases, however, may include code that carries information about databases, users, permissions, API endpoints, etc., or that disables functionality such as two-factor authentication.
Best Practices to Avoid Extraneous Functionality
There is a risk of the M10 vulnerability not being detected by automated tools. The process of pushing apps to app stores often requires manual intervention. Before the developer releases the app, he or she should:
• The final build should not contain any test code;
• The configuration settings should not contain any hidden switches;
• There should be no information about the server backend, administrative privileges, etc. in logs;
• It is generally not a good idea to include any descriptive information in logs;
• Make sure OEMs don’t expose full system logs to applications;
• Stop method calls from interacting with log classes by using ProGuard or DexGuard;
• The app’s debug flag must not be set to true by an adversary; and
• Apps should document the API endpoints they access.
Zestminds has long been a fan and supporter of OWASP (Open Web Application Security Project). Developers at Zestminds understand how to incorporate and identify security risks in the apps and help to manage their risks accordingly.
Contact us if you have any doubt regarding the security of your mobile app and if you want to build a mobile app that is secured. Contact us at info@zestminds.com.
