OWASP Top 10 Mobile Vulnerabilities

As mobile applications continue to grow as an attack vector, organizations will need to prioritize mobile app security to fortify their overall security posture. Both static attacks based on the source code itself and dynamic attacks that exploit app functionality are constantly evolving. That’s why understanding and remediating the most common mobile app vulnerabilities is crucial for mobile development teams.

An important resource for identifying security vulnerabilities and implementing mobile security best-practices is the Open Web Application Security Project (OWASP). While OWASP is best known for publishing insights into security vulnerabilities within web applications, the foundation also has a mobile security project focused on the mobile app industry. 

OWASP has published research into the top mobile security threats and best-practices for defending against them. Here’s a brief overview of their most recent top 10 mobile risks list, as well as an in-depth resource for how app developers can navigate them.

M1. Improper Platform Usage

Improper platform usage is ranked as the top mobile security vulnerability in the most recent OWASP mobile top 10 ranking. Whether you use Android or iOS, each of these platforms is expected to follow specific development standards for security reasons. Apps may, however, unintentionally transgress these best practices and established recommendations or make mistakes during their implementation. This first mobile security risk focuses on that.

This threat refers to the misuse of any platform feature of the Android or iOS operating system or failure to incorporate platform security controls. This includes issues concerning improper use of security controls and platform features that are a part of the mobile operating system, such as:

  • Misuse of the iOS Touch ID feature, which can result in unauthorized access to the device.
  • Incorrect use of the iOS Keychain for instance by storing session keys in the app local storage,
  • Requesting excessive or wrong platform permissions,
  • Android intents (used to request an action from another app component) that are marked public may reveal sensitive information or permit unauthorized execution.

This OWASP mobile security risk is something that you must address on the server side of things. Alongside following platform development guidelines, using secure coding practices and applying the right configuration settings on the server-side helps to minimize risks. Additional mitigation strategies to reduce platforms from being used improperly include the following:

  • Restricting apps from communicating with each other, limit access, implement restrictive file permissions, etc.
  • Applying the most restrictive protection class for iOS keychains and adopt best practices to avoid weak implementation of any controls.

M2. Insecure Data Storage

Next on the OWASP mobile top 10 list is insecure data storage. Your mobile device may get lost or stolen and land in the hands of an adversary. Or a piece of malware, acting on the attacker’s behalf, may execute on the device, and the attacker might be able to exploit vulnerabilities that leak personal information and gain access to sensitive data.

While it isn’t always possible to create apps that don’t save data, it is essential to do it safely and in a location where neither another app nor a person would be able to access it. Dev teams must never assume that attackers won’t have access to filesystems if they are readily available. Jailbreaking or rooting a mobile device is sufficient to get around encryption security.

Threat model the app to understand what information assets are processed by the application and how the APIs handle the data. Doing this helps you to:

  • Assess whether encryption is applied effectively and how the encryption keys are protected.
  • Implement technologies to harden the code against tampering by using obfuscation, protection against buffer overflows and so on,
  • Avoid storing/caching data where feasible, and
  • Deploy sound authentication and authorization checks.

M3. Insecure Communication

Insecure communication ranks third in 2016 OWASP mobile top 10 list. If the data travels unencrypted in cleartext, anyone monitoring the network can capture and read all the information being sent over the wire.

Client-server data interchange is ubiquitous in mobile apps, and this data must be securely delivered through the device’s carrier network and the internet. Cell towers, proxies, spyware installed on your device, or an enemy compromising your Wi-Fi can all intercept the traffic. What can you do, then, to lessen the risks involved in this kind of data exchange?

To avoid data from being stolen as it travels across the network, rely on industry-standard encryption protocols and other general best practices.

  • Deploy SSL/TLS certificates from trusted certificate authorities (CA) to secure all communication channels.
  • Alert users if an invalid SSL/TLS certificate is detected or if the certificate chain verification process fails.

M4. Insecure Authentication

Insecure authentication comes next on the OWASP mobile security vulnerabilities list. Before granting access, mobile apps need to verify the identity of the user. An authentication bypass is often executed by leveraging existing vulnerabilities, such as improper validation of service requests done by the mobile app’s backend server. Mobile apps need to verify and maintain user identity, especially during the transmission of confidential data such as financial information.

Weaknesses in the authentication mechanism for mobile apps can be exploited by an attacker. Capitalizing on those weaknesses allows them to bypass password requirements or gain additional permissions leading to data theft and other damages.

So, what can you do to stop it?

  • Avoid local authentication methods. Instead, shift this responsibility to the server-side and download application data only after a successful authentication.
  • Refrain from using vulnerable authentication methods (such as device identity), don’t store passwords locally, implement multi-factor authentication (MFA), disallow using all four-digit PIN as passwords where feasible, etc. 

