Be it social media, banking, shopping, or daily online transactions, we all depend on our mobile phones these days.

We often share our names, addresses, phone numbers, credit card details, and several other personal details daily, without thinking twice!

It is therefore extremely, EXTREMELY important for an app to have fool-proof security, or else it can jeopardize the sensitive information people trust the app to safeguard.

The stakes are even higher when it comes to banks, insurance companies, and marketplaces.

One breach in security and a company’s trust and reputation is lost forever. And yet, as per studies conducted by IBM, half of the companies had NO budget to secure their mobile apps. 

Not only that, their studies led to even more disturbing findings. Take a look:

Can you believe this? 

Imagine the kind of risk these companies are taking and the threat it poses.

We cannot have a callous attitude towards mobile security. Thankfully, we have OWASP to lead the way.

What is OWASP?

For the uninitiated, Open Web Application Security Project^® (OWASP) is a nonprofit foundation founded in 2001, which works tirelessly to improve software security. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.

OWASP Mobile Top 10

OWASP compiled a list that identifies the major security threats faced by mobile apps. This list called the OWASP Mobile Top 10, was last updated in 2016 and acts as the bible for developers across the globe.

An in-depth knowledge of the OWASP Mobile Top 10 is key to building safer apps and is mandatory for any mobile developer.

Risks and solutions for mobile app security

Let’s look into each of these risks and their solutions.

1. Improper Platform Usage

This category covers the 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.

Prevention: 

To prevent improper platform usage, secure coding and configuration practices must be used on the server side and client side of the mobile application.

Be sure that all the permissions you are using, are the ones that you absolutely need them. Many a time during development we end up adding permissions and forget to delete them before pushing the app. 

2. Insecure Data Storage

This severe risk covers all cases where the mobile phone has fallen into the hands of a cybercriminal, who can either gain physical access to the stolen device or enter into it using malware or a repackaged app. 

Prevention: 

As engineers, we tend to think only in terms of code quality but don’t obsess about the data collected to the same extent.  It is imperative to threat-model the mobile app to understand the information assets the app processes and how the APIs handle them. It is important to see how they handle URL caching (request and response), keyboard press caching, copy/Paste buffer caching, application backgrounding, intermediate data, logging, HTML5 data storage, browser cookie objects, and analytics data sent to third parties.

3. Insecure Communication

Data communication over mobile devices can be intercepted by hackers either through a compromised Wi-Fi network, tapping into the network through routers, cellular towers, proxy servers, or exploiting the infected app through malware. All such risks fall under Insecure Communication.

Prevention:

In order to prevent Insecure Communication, it is imperative that developers follow the following best practices:

• Assume that the network layer is susceptible to eavesdropping. Defensive programming and secure coding are the mantras that you should be chanting while your IDE starts up. 
• Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.
• Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.
• Use strong, industry-standard cipher suites with appropriate key lengths.
• Use certificates signed by a trusted CA provider.
• Never allow self-signed certificates, and consider certificate pinning for security-conscious applications.
• Always require SSL chain verification.
• Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.
• Alert users through the UI if the mobile app detects an invalid certificate.
• Do not send sensitive data over alternate channels (e.g., SMS, MMS, or notifications).

There are also certain iOS- and Android-specific best practices that can prevent these types of risks, but that is beyond the scope of this article. If you want to know more about this you can always get in touch with us and we’ll be more than happy to help. 

4. Insecure Authentication

Insecure Authentication occurs when a mobile phone allows anyone other than the original user to log into the app by faking or bypassing the authentication protocols.

Prevention: 

In order to prevent such a risk, we need to avoid the following insecure authentication design patterns:

• If you are porting a web application to its mobile equivalent, the authentication requirements of mobile applications should match that of the web application component. Therefore, it should not be possible to authenticate with less authentication factors than the web browser;
• Authenticating a user locally can lead to client-side bypass vulnerabilities. If the application stores data locally, the authentication routine can be bypassed on jailbroken devices through run-time manipulation or modification of the binary. 
• Where possible, ensure that all authentication requests are performed server-side. Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication;
• If client-side storage of data is required, the data will need to be encrypted using an encryption key that is securely derived from the user’s login credentials. This will ensure that the stored application data will only be accessible upon successfully entering the correct credentials. There are additional risks that the data will be decrypted via binary attacks. See M9 for additional guidance on preventing binary attacks that lead to local data theft;
• Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device;
• Ideally, mobile applications should utilize a device-specific authentication token that can be revoked within the mobile application by the user. This will ensure that the app can mitigate unauthorized access from a stolen/lost device;
• Do not use any spoof-able values for authenticating a user. This includes device identifiers or geo-location;
• Persistent authentication within mobile applications should be implemented as an opt-in and not be enabled by default;
• If possible, do not allow users to provide 4-digit PIN numbers for authentication passwords.

Reinforce Authentication

• Developers should assume all client-side authorization and authentication controls can be bypassed by malicious users. Authorization and authentication controls must be re-enforced on the server side whenever possible.
• Due to offline usage requirements, mobile apps may be required to perform local authentication or authorization checks within the mobile app’s code. If this is the case, developers should instrument local integrity checks within their code to detect any unauthorized code changes. See M9 for more information about detecting and reacting to binary attacks.

5. Insufficient Cryptography

If the encryption on a mobile app is weak or faulty, hackers can make their way into the device and access a user’s personal information. 

Prevention:

It is best to do the following when handling sensitive data:

• Ask yourself if you really need to store this data. Avoid the storage of any sensitive data on a mobile device wherever possible.
• Apply cryptographic standards that will withstand the test of time for at least 10 years into the future
• Follow the NIST guidelines on recommended algorithms. 

6. Insecure Authorization

A hacker may take advantage of vulnerabilities in the authorization process to log in as a legitimate user, thereby gaining access to a user’s personal information. Insecure Authorization should not be confused with Insecure Authentication (the fourth point on this list), in which the hacker tries to bypass the authentication process. 

Prevention:

In order to avoid insecure authorization checks, developers are required to do the following:

• Verify the roles and permissions of the authenticated user using only information contained in backend systems. Avoid relying on any roles or permission information that comes from the mobile device itself;
• The backend code should independently verify that any incoming identifiers associated with a request (operands of a requested operation) that come along with the identity match up and belong to the incoming identity;

7. Client Code Quality

Inconsistencies in code can provide lacunae for hackers to attack an app. Thankfully, such inconsistencies in coding are not that easy to catch and hence less prone to attacks from external sources. However, poor coding practices still leave a gap that can be exploited by an adversary.

Prevention: 

In general, code quality issues can be avoided by doing the following:

• Maintain consistent coding patterns that everyone in the organization agrees upon;
• Write code that is easy to read and well-documented;
• When using buffers, always validate that the lengths of any incoming buffer data will not exceed the length of the target buffer;
• Prioritize solving buffer overflows and memory leaks over other ‘code quality’ issues.

8. Code Tampering

Hackers always prefer tampering with an app’s code, as it provides them unlimited access to the app and the information contained in it. Usually, a hacker will nudge a user to download tweaked versions of popular apps from lesser-known app stores, after which their attack begins. 

Prevention:

The mobile app must be able to detect at runtime that code has been added or changed from what it knows about its integrity at compile time. The app must be able to react appropriately at runtime to a code integrity violation.

For an in-depth look into the remediation strategies for this type of risk, check out the OWASP Reverse Engineering and Code Modification Prevention Project.

9. Reverse Engineering

Hackers tend to use external, commonly available binary inspection tools, like IDA Pro, Hopper, otool, etc., to study the original app’s code patterns and its links with server processes.

Prevention:

In order to prevent effective reverse engineering, you must use an obfuscation tool. There are many free and commercial-grade obfuscators on the market. Conversely, there are many different deobfuscators on the market. For Android, you can use R8. There are other open-source tools available, in case you are looking for a more configurable alternative.  To measure the effectiveness of whatever obfuscation tool you choose, try deobfuscating the code using tools like IDA Pro and Hopper.

A good obfuscator will have the following abilities:

• Narrow down what methods/code segments to obfuscate;
• Tune the degree of obfuscation to balance performance impact;
• Withstand de-obfuscation from tools like IDA Pro and Hopper;
• Obfuscate string tables as well as methods

10. Extraneous Functionality

Prevention:

The best way to prevent this vulnerability is to perform a manual secure code review using security champs or subject matter experts most knowledgeable with this code. They should do the following:

1. Examine the app’s configuration settings to discover any hidden switches;
2. Verify that all test code is not included in the final production build of the app;
3. Examine all API endpoints accessed by the mobile app to verify that these endpoints are well-documented and publicly available;
4. Examine all log statements to ensure nothing overly descriptive about the backend is being written to the logs.

Conclusion

Everything’s gone online, but so has crime. With the knowledge of the most common risks mobile apps face and ways to counter them, we can only hope that in the near future, more and more companies give mobile security its due importance. It is just a matter of a change in attitude. Why wait for something terrible to happen and put your reputation on the line? We, at Akrity, treat Mobile app security as non-negotiable. Always have, always will.  

At Akrity we think of security that needs to be looked on continuously while the app is in production. Looking at it just like any other phase of your software development lifecycle will give you the right attitude and will help you to realistically be able to manage the challenges that you encounter. If you are in the process of adopting security standards after your attack on the server we recommend 2 steps that will greatly help you in adopting this new set of practices. 

1. Talk about security during your review meetings with a minimum cadence of twice a month. This will help developers think of security as and when they are developing.
2. Appoint a security person in charge from the development team who is responsible for looking into the logs/monitoring tools to audit and see if some new security issue is present that got missed previously. 

Adopting security changes is as much about consistency as it is about learning new tools. Building consistency will go a long way in adopting security as a process by everyone on the team. Spending smaller chunks of time spread across the calendar will give you more results compared to spending all the effort on the same week. Developers will get more aware and make it part of their existing testing/design discussions they are having. 

Are there any challenges you faced in adopting security best practices while developing an app? Tell us about it in the comments below and let’s discuss how we can fix them!