In September 2019, a notorious hacker exposed over 173 million user accounts of the popular mobile game Words with Friends. In 2018, Under Armour confirmed that hackers got to the My Fitness Pal app, exposing 150 million users. These giants have bounced back from the blows, though it cost them dearly. But can your company afford to lose hard-earned dollars and reputation?

App security can’t be an afterthought, and you need to be sure the application you’re delivering to users is secure. How? By designing it with security in mind and thoroughly testing the app, of course. 

Why you should care about securing your application

Users blindly trust mobile applications with their most sensitive info. They either believe companies have taken all the necessary security measures before introducing their product to the market or are simply unaware of the threats. Yet, according to Accenture, in 2019, security breaches have increased by 11% compared to the previous year and by 67% since 2014. 

There probably is more than one reason for this growth. But the fact is, many companies forgot security testing in a rush to outrun the competition and bring their mobile app to the market as soon as possible. Let’s look at the consequences of launching an application without proper AppSec.

Compromised login information

According to RiskBased, hackers exposed over 4 billion records in the first half of last year alone. There are dozens of ways to get login credentials for even an inexperienced hacker. One recent example, found by Kaspersky in the first quarter of 2020, is Cookiethief. 

This trojan steals cookies from the Facebook app and mobile browsers and gives hackers access to user accounts. This allows the attackers to perform various actions in the user’s name, including changing the login credentials. Since a lot of people use Facebook login for other apps and services, this trojan can potentially expose sensitive data from more apps. 

Stolen financial information

With the global crisis and the pandemic not showing any signs of stopping, hackers are learning to adapt. Kaspersky has recently found a new modification of the popular malware Ginp – Coronavirus Finder. The trojan is disguised as an app able to detect people infected with COVID-19 nearby. 

Not only did its creators scam users by exploiting their reasonable fears, but they also received access to numerous credit card details. Hackers could even intercept multi-factor authorization OTPs and exploit other apps on the device.

Diminished growth resources

Restoring operations after a hacking attack means your business can suffer a serious setback. Companies are known to go bankrupt or having to let go employees just to stay afloat after a cyberattack. 

And even if your app wasn’t compromised much and the consequences weren’t severe, having to redirect your growth budgets to repair the damage left by the hackers might cost you years of business development. Preventing a security breach is much cheaper. 

Lost profits and destroyed reputation

If your app has premium features, you have to be especially careful with your security. For example, in March this year, there were numerous reports of Spotify Premium accounts hacked. As a result, Spotify got an army of irritated customers, and you can bet some of them have unsubscribed. In the end, a business is as good as its customers believe it is.

Regulatory fines

The General Data Protection Regulation (GDPR) has been in effect for only a couple of years, but the fines issued have already crossed €175 million. If your app deals with customers from the areas protected by the GDPR, and your failure to comply with cybersecurity regulations results in a data breach, you are sure to get severely punished by the regulator. 

Even if you don’t operate in the EU, other countries have their own regulations either already in place or coming soon. And when you’re researching general privacy regulations, make sure to check if there are specific rules to comply with in your industry (eg., banking and finance) in various countries.

While these consequences can make you feel uneasy, many of them can be prevented. But in order to know how to protect your mobile app, you need to know the threats first.

The OWASP top 10 for mobile

The Open Web Application Security Project (OWASP) is a collaborative effort of tens of thousands of security specialists worldwide on a mission to make the web a secure place. Founded in 2001, OWASP has created numerous tools, methodologies, and recommendations for web and mobile software. They also share their list of the top 10 risks to raise awareness about the latest security threats among software developers. 

The finalized list of mobile security issues included the following ones:

Improper platform usage

Mobile platforms provide well-documented features and capabilities, like TouchID, Keychain, permissions. If the app your team is developing fails to implement those features or misuses them (intentionally or unintentionally), this can result in a security violation.

Insecure data storage

This security risk might result from insecure storage in SQL databases, logs, data stores, and cookie stores. Other issues include weak server-side controls and undocumented or poorly documented internal processes. Finally, unintended data leakage might be a culprit here.

Risky communication

This risk refers to all aspects of insecurely transferring data from point A to point B. It includes all possible issues with mobile communications technologies such as GSM, TCP/IP, Wi-Fi, Bluetooth, NFC, 4G, SMS, etc. Poor TLS connection goes here too. If your app’s data can be changed or compromised during transmission with a man-in-the-middle attack or even simple eavesdropping, that is insecure communication.

Insecure authentication

If your app stores passwords and secret keys on its user’s device, you’ve got yourself an insecure authentication. The same goes for using weak password policies and anonymously executing an API service request without an access token. 

Weak cryptography

OWASP emphasizes two ways flawed cryptography can get into an application. The first one is the use of fundamentally flawed processes behind cryptography that hackers easily exploit to decrypt your data. The second one is the use of a naturally weak encryption algorithm. So make sure your team knows about both.

Insecure authorization

If your app’s code doesn’t perform a valid authorization check, you’re stuck with bad authorization schemes. As a result, hackers can smoothly gain access to administrative functionality. Another way to get this security risk is to transmit the permissions or user roles as part of a request. 

Client code quality

This one refers to all the vulnerabilities created by various code-level mistakes on the device side. We’re talking about buffer overflows and format string vulnerabilities.

Code tampering

Technically, all mobile code is vulnerable to tampering once delivered to the end user’s device. Hackers can change the code itself, change or replace APIs, modify your data or resources, and more.  

Reverse engineering

This is another security risk all mobile apps are technically susceptible to. All a hacker needs to do to exploit it is download your app and run an analysis of your core binary using relatively common binary inspection tools like Hopper, otool, or IDA Pro. 

Incidental functionality

Developers often introduce apps forgetting to remove the functionality that wasn’t supposed to be released. And attackers are happy to exploit backdoor functionality, security controls switched off for testing purposes, a password in a comment, and more. So make sure your development team doesn’t forget to lock all the doors on the app.

Now that you know the typical mobile security threats, it’s time to discover the main areas usually affected by them.

Key Areas in Mobile App Security

Like any other important task, mobile application security testing requires a smart approach and prioritization. These are the key areas we at Relevant pay attention to (and you should, too).

Code quality

While mobile apps are less susceptible to traditional injection attacks and memory management issues, you can’t afford to produce sloppy code. This is a perfect opportunity to introduce the security as code culture to your team and implement the DevSecOps methodology. If your team keeps security in mind from the very beginning and follows the best practices while coding, you’ll be safe from many issues.

Interaction with the platform

Platform-specific features like app permission systems that control access to APIs or inter-process communication (IPC) facilities, which let apps exchange data, have underlying potential problems. These pitfalls can also unintentionally expose other apps on the user’s device. 

Local data storage

Taking extra care with data storage means better protection to your users’ sensitive data. But if you lose caution and use the local storage or misuse IPC, it might expose sensitive data to other apps on the device and unintentionally leak data to backups, keyboard cache, or cloud storage.

Read also about cloud native app development.

Authentication and authorization

Unlike websites, mobile applications often store session tokens. It does allow for better user experience and faster login but introduces additional security risks and error possibilities. If you outsource authentication to 2FA providers and the authentication process goes through a separate app on the same device, your security tester has to pay attention to it, too. 

Speaking of mobile app security testing, why don’t we take a look at some of the most popular approaches and techniques?

Mobile application security testing techniques

Fundamentally, there are two approaches to security testing: standard testing, which is done at the end of the application development cycle, and the adoption of security requirements and security testing throughout the whole development cycle (SDLC).

Standard testing

Here are the main methods used in the security testing of mobile apps.

White-, black-, and grey-box testing

These three approaches differ in the extent to which testers can explore the mobile app from the inside.

• White-box testing. This method implies that the tester knows the app’s ins and outs and has access to the source code and various documentation. White-box testing allows for faster testing and more sophisticated test cases.
• Black-box testing. With this approach, the tester has no prior knowledge of the app, which allows them to behave like a user (or hacker) and exploit the publicly available info.
• Gray-box testing. This one is the most common approach in security testing. With it, some information (like the credentials) is provided, but the rest is to be discovered by the tester.

Vulnerability Analysis

This self-explanatory procedure is usually automated and done with various scanners, although it can also be done manually. There are two approaches to vulnerability analysis:

• Static analysis. This type of check implies an examination of software components without actually running the application. Its purpose is to review the implementation of security controls. It can be done in two ways: automatic and manual. Automatic analysis quickly picks the low-hanging fruit by checking the code against the preferred rules or standard practices. Manual code analysis allows testers to identify security vulnerabilities in design flaws, common standards violations, and business logic.
• Dynamic analysis. The dynamic check aims to find vulnerabilities and security holes while the mobile application is running. This type of analysis usually looks for the most common errors in server configuration, authorization and authentication issues, data leaks in transit, etc.

Penetration Testing

Penetration testing is a full-scale thorough security testing of mobile apps on the final stage of its development. Usually, it follows the same structure:

• Preparation. Testers identify testing goals, appropriate security controls, and which data to deem sensitive. They also address various legal issues at this stage.
• Gathering intelligence. The testing team gathers and analyzes the application’s contexts (environmental and architectural).
• Mapping the application. This stage provides a deeper understanding of the mobile app. What are the entry points? What data does it gather and store? What are the possible security vulnerabilities? Mapping answers these questions and allows testers to prioritize better.
• Exploitation. At this stage, testers try to penetrate the app and exploit the previous stage’s vulnerabilities.
• Final report. At the final stage, the testing team lists the vulnerabilities they found, details the exploitation process, documents all the security risks, and reports all the data they could reach illegitimately.

SDLC

The second approach to security testing is security as part of the development process. At Relevant, we know how important it is to have security in mind from the very start and test it throughout the software development life cycle. We’ve even written a very detailed article on it here. You’re more than welcome to check it out. 

Furthermore, see what are the best outsourcing destinations as well as benefits of outsourcing in Ukraine.

Secure your mobile application with Relevant

Mobile application security testing requires time, tools, and expertise. Luckily for you, Relevant has all of that in abundance.

Relevant can help you with black,- white,- and grey-box testing and vulnerability analysis, as well as testing cloud security and the code review of your mobile app. We also offer AppSec consulting, so go ahead and contact us if you have any mobile application security issues, questions, or concerns.