M5. Insufficient Cryptography

There are two situations in which a system’s cryptography may get compromised to reveal sensitive data:

  1. The underlying algorithm used for encryption and decryption might be weak, or
  2. The cryptographic process itself has implementation flaws.

Broken cryptography in mobile apps can be the result of one of several factors. This list of potential causes includes:

  • Bypassing built-in code encryption algorithms,
  • Improperly managing your digital keys, and
  • Using custom or deprecated encryption protocols.

Insufficient cryptographic controls can lead to the unauthorized retrieval of sensitive data (such as personal information about the user) from the device.

  • Apply strong cryptographic standards as recommended by the National Institute of Standards and Technology (NIST).
  • Avoid storing any sensitive data on the device whenever possible

M6. Insecure Authorization

Not all users are created equal! Some users may be regular users, while others may require additional permissions and privileges, such as admin users. Poor authorization schemes fail to verify not who the user is but whether the user is sanctioned to access the resources they’re requesting. Failure to properly enforce identity as well as the permissions given to the users allow hackers to log in as legitimate users and perform privilege escalation attacks.

The impact of insecure authorization is similar to insecure authentication. They both may lead to data theft, reputational damage, and even noncompliance fines and penalties.

  • Ensure that for each request, backend processes verify that incoming identifiers associated with an identity match up and actually belong to the identity.
  • Validate the roles and permissions of an authenticated user using the information on backend systems and not based upon the information supplied by the mobile device.

M7. Client Code Quality

This category on the list of OWASP mobile security risks is a bit of a catch-all for mobile client issues relating to faulty code implementations.

An attacker may pass crafted inputs to function calls made within an app in an attempt to execute them or observe the application’s behavior. It may lead to degradation of performance, increased memory usage, etc. Note that the mistakes in code need to be fixed in a localized way since they arise on the mobile client and are different from server-side coding errors. There could be code-level mistakes in mobile apps that may lead to issues such as:

  • Format-string vulnerabilities,
  • Buffer overflows,
  • Integration with insecure third-party libraries,
  • Remote code execution

Several apps rely on third-party libraries to build their applications, which often contain bugs and are not well tested. These issues are outside the control of the app developer since they don’t own the code. More often than not with code-level bugs, the solution is to rewrite some of the code running on the device. But what else can you do?

Poor code quality issues may lead to remote code execution and other vulnerabilities and issues that we’ve already mentioned. Thankfully, there are a few things you can do to help mitigate these issues:

  • Test for buffer overflows, memory leaks, etc. using automated tools, rely on source code reviews, and write code that’s easy to understand and well documented. 
  • Use consistent coding patterns across the organization.

M8. Code Tampering

Modified versions of mobile apps can occasionally be found in app stores. A modified program is one where a hacker changes the binary to add harmful code, set up a backdoor, etc. Attackers have the ability to re-sign these fake apps and upload the updated version to other app stores. In order to mislead a victim into downloading the software, they can also deliver them to them directly via a phishing attack.

Tampering with the code can lead to revenue loss, identity theft, reputational and other damages.

  • The app must be able to identify any code integrity violation (if additional code has been added or modified) and react suitably to it at runtime. Using something like a code signing certificate could help to let users know about the code alterations.
  • Implement anti-tamper techniques that prevent illicit apps from executing via implementation of checksums, digital signatures, code hardening, and other validation methods.

M9. Reverse Engineering

Attackers may reverse engineer the app and decompile it to perform some code analysis. This is particularly dangerous since the attacker can understand, inspect, and modify the code to include harmful functionality or transmit undesired advertisements. Once they understand how the app operates, they can modify it using tools such as IDA Pro, Hopper, and other binary inspection tools. Once they get the app to behave in the desired way, they can recompile and run the app.

In order to prevent reverse engineering, the attacker must be unable to de-obfuscate the code using tools like IDA Pro and Hopper. 

M10. Extraneous Functionality

Sometimes developers may unintentionally leave backdoors or additional functionalities in mobile apps that aren’t apparent to end users via the interface. These products may get released into the production environment with a feature not intended to be made available, creating security risks.

These weaknesses can typically be exploited by hackers from their systems directly without requiring any participation from regular users. They may examine configuration files, analyze the binary, etc. to discover functionalities in the back-end system that cybercriminals can leverage to perform an attack.

One of the most effective ways to prevent these types of mobile app vulnerabilities is to perform manual secure code review. What this does is allow you to:

  • Examine the mobile app’s configuration settings to detect any hidden switches.
  • Ensure that the logs don’t hold exceedingly descriptive statements about backend systems.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *