OWASP Audit: How to Make Sure Your App is Secure

The cost of data breaches to businesses in 2021 broke the record. The Cost of Data Breach Report, published by IBM, finds that the average cost of damage among respondents (537 companies in 17 countries) reached $4.24 million - the highest cost in the last 17 years.

Of the total number of incidents, 44% involved the personal data of users. Leaks pose huge reputation and financial risks. It is hard to forget the story of Facebook, which paid a record $5 billion fine for leaking users' private information. And Facebook is not alone - in the last year, Amazon, WhatsApp, Vodafone, and other giants have joined the club. These companies were fined for violating the EU General Data Protection Regulation.

You do not have to be a giant corporation to fear leaks or attacks just because you do not collect this much data. Data about an individual is the most valuable. IBM estimates that each lost record will cost the company $180 in 2021. This cost will only increase in the future. So you need to learn how to create a secure mobile application and avoid risks.

Identifying whether your app is safe

You can do the safety audit in several ways:

• Internal audit - conduct your own pen-test or analysis of the application's security;
• External audit - include cyber-security specialists in the audit.

Security analysis and pen-testing are two different things. During a pen-test, the attacker attempts to find a vulnerability and exploit it to cause maximum damage. In the security analysis, the goal is to cover as many threats as possible using the most tools.

Both tools, however, rely on the same requirements - the OWASP security standards. The Open Web Application Security Project (OWASP) is an independent, international, non-profit organization. OWASP compiles and publishes the top 10 vulnerabilities in digital products every year.

As an open initiative, the project issues no certificates. Even so, OWASP is today the standard in cyber-security all over the world. In order to assess the safety of your product, you should use the top 10 OWASPs. External
cyber-security experts also use these guidelines. Every three to four years, the rating is updated. Here's what it looked like in 2021:

FamilyGo experience: detecting threats and fixing them

Our security analysis of the FamilyGo mobile application will be used as an example to show what threats the scan can uncover and how they should be handled.

The application includes a GPS tracker, messenger, task manager, SOS button, radio, and baby monitor. In a nutshell, it provides everything you need to communicate with loved ones and solve everyday problems: monitor the safety of children and stay in constant contact with relatives.

No data is stored on the server, nor is it transferred to developers or third parties. Because all data is encrypted and stored on users' devices, only participants can access it. We want to create a completely secure space where loved ones can communicate without being invaded by strangers.

E2E encryption based on Signal protocol protects the transmitted information. Information is transmitted via asymmetric encryption - a pair of public and private keys is generated for the sender and recipient, without which the correspondence cannot be decrypted.

The private key is stored on the phone and is never shared. To get started, no phone number or other details are required. The application generates an anonymous login automatically after installation. Adding members to the chat is as simple as sending them an invitation code or scanning a QR code.

How the Audit was Conducted

An information security audit is essential to the project. We wanted to build an application that was as secure as possible. Thus, we decided to conduct a comprehensive analysis with the help of external experts.

Android and iOS versions, as well as the API, have been tested. All work has been done using a "black box." This means the cyber-security experts did not have access to the application code.

The audit revealed the following:

• 12 vulnerabilities in an Android application: 2 are high, 3 are medium, and 7 are low risk;
• 12 vulnerabilities in an iPhone application: one is high, 6 are medium, and 5 are low risk;
• the API used by the mobile application has 2 low-severity vulnerabilities.

Taking a Breath

This is where we pause to explain the meaning of these degrees of risk. Audits help both to identify vulnerabilities and to categorize them according to the level of risk they pose. OWASP defines three categories of vulnerability: high, medium, and low:

• High - Vulnerabilities can lead to remote access, the execution of arbitrary code by an attacker, and the disclosure of confidential information;
• Medium - Vulnerabilities have limited impact, but can be exploited to obtain sensitive information, which, when combined with other vulnerabilities, allows for remote access;
• Low - do not pose a direct threat, but can be utilized to collect information and develop attack vectors.

Everything is simple in theory. The application is unsafe if a vulnerability exists, and the issue needs to be resolved. A high vulnerability is very bad, you must act immediately. Low - also not very good, but tolerable, can be reduced to some extent. In reality, the audit results are much more complicated.

Vulnerabilities: causes, risks, and remedies

OWASP classifier is somewhat like a "spherical cow in a vacuum". It is a
great concept, but unreal. You can create a highly secure application by using the checklist above. The ideal patient, however, is a dead one.

Be prepared that vulnerabilities from the checklist that are related to your application's architecture and business logic will not be regarded as vulnerabilities when you check it against OWASP. Let's say you have a food delivery application that OWASP says is insecure because it includes a 4-character pin code. Although in terms of common sense, who needs an 8-digit password to protect a list of favorite cheeses?

The OWASP classifier found 12 vulnerabilities in the our application. Of these, only two were really serious and critical. Ten vulnerabilities could hardly be considered vulnerabilities: they either contradicted the business logic or could not be repaired conceptually.

Two critical vulnerabilities:

1. The password generation algorithm is insecure (medium risk). This vulnerability was associated with the generation of a random login value. We have changed the algorithm to completely prevent data repetition;
2. Storage of sensitive data in local storage is insecure (high risk). Using this vulnerability, the auditors were able to access the database on the phone using the key that was stored in the RAM. We have fixed this problem by changing the mechanism and making it dynamic.

Major Outcomes

Here is a summary of what the audit found and what problems were corrected. The audit identified 12 vulnerabilities:

• one obsolete component - was not repairable;
• two superuser rights and ROM data - partially fixed;
• nine threats were completely fixed, despite the inconsistencies, redundancy, and apparent failure of these threats on our application.

Why did we do that? Our team felt it was crucial to create a product that protects user data as much as possible. There is no 100% secure, unhackable application. When you pick up your phone or log on to your computer, the threat immediately appears. In this case, only the cost of hacking determines the level of security.

The more difficult it is for an attacker to gain access to your data and the more expensive the attack, the more secure the application. When a super level is achieved, it is easier to take you captive and find out everything on your own than to break all the defense systems.

In the light of our security analysis and the results of the study, we can proudly state that FamilyGo has nearly reached the point where hacking is pretty much meaningless - accessing user data is too expensive.

Conclusion: A few tips for securing your app

• Tip #1 - increase your own expertise. As practice shows, an external audit may not always be relevant to your project. Train developers and help them improve their skills. Create internal checklists and standards before every release.
• Tip #2 - monitor the situation constantly. If a new function is implemented, immediately check whether it meets the requirements, if there is a memory leak. Check for updates to the operating system and libraries at least once a year.
• Tip #3 - don't neglect external evaluation. You shouldn't assume that the OWASP requirements don't correspond to reality at all, and you can do it on your own. In addition to looking at the product from the point of view of business logic, it is also necessary to consider it from an independent standpoint. A comprehensive audit can help you identify the shortcomings you might not have noticed otherwise.
• Tip #4 - get ready to invest. At least 30% of the budget should be allocated to the development of internal competencies, the hunt for security specialists, penetration tests, and analyses. Our own experience shows that security is indeed very expensive. When you work with the product, keep this in mind, because hackers can cause much more damage.