Understanding OWASP Mobile Top 10 Risks with Real-world Cases

Carrying an industry record of developing 100% hack proof applications come with a responsibility and a baseline guarantee that none of the digital solutions developed under our name would face security breach. 

As a way to achieve that, Appinventiv’s Quality Assurance team are familiar with all the possible security risks which an app can face. Knowing the risks makes it easy to ignore pitfalls and write secure apps.

Helping us be on top of the game when it comes to assuring security is having a complete knowledge of OWASP secure coding practices (Open Web Application Security Project). It is an online community of security specialists who have developed free documentation, learning materials, and tools for building secure mobile and web applications. 

Along with other things, they have also compiled a list of OWASP Mobile Top 10 security threats in mobile applications.

While the OWASP security practices document is fairly clear, it can sometimes be difficult for businesses to connect it from real-world cases. 

In this article, we will give you a basic overview of Top 10 mobile security risks and give examples of the real world disclosed vulnerabilities for each of them. It will give you an insight into what we prepare for at Appinventiv when we work on your application. 

Before looking into the risks, let us look into statistics. 

NowSecure looked into the apps on Google Play store and App store identified that over 85% of apps violate one of the risks.

Of these applications, 50% have had insecure data storage and somewhere the same number of apps were working with insecure communication risk. Here’s a graph showcasing the percentage of occurence of the OWASP Mobile Top 10 risks

List of 10 Most Common Threats to Mobile Applications and the Best Practices to Avoid Them

M1: Improper Platform Usage 

The category of OWASP security testing consists of the misuse of a device functionality or the instance of failure when using platform’s security controls. It can include  platform permissions, Android intents, misuse of the TouchID, Keychain, etc.

Real-World Case:

Three iOS apps: “Fitness Balance app”, “Heart Rate Monitor”, and “Calories Tracker app” came into light for bypassing Apple’s Touch ID. They were asking users to use their fingerprint to get fitness information, while they were using it to charge money from the App Store. 

Best Practice to Avoid: 

• The developer must not allow Keychain encryptions through server route and keep the keys in one device only, so that it’s impossible to get exploited on other servers or devices. 
• The developer must secure the app through Keychain to store the app’s secret that has a dedicated access control list. 
• The developer must take permission to limit which apps are allowed to communicate with their application. 
• The developer must control the first of OWASP Mobile Top 10 list by defining the explicit intents and thus blocking all other components to access information present in the intent. 

M2: Insecure Data Storage 

OWASP consider it a threat when someone gets access to a lost/stolen mobile device or when malware or another repackaged app starts acting on the adversary’s behalf and executes action on mobile device.

An insecure data storage vulnerability usually lead to these risks: 

• Fraud
• Identity Theft
• Material Loss.
• Reputation Damage
• External Policy Violation (PCI)

Real-World Case:

Dating apps like Tinder, OKCupid, and Bumble have time and again been scrutinized for their insecure data storage practices. The security lapses present on these apps vary according to feasibility and severity and feasibility, can expose users’ name, login details, message history, and even location, in addition to other personal account activity. 

Best Practices to Avoid: 

• For iOS, OWASP security practices recommends using purposely made vulnerable apps like iGoat to threat model their development framework and apps. This will help the ios app developers understand how APIs deal with the app processes and information assets. 
• The Android app developers can use the Android Debug Bridge shell for checking the file permissions of targeted app and DBMS to check database encryption. They should also use Memory Analysis Tool and Android Device Monitor to ensure device memory doesn’t have unintended data.

M3: Insecure Communication 

When devising a mobile app, data is exchanged in client-server model. So, when the data is transmitted, it should first traverse the device’s carrier network and the internet. The threat agents could exploit vulnerabilities and intercept sensitive data while traveling across wire. Here are the different threat agents who exist:

• Adversary who shares your local network – a compromised Wi-Fi
• Network or Carrier devices – cell towers, proxy, routers, etc. 
• Malware on the mobile device.

The interception of sensitive data via communication channel would end up in a privacy violation, which can lead to:

• Identity theft
• Fraud
• Reputational Damage.

Real-World Case:

Rapid7 security company disclosed several vulnerabilities attached with kids’ smartwatches. Those watches were marketed as ones used by parents for tracking their children and sending them messages or making calls on their smartwatch. 

The watches were supposed to be contacted by approved contact numbers through the mode of a whitelist, but the company found that the filters were not even working. The watches even accepted configuration commands via text messages. It meant that a hacker could change the watch settings and put children at risk. 

“You can identify where the phone or the child is, you can gain access to audio, or make phone calls to children,” said Deral Heiland, the IoT research lead at Rapid7.

Best Practices to Avoid:

• Developers should not only look for leakages over traffic communicated between app and server but also device that holds the app and other device or local network. 

• Applying TLS/SSL for transporting channels is also one of the mobile app security best practices to consider when it comes to transmitting sensitive information and other sensitive data.

• Use certificates given by trusted SSL chain verifications. 
• Do not send sensitive data over alternate channels like MMS, SMS, or push notifications. 
• Apply separate encryption layer to sensitive data before giving to the SSL channel. 

M4: Insecure Authentication

The threat agents who exploit authentication vulnerabilities do so via automated attacks which makes use of custom-built or available tools.

The business impact of M4 can be:

• Information Theft
• Reputational Damage
• Unauthorized Access to Data.

Real-World Case:

In 2019, a US bank was hacked by a cyber attacker who took advantage of the bank’s website flaw and circumvented the two-factor authentication that was implemented for protecting accounts. 

The attacker logged into the system through stolen victim credentials and upon reaching the page where PIN or security answer had to be entered, the attacker used a manipulated string in the Web URL, which had set the computer as a recognized one. This enabled him to cross the stage and initiate the wire transfers. 

Best Practices to Avoid:

• The app security team must study the app authentication and test it through binary attacks in offline mode for determining if it can be exploited. 
• The OWASP web application testing security protocols must match those of mobile apps. 
• Use online authentication methods as much as possible, just like that in case of web browser.
• Do not enable app data loading until the server has authenticated the user sessions. 
• The places where local data us eventual, ensure that it is encrypted through encrypted key derived from users login credentials. 
• The persistent authentication request must also be stored on the server. 
• The security team should be careful with device-centric authorization tokens in the app, since if the device gets stolen, the app can get vulnerable. 
• Since the unauthorized physical access of devices is common, the security team must enforce regular user credential authentication from server end. 

M5: Insufficient Cryptography Risks

The threat agents in this case are the ones who have the physical access of data which was encrypted wrongly. Or where a malware is acting on the behalf of adversary. 

Broken cryptography generally result in these cases:

• Information Theft
• Intellectual Property Theft
• Code Theft
• Privacy Violations
• Reputational Damage.

Real-World Case:

Sometimes ago an alert from DHS Industrial Control Systems’ Cyber Emergency Response Team and the Philips advisory warned users of a possible vulnerability in the Philips HealthSuite Health Android app. 

The issue which was tracked back to inadequate encryption strength, opened the app to hackers who could get access to users’ heart rate activity, blood pressure, sleep state, weight and body composition analysis, etc. 

Best Practices to Avoid:

• To solve this one of the most commonly occuring OWASP Top 10 Mobile risks, developers must choose modern encryption algorithms for encrypting their apps. The choice of algorithm takes care of the vulnerability to a great extent. 
• If the developer is not a security expert, they must refrain from creating own encryption codes. 

M6: Insecure Authorization Risks

In this case, the threat agents are able to access someone else’s application typically via automated attacks which use custom-built or available tools.

It can lead to following issues:

• Information Theft
• Reputational Damage
• Fraud

Real-World Case:

The Information security specialists at Pen Test Partners hacked Pandora, a smart car alarm system. In theory, the application is used to track a car, cut off the engine if stolen and lock it until police arrive. 

On the other side of the coin, a hacker can hijack the account and get access to all the data and the smart alarm functionalities. Additionally, they could:

• Track vehicle movements
• Enable and disable alarm system 
• Lock and unlock car doors
• Cut the engine
• In the case of Pandora, hackers got access to everything that was talked about inside the car through the anti theft system’s microphone. 

Best Practices to Avoid:

• The QA team must regularly test the user privileges by running low privilege session tokens for the sensitive commands. 
• The developer must note that the user authorization schemes go wrong in the offline mode.
• The best way to prevent this risk is to run authorization checks for permissions and roles of an authenticated user at server, instead of the mobile device. 

M7: Poor Code Quality Risks

In these cases, untrusted inputs are passed by entities to method calls made in the mobile code. An effect of this can be technical issues which can lead to degradation of performance, heavy memory usage, and poor working front-end architecture.

Real-World Case:

WhatsApp last year patched a vulnerability that hackers were taking advantage of for installing surveillance malware called Pegasus Spyware on smartphones. All they had to do was place a WhatsApp audio call on the targeted phone numbers. 

Within a simple few steps, hackers were able to get in the users’ devices and access it remotely.

Best Practices to Avoid:

• According to the OWASP secure coding practices, the code should be rewritten in the mobile device instead of fixing them at the server side. The developers must note that bad coding at the server side is very different than poor coding at client level. Meaning, both weak server side controls and client side controls should be given separate attention.
• The developer must use third party tools for static analysis to identify buffer overflows and memory leaks. 
• The team must create a third-party libraries list and check it for newer versions periodically. 
• Developers should see all the client input as untrusted and validate them irrespective of whether they come from users or the app. 

M8: Code Tampering Risks

Usually, in this case, an attacker exploits code modification via malicious forms of the apps hosted in the third-party app stores. They might also trick users into installing an application through phishing attacks.

Best Practices to Avoid:

• The developers must make sure that the app is able to detect code changes at runtime. 
• The build.prop file must be checked for the presence of unofficial ROM in Android and to find out if the device is rooted. 
• The developer must use checksums and evaluate the digital signatures to see if file tampering has taken place. 
• The coder can make sure that the app keys, code, and data are removed once tampering is found. 

M9: Reverse Engineering Risk 

An attacker typically downloads the targeted app from the app store and analyzes it inside their local environment with a suite of different tools. Following which, they are able to change the code and make the app function different. 

Real-World Case:

Pokemon Go recently faced the security breach glances when it was found that users had reverse engineered the app to know the vicinity of the Pokemons and catch them in minutes. 

Best Practices to Avoid:

• The best way to safeguard an app against the risk, according to OWASP mobile security, is to use the same tools as the hackers would use for reverse engineering. 
• The developer must also obfuscate the source code so that it gets difficult to read and then reverse engineer. 

M10: Extraneous Functionality Risk

Usually, a hacker looks at the extraneous functionality inside a mobile app in order for discovering the hidden functionalities in the backend systems. The attacker would exploit extraneous functionality from their own systems without any end-users involvement.

Real-World Case:

The idea of Wifi File Transfer app was to open port on Android and allow connections from the computer. The problem? An absence of authentication such as passwords, meaning, anyone could connect to a device and get its full access.

Best Practices to Avoid:

• Ensure that there is no test code in final build
• Ensure there is no hidden switch in the configuration settings 
• Logs must not contain any backend server process description
• Ensure that the full system logs are not exposed to apps by the OEMs
• The API endpoints must be well documented.

Related Articles: