How can OWASP help you define your mobile app security policy?

The trend of finance going mobile is unstoppable. According to the 2021 Mobile App Trends report from Adjust, there are 2.5 finance apps on average installed per user.

Global online payments have reached USD 1.39 billion in 2020 and are projected to reach USD 1.68 billion this year, registering an astounding revenue increase by 250% from 2020 to 2025.

As mobile banking and finance grows in popularity, cybercriminals have also directed their attention to mobile applications. In the 2022 Security Report published by Check Point, cyberattacks targeting the finance/banking sector have seen an annual growth of 53% in 2021. Given the escalating scale of cyberattacks, 77% of finance apps have at least one critical or high severity vulnerability according to Intertrust’s 2021 State of Mobile Finance App Security Report.

The stats below shows Intertrust’s investigation into the risk types and the preparedness of financial apps facing rising cyberattacks:

On the other hand, AppSec standards have been through some changes recently, impulsed by the PSD2. In these circumstances, there is a strong need for the maturity of the mobile app security landscape.

Is your organization ready and well-equipped to enter this game?

Let’s be inspired by the OWASP expert community

To help organizations efficiently develop and secure their mobile apps, the OWASP (Open Web Application Security Project®) has put together highly valuable resources:

• The OWASP Mobile Top 10: gathers the most critical security risks encountered on mobile applications. This list helps you identify the top priority risks you must be protected against.
• The Mobile Application Security Verification Standards (MASVS): describes 4 levels of verification standards that help you quantify your level of compliance against the OWASP. This score is a good way for you to measure your progress over time and to communicate both internally and to external third parties.
• The Mobile Security Testing Guide (MSTG) is a set of test cases to be performed in order to evaluate your MASVS compliance score. Your Security Policy starts from here.

What are the Top 10 Mobile Risks according to OWASP?

In order to help organizations to prioritize their work in terms of mobile app protection and to understand the exploitability and the business impact of each threat, OWASP has put together a top 10 of the Mobile App Risks. Although this list is dated now (2016), it remains highly relevant:

• M1: Improper Platform Usage

This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.

• M2: Insecure Data Storage

Threats agents include the following: an adversary that has attained a lost/stolen mobile device; malware or another repackaged app acting on the adversary’s behalf that executes on the mobile device.

• M3: Insecure Communication

When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device’s carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it’s travelling across the wire.

• M4: Insecure Authentication

Threat agents that exploit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools.

• M5: Insufficient Cryptography

Threat agents include the following: anyone with physical access to data that has been encrypted improperly, or mobile malware acting on an adversary’s behalf.

• M6: Insecure Authorization

Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.

• M7: Client Code Quality

Threat Agents include entities that can pass untrusted inputs to method calls made within mobile code. These types of issues are not necessarily security issues in and of themselves but lead to security vulnerabilities. For example, buffer overflows within older versions of Safari (a poor code quality vulnerability) led to high-risk drive-by Jailbreak attacks. Poor code-quality issues are typically exploited via malware or phishing scams.

• M8: Code Tampering

Typically, an attacker will exploit code modification via malicious forms of the apps hosted in third-party app stores. The attacker may also trick the user into installing the app via phishing attacks.

• M9: Reverse Engineering

An attacker will typically download the targeted app from an app store and analyze it within their own local environment using a suite of different tools.

• M10: Extraneous Functionality

Typically, an attacker seeks to understand extraneous functionality within a mobile app in order to discover hidden functionality in backend systems. The attacker will typically exploit extraneous functionality directly from their own systems without any involvement by end-users.

MASVS is the guide to define your Mobile App Security Policy

The Mobile Application Security Verification Standard (MASVS) is a standard for mobile app security. Depending on the apps’ features and the required level of protection, these standards can be combined as follows:

• MASVS-L2+R
• MASVS-L2
• MASVS-L1+R
• MASVS-L1

At eShard, we have automated a wide range of security tests to be run on your mobile applications. You can run preset OWASP campaigns to verify how far you are from the OWASP compliance. Want to give it a try?

> MASVS-L1: Mobile Application Security Verification Standard - Standard Security

Any mobile application should at least follow this standard. It gathers the basic best practices when it comes to sensitive data management (e.g. payment or user data), code quality, and much more.

> MASVS-L2: Mobile Application Security Verification Standard - Defense-In-Depth

Suited for mobile applications handling PII (Personally Identifiable Information), payment information, or that allow users to move funds. This is also recommended if you’re looking for specific regulatory compliance such as:

• Health Insurance Portability and Accountability Act (HIPAA), Privacy, Security, Breach Notification Rules and Patient Safety Rule,
• PCI DSS (Payment Card Industry Data Security Standard),
• SOX (Sarbanes-Oxley Act),
• Gramm Leach Bliley Act.

> MASVS-R: Mobile Application Security Verification Standard - Resilience

This section is critical to be protected against vulnerabilities coming from the user’s mobile phone. As a mobile app editor, you need to make sure the app you provide to your users is under control: how is it supposed to behave on a rooted phone? Can it detect a code injection attempt? Does it prevent the use of debuggers or emulators which are tools attackers may use to reverse-engineer your app?

The Mobile Security Testing Guide is a goldmine

To help the app testers during the mobile app security testing phase, OWASP has put together a series of testing cases, broken down into 8 categories:

These test cases can be either run manually by your Engineers or Security teams or can be automated by a tool like esChecker. Actually, some of them can not be automated, but how would your teams feel if a decent part of them could be?

You can also use the OWASP Mobile App Security Checklist to identify precisely the use cases to be tested against each MSTG:

Now you know:

• the security risks,
• the protection best practices,
• the security testing cases,
• the security policy recommendations.

With esChecker, set up and automate your Security Policy audit

eShard is the only MAST solution on the market to cover OWASP-R criteria (Resilience layer of the MASVS), from the binary, and not from the source code. We want to use the same resource a potential hacker would use to harm your business.

It helps you make the change from DevOps to DevSecOps, which leads to an automation of the Security Testing for every new build of your mobile app before it does live on the stores.

With years of reverse engineering experience, our team has gathered a specific test suite to stress mobile applications.

And this is performed leveraging our dynamic testing technology: the application is tested when it is running by recording a sequence of operations and replaying it as many times as necessary, allowing to test 100% of the code at runtime.

What are the Mobile App Potential Threats you should be aware of?

Have you ever thought of the potential threats mobile applications could represent? There’s a reason why In-App Protections are now getting a real thing in all organizations, regardless of their size, for two main reasons:

• Protect yourself against users that may cheat your business

Did you know that some people are skilled enough to inject code into their mobile phone to fake a particular behavior, such as pretending to pay for a premium option, increasing their gaming wallet, accessing protected spaces of your app pretending to be logged in as a genuine authorized user, etc?

• Prevent your users from being abused by hackers

If you provide a non-secure application to your users, you expose them to critical risks. Some apps (maybe yours?) store personal information or credentials within the mobile phone memory. If you don’t want your Data Protection Officer to be mad at you, make sure that the data you manipulate on behalf of your users is securely handled and stored.

Oh, and if you thought that Apple devices were less exposed than Android’s thanks to iOS, you are so wrong. Both Operating Systems are vulnerable. We highly recommend paying as much attention as possible to your entire mobile apps ecosystem. That’s why we’ve incorporated automated security testing for iOS and Android into esChecker, our MAST tool.

What kinds of risks should you be protected against?

There are so many ways to harm your business if you don’t protect your mobile application:

> Use of rooted/jailbroken phones

Mobile phones are rooted by their owners because they want to gain full control over and access to their mobiles. Most of the time, they want to force the uninstallation of the default apps or the extra OS layer of the device manufacturers or get rid of Google services. This also leads to the uninstallation of the built-in protections of iOS or Android.

As a consequence, apps could potentially access every personal private and sensitive information used in your own app, if users have untrustful and malicious apps installed on their mobile phones.

> Hook attacks

Hooking an application is a way for an attacker to change the expected behavior of an application. By injecting some code, an attacker could change the data displayed on the app, or collect some sensitive information and save it or send it to an external space. An attacker can use this hooking technique to understand and the application works to exploit the breach in a more harmful manner. This allows misleading the users and compromises their trust in the mobile app.

> Emulators & Debuggers

The mobile application must prevent the usage of a debugger and an emulator in production. Attackers may use such tools to understand the way the app works and help them to reverse engineer it. You must make their job as hard as possible to preserve your protection.

> Coding best practices

when developing an application, there are some basics that you must follow:

• Handle the permissions (read/write) on files and folders with care,
• Don’t use weak hash algorithms, such as SHA1, MD4, MD5, etc.,
• Make sure your certificates are always up and running,
• Manage carefully the access to the screenshot features, to the clipboard, etc.,
• And many more.

With esChecker, you get immediate feedback covering a large range of requirements. Everything is summarized in a single report.

It is as easy as:

• Upload your app binary (.apk or .api)
• Launch one of the preset OWASP campaigns
• Get the report within a few minutes to get the results

You can now dig into the OWASP Report, category by category, to understand the MSTG’s that require your attention to obtaining OWASP compliance.

Beyond your internal usage, the report can also be used as a demonstration of compliance.

We’ll be happy to show you how much time it saves and how relaxed you’ll become with this protection audit tool in your hands.

Start the free test now!