Emerging cross-platform technologies

(1)

Emerging cross-platform technologies

Implementation and evaluation from a security perspective

Marius Christensen

Thesis submitted for the degree of

Master in Programming and System Architecture 60 credits

Department of Informatics

Faculty of mathematics and natural sciences

UNIVERSITY OF OSLO

(2)

(3)

Emerging cross-platform technologies

Implementation and evaluation from a security perspective

Marius Christensen

(4)

Emerging cross-platform technologies http://www.duo.uio.no/

Printed: Reprosentralen, University of Oslo

(5)

Abstract

Mobile applications are considered to be a fundamental tool we use for hours every day. In just a decade, it has changed many of the small things we do each day, connecting people in new ways across our world.

Mobile phones have in the last decade grown to be a ubiquitous accessory, where consumers can choose between several different ecosystems. For businesses, this means that more resources are needed to build separate applications since the tools and technologies are unique for each platform.

As a consequence, cross-platform applications have emerged.

This thesis investigates and presents common security pitfalls and risks for developers using such frameworks. It is done through Proof of Concepts applications comparing available methods for developers in both the native and web-based approaches. A major part of this thesis is devoted to an analysis of the current solutions. It is done to explain some of their limitations, in addition to some of the proposed best native and web practices, with the ultimate goal of increasing the overall security in applications on mobile phones. The consequences and impacts of these security mechanisms are discussed extensively, followed by suggestions on how to improve. Although a great portion of the attack surface lies on the network or back-end, this will need to be implemented correctly.

Hopefully, others find this study valuable in picking an appropriate approach and, optimistically, inspire other researchers to further explore the challenges for cross-platform mobile applications.

Keywords:Secure app development, Ionic, Apache Cordova, Cross-platform

(6)

(7)

Acknowledgements

This thesis concludes my master’s degree in Informatics: Programming and System Architecture with the Department of Informatics at the University of Oslo.

First and foremost, I want to give my greatest gratitude to both my supervisors Audun Jøsang and Lillian Røstad for supervising me for this thesis.

Writing a thesis is a challenging adventure. A huge thanks to my friends and fellow students, for the last five incredible years at the University of Oslo. Shout-out to all the interns at Start UiO for all the memorable and fun trips we have had. Thank you, Håvar, for excellent support during this period and the opportunity to exchange knowledge, thoughts, and experiences. Thanks to my friends outside of school who have been patient with me while I have been writing this thesis.

I would also like to thank my upcoming employer, Sopra Steria, and colleagues for guidance and for giving me the great opportunity and the idea for this thesis when I worked on a project related to this topic.

Finally, the biggest thanks go to my family and wonderful girlfriend for supporting me through a stressful and hectic period. This will, hopefully, be the last time we fully renovate our apartment while I write a master thesis. I am forever grateful for your continuous support.

I hope you, as a reader, find this thesis interesting and that it offers you some insight into the field of secure mobile application development.

Marius Christensen University of Oslo November 2019

(8)

(9)

List of Figures

1.1 Simplified architectural overview. . . 5

2.1 A look at how the two frameworks differs in rendering. . . . 15

2.2 Comparison of development team structures. . . 17

3.1 WebView and Cordova connects OS functionallity. . . 20

3.2 Architecture of applications using Cordova to tap into native functionality. . . 21

3.3 Example showing how tokens can be misused. . . 23

3.4 Two different ways biometric authentication calls can be performed. . . 23

3.5 Authentication request flow. . . 27

4.1 The research process as adapted from Rummel and Ballaine (1963). . . 39

4.2 Risk rating hierarchy model. . . 43

4.3 MASVS requirement levels and their meaning. . . 44

5.1 Confidentiality, integrity and availability, also known as the CIA triad. . . 50

5.2 Onboarding process pages. . . 55

5.3 Application content pages. . . 55

5.4 Security architecture diagram of iOS (Apple, 2019). . . 59

5.5 Contents of the JWT used in the Master Bank implementation. 62 5.6 A snippet from the obfuscated code from auth.service.ts. . . 68

6.1 Overview of how the different parts of the OWASP project are related. . . 73

6.2 List of requirements and the corresponding level it satisfies. The full list of requirements used in this thesis can be found in appendix A. . . 73

6.3 Firebase’s use of local storage. . . 76

6.4 Encrypted TLS v1.2 traffic inspected with Wireshark. . . 76

(14)

6.5 Error shown (in Norwegian) due to SSL pinning. . . 77 6.6 Remote code execution vulnerability found during testing. . 78 7.1 Mobile Security Checklist compliance score for the test results. 90

x

(15)

List of Tables

2.1 Overview of features supported in different mobile app approaches. . . 9 2.2 Platform Idiosyncrasies between iOS and Android. . . 11 2.3 Benefits and downsides of cross-platform development . . . 13 2.4 Comparison of frameworks in cross-platform development. 14 3.1 OWASP top 10 mobile . . . 20 3.2 Cryptographic algorithms that are known to be weak and

should be replaced by more secure alternatives. . . 27 4.1 Functionality and functions that often contains flaws and

could be a good reference in a Forensic Analysis. . . 42 4.2 Overview of common attacks on mobile devices and its

infrastructure . . . 46 5.1 Functional and non-functional requirements. . . 53 5.2 Comparison between stateful and stateless authentication. . 62 7.1 Likelihood and impact levels . . . 88 7.2 Test results from the eight different categories. . . 89 B.1 Severity listed for each of the requirements. . . 110

(16)

(17)

List of Acronyms

The page number refers to the first use of the acronym.

API Application programming interface . . . 2

BaaS Backend-as-a-Service . . . 83

CORS Cross-Origin Resource Sharing . . . 75

CVE Common Vulnerabilities and Exposures . . . 66

CVSS Common Vulnerability Scoring System . . . 66

DAST Dynamic Application Secuirty Testing . . . 41

IAST Interactive Application Security Testing . . . 41

IDE Integrated Development Environment . . . 56

IdP Identity Provider . . . 60

JSX JavaScript XML . . . 14

JWT JSON Web Token . . . 60

MAC Message Authentication Code . . . 28

PoC Proof of Concept . . . 2

RCE Remote Code Execution . . . 78

SAST Static Application Security Testing . . . 40

SDK Software development kit . . . 2

SDLC Systems development life cycle . . . 43

TLS Transport Layer Security . . . 26

(18)

(19)

Chapter 1

Introduction

"Software is like entropy: It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics;

i.e., it always increases."

— Norman Augustine Nowadays, mobile applications are considered to be an essential part of our daily life. In just a decade, it has changed many of the small things we do each and every day across our world. People have adapted their habits of how we create, share, and communicate with each other. To understand the value of this revolution, which is considered to be roughly 12 years ago with the introduction of the first iPhone, we should look at how our everyday life has changed and thus how we have changed with the new flow of information available. One could argue that much of the success of the modern smartphone lies 1.8 million mobile applications connecting users and enrichening their lives. Now, more then ten years later, the primary user-mobile interaction is still app-centered. While some predict that in the next mobile revolution, we will see action-based interactions replace this. However, we are not yet there.

Just like in the early days of the landline phone, we need an operator to connect us to someone - the same is true with the current offering of apps.

The installed app is like the middleman to help us complete an action since the content is essentially locked inside the app (Perrin, 2017).

Mobile applications are considered to be a fundamental tool we use for hours every day. In just a decade, it has changed many of the small things we do each day, connecting people in new ways across our world.

Mobile phones have in the last decade grown to be a ubiquitous accessory, where consumers can choose between several different ecosystems. For businesses, this means that more resources are needed to build separate applications since the tools and technologies are unique for each platform.

(20)

Chapter 1

As a consequence, cross-platform applications have emerged, promising a solution where developers can use the same technologies and tools across different platforms (Eskola, 2018).

This thesis investigates and presents common security pitfalls and risks for developers using such frameworks. It is done through Proof of Concepts (PoCs) applications comparing available methods for developers in both the native and web-based approaches. A major part of this work is devoted to an analysis of the current solutions that explain some of their limitations, in addition to some of the proposed best native and web practices, with the overall goal of increasing security in applications on mobile phones.

Two PoC Mobile applications were created for this master project. The PoCs exposes many common attack vectors, as detailed in Section 3.3.

Besides, the thesis discusses how the PoCs ranks on a set of recognized security assurance levels across different domains. The consequences and impacts of these findings are discussed extensively, followed by solutions or suggestions for improving security. Although a great portion of the attack surface lies on the network or back-end, this client-side frontend must be done right.

Hopefully, others find this study valuable in picking an appropriate approach and, optimistically, inspire other researchers to further explore the challenges for cross-platform mobile applications.

1.1 Personal Motivation

As I write this thesis, I am like most people surrounded by devices connected to the internet; laptops, watches, audio-systems, phones and more. For the past decade, I have closely been following various mobile developer conferences with big eyes. Like many others, I was blown away years ago with the introduction of mobile Software development kits (SDKs), which let developers create new experiences for people that simply weren’t possible before. I remember being amazed by the thought of potentially reaching millions of people easily with an idea through the phone. Still, in my early teens, I was making small games during the weekends, passing them along to friends on USB drives during recess.

I never made it to the slightly more complicated mobile world at that time, but the interest for has been there all along. As years have passed, the technologies and Application programming interfaces (APIs) have matured and aged - so have I. Last summer, I was so fortunate to be given the opportunity to work on a cross-platform project at Sopra Steria.

2

(21)

Introduction

It really sparked my interest and let me see just how accessible these technologies have made mobile application development for someone only having experience with web development – which is probably a lot more than mobile.

Stepping into the consulting world, it is easy to see how creating regular applications for the most common platforms requires a lot of resources since it is needed to write the same code twice. Due to variations in languages, dependencies, and architecture styles having the application run on the same codebase is simply not possible. Multiple frameworks interestingly try to address these problems.

During my years here at the University of Oslo, I have had many conversations with fellow students and professors that have fueled my interest. I feel fortunate to have met so many dedicated people; some are eye-opening privacy advocates, other great technical security experts.

Thanks for all the fun, hypothetical, and weird discussions we have had.

All of whom have led me towards choosing such a topic. It was somewhat inclined I was to combine my passion with academic research.

Writing this thesis conducts my five-year learning adventure, but I am well aware the technologies and best practices are always changing.

Probably a few times just by the time of writing this thesis.

1.2 Objective

In this thesis, I wish to dive into the field of modern application development. Aiming to explore the different security concerns we need to consider when using cross-platform development tools. I want to investigate through research and development how to properly implement security measurements and potentially uncover weaknesses, as well as to promote better and more secure practices.

1.3 Research Question

Based on the outlined problem area, the research question of this thesis is:

Which security challenges exist for a favored mobile cross-platform framework and what security concerns are relevant when developing for it?

To answer this research question, the objectives of this thesis are:

(22)

Chapter 1

1. Investigate if there are specific challenges related to the cross- platform framework in general, and how the development and implementation of the needed security mechanisms best can be done.

2. Design and develop a prototype application for the chosen cross- platform approach that solves the commonly known attack vectors found in a secure manner.

3. Test and evaluate the process and its findings through an established testing standard used in the industry as a means to identify potential weaknesses that would fit into discovery to answer the research question.

This thesis aims to answer the research question above. A conclusion to this question can be found in Chapter 8.

1.4 Scope

The main focus of this thesis will be on the available security mechanisms provided in the two different PoC concepts. Security-wise this has to be treated as a front-end that provides minimal security by itself. It is important to point out that the back-end and network, shown in Figure 1.1, is just as essential to secure and test, even though it is not given much attention in this thesis. As described in Section 2.3.4, the focus in this thesis will be on a few selected technologies, while in fact, there are a lot of promising cross-platform technologies available as presented in Section 2.3.1.

In the phase of initial research, the majority of related research found particular concerns in, e.g., protocols or deprecated software. However, limited research has been published regarding the field of cross-platform technologies and security, especially in the setting of mobile devices.

The problem areas presented are intended for single developers to medium-sized developer teams in mind. Some of the obstacles presented probably can be overcome with enough resources and time, but it would certainly not be feasible for most. The design principle, "If it is not available for me to see, it is not there." for implementing security measurements holds true. The evaluation is also done from a standpoint where we assume it is not beneficial or worthwhile to write a lot of low-level or strictly native Objective-C/Swift or Java code to achieve expected goals.

4

(23)

Introduction

Figure 1.1:Simplified architectural overview.

1.5 Thesis structure

Chapter 2: Background describes prerequisite information I find essential for the reader to understand before handling the main body of the thesis, as well as relevant concepts in mobile security. I also describe how cross-platform application fits into the context of modern mobile application development.

Chapter 3: Deploying a technical framework presents an introduction to the security landscape, literature, and the historical background.

Several domains are introduced that forms my theoretical framework for addressing security testing in cross-platform frameworks.

Chapter 4: Methodology introduces my research method, along with techniques for testing and risk assessment. The general approach is presented along with important distinctions. Lastly, relevant principles for the tools needed are described.

Chapter 5: Implementation presents the goal, requirements, and architecture for the system. As well as the technical implementation and issues met.

Chapter 6: Testing presents how these applications are evaluated against the criteria set and the OWASP Mobile Application Verification Standard.

Chapter 7: Findings & discussion presents findings uncovered by the project, reflections on the process, and its findings. The discussion is divided into recommendations for improvement and risk analysis.

Chapter 8: Conclusion summarises the thesis, and my contributions, I argue, would be of interest to both the broader community of cross-

(24)

Chapter 1

platform development. As well as suggesting further research in securing such systems.

6

(25)

Chapter 2

Background

This chapter will describe prerequisite information I find important for the reader to understand in order to follow the main body of this thesis, in addition to some background context. This chapter is divided into three sections:

1. A brief historical background of mobile phones and security (Section 2.1).

2. Native application development (Section 2.2).

3. Presentation of cross-platform frameworks and technologies (Section 2.3).

2.1 A brief historical background

Nowadays, almost 70% of all Internet users access the Internet using mobile devices like smartphones or other mobile computers (Gröger, Silcher, Westkämper and Mitschang, 2013). Apps on these devices are becoming the core of digital life and are used, e.g., for communication, news, shopping, as well as accessing our bank accounts. Due to consumerization, that is, consumers, bringing their own mobile devices everywhere, and the increasing need for mobility and flexibility, apps are gaining more and more attention in business and everyday life. Mobile internet usage already surpassed traditional desktop usage back in 2016, measured in percentage of global web traffic visits (Enge, 2018).

While mobile devices share many security concerns with desktop computers, they are by nature different in the way that makes them so convenient for people; their mobility. Organizations are seeing growing needs for their devices and data infrastructure. The bring- your-own-device approach sets new requirements on how businesses

(26)

Chapter 2

address device management, cross-platform support concerning security (Jaramillo, Newhook and Smart, 2013). Even back in 2005, it was suggested that, in business scenarios, over 80% of new and critical data is available or stored on such devices (Allen, 2006). There are few reasons to believe these numbers have decreased with the rapid growth of computing power in mobile phones over the last decade. Mobile devices have become highly capable, but they are by nature more vulnerable to threats such as theft and accidental loss than devices in fixed locations (Su, Chen, Kuo and Tseng, 2014).

The cost of mobile devices has increased over the years. Most models are relatively expensive and if it were to be unavailable it would expectedly be a major inconvenience. Moreover, when we address the security of such devices, it is crucial to be aware of what kind of information is stored or accessible on these devices because they contain large amounts of sensitive data that can be lost or fall into the wrong hands. These data may include personal photos and videos (76%), personal email correspondence (64%), passwords to social network and email accounts (22%), work emails (32%), business documents (20%), and financial information, specifically, passwords to online banking accounts (10%). This will most likely cause a significant inconvenience (‘Security in a Multi-Device World: The Customer’s Point of View’, 2013).

2.1.1 The state of mobile security in 2019

In recent years approximately 70 million smartphones are lost each year (Kensington, 2011). Another report claims that in the USA alone, 113 cell phones are lost or stolen every minute (Schweber, 2013). Note that these reports are written years before anti-theft systems became common.

Studies have also looked at the potential risk, as these devices by their nature, are inherently more likely to get lost or stolen. Which may have the following consequences: (1) loss of the device i.e., the potential for physical property loss, (2) loss of data i.e., the potential of being unable to access needed data and giving others potential access to such data, and (3) loss of service access. i.e., losing the ability to access needed applications remotely and potentially allowing unauthorized access to such applications (Tu, Turel, Yuan and Archer, 2015).

The two most common types of mobile operating systems today are iOS from Apple and Android from Google. While iOS is only used on iPhones and iPads, Android is compatible with a variety of phones from different manufacturers. These flavors of the Android operating system are

8

(27)

Background

often extended upon by the manufacturer, adding complexity and a longer pipeline i.e., slower security updates. Both companies show conscientious efforts to make the operating system secure. However, they have quite the different philosophy regarding privacy and control. While Apple keeps the App Store under tight review, the Google Play Store is more open and known to have greater number of applications with dubious intentions.

None of them is however perfect.

Gartner estimated that in the year 2022, 70% for all enterprise software interaction is expected to occur in mobile devices (2013). Today, having a mobile-friendly application is almost expected. If it is available on desktop, people expect to have access on their mobile devices along with the data, giving them the freedom to do much of the same on the go.

2.2 Native applications

Table 2.1:Overview of features supported in different mobile app approaches.

There are some fundamental differences between webview application and native, as seen in Table 2.1. Firstly, native applications are considered to be superior with regard to performance to webview since they do not rely upon the browser’s engine to display content.

(28)

Chapter 2

Since native applications are written for a particular device or platform, they are using platform-specific languages. Applications for iOS are written in Swift while applications for Android are written in Java.

This prevents code from being reused between the different platforms, which increases the time needed to create the applications since the entire codebase has to be rewritten for every platform (Abrahamsson and Berntsen, 2017).

Native apps have the benefit of access to the capabilities of the device. It is possible to send push notifications, leverage the hardware on the devices, like GPS for location-based services, along with advanced camera systems with augmented reality support, and more. The great benefit is that features and security fixes become immediately available¹to developers as they are released. However, with different operating systems and devices, which require different source codes to run natively, targeting a mobile audience is not always as simple as just creating a mobile version of a site (‘Cross Platform Apps Development’, 2019). As shown in Table 2.1, there are both benefits and drawbacks for each different option. It is essential to keep in mind that the decision should be based on the circumstances for a given project, the team, and the requirements. Later in this paper, we will look into more detail of what the current landscape of security on mobile devices is like since developing using native SDKs is no longer the only viable option.

These other options need to ensure proper coverage of the two most popular and deployed mobile OSes: iOS and Android. While these platforms have many similarities for users, there is a need to identify critical differences in architecture and configuration to provide uniform coverage across both platforms. Platform Idiosyncrasies that might affect security can be seen in Table 2.2.

2.2.1 iOS

Key facts about Apple’s mobile platform:

• Over 1 billion active iOS devices in the world.

• 2.2 million apps are available via the Apple App Store.

• Newest OS, iOS 12, has over 87% adoption.²

1The android ecosystem is known to be reliant on phone manufactures to implement the updates, which slightly slows down the process and causes version fragmentation.

2As measured by the App Store on May 30, 2019.

10

(29)

Background

2.2.2 Android

Key facts about Google’s mobile platform:

• Over 1.5 billion active Android devices in the world.

• 2.6 million apps are available via Google Play.

• Newest OS, Android 9 (Pie), has less than 11% adoption.³

iOS Android

App Transport Security Inter Process Communication Touch/Face ID

World Readable, World Writeable, World executable files Local Authentication Obfuscation

Keychain Java Crypto Architecture Stack Smashing

Table 2.2:Platform Idiosyncrasies between iOS and Android.

How should the developers best perform security testing for iOS and Android when taking system architecture and idiosyncrasies into account?

2.3 Hybrid app frameworks

This is where hybrid and cross-platform technologies come in. These apps can run on more than just one platform at a time, without developers having to create separate versions of their code. A recent survey by Forrester found that two-thirds of mobile developers are choosing a web- based approach over native tools (2019). There are essentially three different kinds of mobile applications; native, web, and hybrid applications (Abrahamsson and Berntsen, 2017). This thesis focuses on the hybrid approach that can further be divided into two categories.

Hybrid appsare essentially written as a web application, using standard web technologies like HTML, JavaScript, and CSS, that are embedded within a native wrapper. Allowing it to run on any device while bypassing the restrictions common browser websites (‘Cross Platform Apps Development’, 2019). I.e., they can access a device’s hardware and tap into the mobile operating systems native code to use, e.g., biometric

3Data collected by Google on May 7, 2019.

(30)

Chapter 2

authentication, normally not available through web APIs. This architecture allows for an excellent amount of code reuse, reduces the same, and makes the technology stack available to a broad audience of developers who have no previous experience with mobile. Regardless of these benefits, the approach has been found to raise security concerns related to the way the browser tap into native functionalities (Hale and Hanson, 2015).

Native apps created by cross-platform development tools. These are written in a cross-platform language that compiles a single app source code into native code that will run on different operating systems. It is a more native feel than a hybrid app, but we are still only working with one codebase (‘Cross Platform Apps Development’, 2019).

The advantages to this are that we do not need to hire developers who are specialized in each platform, building the same apps for each with entirely different codebases, and then maintaining and updating those separate versions with the same features. This can be complex, expensive, and time-consuming, which leads to longer development cycles if we try to keep functionalities across platforms in sync. Typically there is a need to maintain two teams with expertise on each platform, which naturally could lead to a higher cost. Of course, this approach does not come without its drawbacks either, and I would like to point out three of them.

• It will increase the system overhead by running in the WebView that might be missing the performance and security features.

• Reliance on third-party plugins. While hybrid apps are able to access nearly every native feature, it requires open source software such as Cordova to do so, and it does add complexity.

• This also means that there are framework dependencies. Choosing this approach means placing trust in the framework community that maintains it in order to keep up with the latest features and security fixes. While it is in everyone’s interest to keep up with the new Android and iOS versions, there is an added layer and a factor to consider nonetheless.

All this is made possible through a collection of simple, abstracted interfaces that enable us to focus on homogeneous features and business logic rather than on cross-platform idiosyncrasies.

12

(31)

Background

Benefits Downsides

Code reusability Limited feature support Cost-effectiveness Performance

Consistency in UI Components Not optimal platform specific UX Fewer language barriers Dependent on framework updates Shorter time to market Available tools may not be enough

Table 2.3:Benefits and downsides of cross-platform development

2.3.1 Available frameworks

In the preparation essay leading up to this work, I looked at several promising cross-platform frameworks. The results can be seen in Table 2.4. While I wont to restate all the results found, two of the approaches to cross-platform development seemed particularly interesting.

• Ionicis built by a startup from Silicon Valley. Most of the project is open-source, while they capitalize on a few selected features geared towards enterprise customers. In some way, the project looked at as an evolution of Apache Cordova and PhoneGap. Historically the same components were used to enable the webview application to tap into native functionalities of the different platforms. The framework inherits most of its technologies from the web since the application is rendered in the webview. Premade components that resemble the native functionality of the platform are pre-made with HTML, CSS, and JavaScript. Since running an application in the webview is the most platform-agnostic approach that exists it allows for a great amount of code reuse while also being an accessible technology for most.

Some disadvantages to the Ionic framework found is that knowledge of Angular becomes almost a necessity. While version 4 aims at being platform-agnostic with support for frameworks such as React or Vue, it is still limited in functionality. Also, things such as designing in-app navigation are complex, and extending functionality beyond plugins available requires knowledge of native code.

As many as 35,609 applications use Ionic as of 2019.⁴ It is also the most budget-friendly framework among the described, thanks to its web nature.

• React Nativeis built by Facebook and licensed under the MIT-licence,

4According to SimilarTech (https://www.similartech.com/technologies/ionic).

(32)

Chapter 2

Table 2.4:Comparison of frameworks in cross-platform development.

meaning that it is also open source like Ionic. The language is JavaScript-based, with its own set of syntax named JavaScript XML (JSX). The framework gets much traction from React used on the web, and companies could potentially reuse some code and components if their mobile application shares similarities in functionality with the web. Unlike frameworks like Ionic, the canvas is rendered naively, i.e., not in a webview, meaning that it has several performance benefits and is considered to be fast. It is built on the principle of components so that both the iOS and Android versions can look the same. This can both be a benefit or a drawback depending on whether the goal is resembling platform-specific design principles and feel or its own. As much as 96% of the code is platform agnostic and can

14

(33)

Background

be shared between the platforms, saving up to potentially 40-70% in development expense.

The real benefit of React Native is the growing community and that the main logic of the react-native can be shared between web, mobile, and desktop applications.

(a)Ionic rendering (b)React rendering

Figure 2.1:A look at how the two frameworks differs in rendering.

2.3.2 Evaluation of Ionic

If we do not consider Ionic’s enterprise product Ionic Pro, it is the most budget-friendly framework among all the different frameworks. It is easy to pick up for someone with experience from the web, making it a choice to consider for many. While it is slightly behind strictly native in performance, it comes with many benefits and few hindrances. It gives the developers much more flexibility when it comes to design since it is using CSS, while also having a pre-made library of native-looking components. Security- wise, the application is running in a modified Apache Cordova webview, as shown in Figure 2.1a. This allows the application to call native code from within the container using an already huge and growing library of JavaScript plugins to make calls to system components such as biometric authentication.

Up until very recently, Ionic was strictly tied to Googles Angular framework. However, with release 4.0, it has become platform-agnostic

(34)

Chapter 2

- allowing developers to choose between front-end frameworks such as React or Vue, making it a good fit for code reusability if the company already has components for the web. It is also worth to mention that developers can take advantage of the many packages in npm⁵ in the web environment. Which of course, makes life more comfortable, but also poses a risk as it might be unknown or vulnerable third-party packages. There have also been numerous flaws found in well known and wildly used packages. Besides, vulnerabilities may propagate in dependent packages of modules, making them vulnerable too (Decan, Mens and Constantinou, 2018).

2.3.3 Evaluation of React Native

React Native will, at this time, be the first framework many consider when building new experiences for mobile. As shown in Table 2.4, it allows for a great amount of code reuse while giving users smooth native animations and experiences. It is backed by Facebook that uses it for its main application, Instagram, and Messenger, so there is proof it can scale well. It is also chosen as the core technology behind both the VoIP applications Discord and Skype. It shows that it is a matured technology that can deliver great experiences to millions of people. React native is also by far the most popular framework, as measured in GitHub Stars, and has a huge community with lots of support. On the other side, there might be a lack of visibility into such a large company that can bring frustrations when so many people depend on their contributions and maintenance.

Security-wise it shares many of the same concerns as Ionic out of the box. It is also a JavaScript-based library, and an application that needs type A security, like a banking or medical app, will require extra attention since JavaScript is known to bring some weaknesses, especially from third-party code.

2.3.4 Summary of frameworks

At the time of writing this, the choice seems obviously to be between the two latter frameworks. Adobe PhoneGap is beginning to look like a dated technology with the best plugins being made available to Ionic trough Apache Cordova. Xamamarin is costly as a student, and the learning curve seems too steep unless you pursue a professional career. Flutter looks like an auspicious choice in the future, and while still new, it has gained

5npm is a package manager for the JavaScript programming language. It is the default package manager for the JavaScript runtime environment Node.js.

16

(35)

Background

Figure 2.2:Comparison of development team structures.

a lot of momentum in a short amount of time. However, I still consider React native and Ionic the better choice in this scenario. I would also like to mention that I have some limited experience from working with Sopra Steria’s timesheet application that uses the Ionic framework.

(36)

(37)

Chapter 3

Deploying a theoretical framework

Part of this chapter contains information about threats for mobile applications, hybrid applications, and the mobile application platform in general.

After that comes apart with theory about application architecture, security theory, and modifiability¹for adapted web security controls. The chapter also contains some theory I find useful to include before presenting the methodology.

3.1 Common mobile attack surfaces

Different technologies introduce different attack vectors, so is true for mobile technologies. Security challenges for mobile deviate from regular applications in some natural directions. Since the mobile platform expands to the variety of functionality available there are additional concerns to consider. Such as storage, cryptography, platform communication, and sensors (Schleier, Mueller, Willemsen and OWASP, 2019). Considerably, the conventional understanding might be that the mobile platform is less prone to attacks than traditional desktop operating systems, however, deficiencies might manifest if security is not taken seriously during the mobile development process.

Almost every application talks to a back-end service, and those services are prone to the same types of attacks we are familiar with on web and in desktop environments (Schleier et al., 2019). Mobile client-side applications differs in that there is a larger attack surface because it has a lot of sensors and hardware functionality that other computer platforms do not have.

1Modifiability is the degree of ease at which changes can be made to a system, and the flexibility with which the system adapts to such changes.

(38)

Chapter 3

As so, it inherently contains sorts of sensitive data lucrative to bad actors.

The security landscape, therefore, reflects these kinds of threats, i.e., data protection on the device is essential.

1. Improper Platform Usage 2. Insecure Data Storage 3. Insecure Communication 4. Insecure Authentication 5. Insufficient Cryptography 6. Insecure Authorization 7. Poor Code Quality 8. Code Tampering 9. Reverse Engineering 10. Extraneous Functionality

Table 3.1:OWASP top 10 mobile

3.1.1 Cross-platform attack surfaces

Figure 3.1:WebView and Cordova connects OS functionallity.

An example of a more hybrid-specific attack is inherent on the Apache Cordova architecture. The cross-platform hybrid mobile framework manages the connection between the native layer and the embedded web browser component. It enables the JavaScript applications to communicate with the native application programming interfaces (APIs) to access native resources, such as the network, camera, GPS, and contacts. Besides, several components provide capabilities to control and set up the communication channel between the embedded web browser and the hosted native app

20

(39)

Deploying a theoretical framework

component, as shown in Figure 3.1. This can be dangerous because this breaks the sandbox generally enforced by the browser. Shehab and AlJarrah successfully demonstrated how this could be exploited in the Android operating system and potentially harm victims in the millions with a large scale attack (2014).

According to Brucker and Herzberg, hybrid apps pose several challenges from a security development perspective (2016). We need to be aware that, e.g., an XSS attacker becomes much more powerful as attackers might be able to break out of the JavaScript environment and inject code that is executed in the context of the native part of the app, increasing the damage potential. The combination of web technologies and native mobile code is not yet supported by state of the art automated security testing tools in general and static application security testing (SAST) tools in particular (Brucker and Herzberg, 2016). Bessey describes SAST tools as the back- bone of a holistic security testing strategy and it is widely used in the software industry (Bessey et al., 2010). He further suggests that one solution to this problem could be to develop a static code analysis approach that sup- ports hybrid mobile apps developed using Apache Cordova (Brucker and Herzberg, 2016).

Figure 3.2:Architecture of applications using Cordova to tap into native functionality.

As previously stated, several cross-platform frameworks implement Cordova libraries, but the far most used nowadays is the Ionic framework, which is a framework that uses the Cordova engine as a middleware that provides APIs to establish communication channels between native code and JavaScript. The Cordova library defines the native (Swift for iOS and Java for Android) to JavaScript interfaces through the WebView

(40)

Chapter 3

interface. The native library provides native APIs that are developed as abstract classes, which are referred to as plugins, as shown in Figure 3.2.

These plugins include the both set of native code required to access device resources such as location services, camera, and storage (Phung, Mohanty, Rachapalli and Sridhar, 2017).

There are many threats associated with using WebViews in mobile apps like cross-site scripting, excess authorization, file-based cross-zone scripting, weakening of TCB and sandbox to mention a few (Bhavani, 2013) (Luo, Hao, Du, Wang and Yin, 2011) (Chin and Wagner, 2014). The WebView interface and URL loading methods can easily be exploited to introduce back channels to give access to malicious apps (Luo et al., 2011).

As shown in Figure 3.2, it is theoretically possible to take advantage of the Cordova API to access and exploit native OS functionalities, i.e., gaining access to sensors and secure storage, that would otherwise be off-limits in a sandboxed environment.

Several security measurements can be implemented to mitigate the risk of such attack vectors; however, in general, adding an existing layer on top of native shell broadens the possible attack surface and further complicates the codebase. There is an OWASP Security by design principle that states we should keep security simple and minimize the attack surface area.

Having this additional layer could add security concerns beyond what typical web developers would be familiar with if such feature plugins are to be used or developed in-house.

According to the most recent Stack Overflow Survey, only 6.5% of all developers cited Swift and Objective-C as familiar languages (languages used explicitly for native development on iOS and Apple’s ecosystem).

While in contrast, web developers made up 72.6% of respondents, and JavaScript appeared as the most commonly used programming language in the survey (Stack Overflow Developer Survey, 2018) (Introduction to cross- platform hybrid development for architects, 2018). While this makes a great argument as to why companies could benefit from the approach and use the existing knowledge of their developers, it is, however, scary from a security point of view. As shown in Figure 3.1, these plugins use native APIs and third-party libraries that would not be familiar.

Furthermore, these plugins tend to be made available at the global scope of the application and called from anywhere, thus breaking the principle of least privilege (POLP). However, according to Shehab &

AlJarrah, an effort has been made to circumvent this by mocking the cross- language call interface, by automatically pre-processing the JavaScript source code, where the core idea is to search for all Cordova execution calls

22

(41)

and replace them with a call to a callback handler (Shehab and AlJarrah, 2014). While this is a paper theory and could be a solution, it is not established as a secure default nor seem to be a widely adopted practice throughout the developer community.

Figure 3.3:Example showing how tokens can be misused.

OWASP MASVS recommends following the platforms recommended best practice for using secure storage. As shown in Figure 3.3, this is a typical scenario where we want to securely store an authentication token natively on the device with, for instance, the Cordova plugin for secure storage, and avoid relying on the browsers localStorage (Chen et al., 2014). In addition to this, a typical application would need as many as 11 plugins for the authentication process. These plugins used together have an imminent flaw in the way that they are separated and do not talk to each other. Figure 3.4 shows a pseudocode example of how one could program this functionality using separate plugins. In the first line, an attacker could override the biometric function to always return true, and the hardware check will then be bypassed and return the token automatically, thus allowing the attacker to get a hold of the token. The better solution would be to tie together all the native functions in a way that it returns the token in the same call. In the second line, it is all performed with a single call to the hardware chip, so that there is no way to bypass that piece of code. This process is typically carried out by the iOS Secure Enclave or the equivalent Android Key Store.

Figure 3.4: Two different ways biometric authentication calls can be performed.

3.2 Open Web Application Security Project (OWASP)

OWASP is a non-profit online community that produces open-source security methodologies, documentation, and tools. Their goal is to make software security visible so that individuals and organizations can make

(42)

Chapter 3

informed decisions (‘OWASP’, 2019). During the next chapter, I will refer to their documentation as they are a group that provides unbiased and practical information for application security. Members of the project cover a diversity of security experts from around the world who share their knowledge of vulnerabilities, threats, attacks, and countermeasures. The organization is probably most known for the publication of a popular Top Ten list, but they also provide a much more in-depth testing framework.

The framework will be introduced in detail in Section 6.1 - Resources.

3.2.1 Platform usage

While many of the requirements in this topic refer to things on the server- side, thus outside the scope of this thesis, as described in Section 1.4. There are some scenarios worth mentioning since there are several ways these topics can expose a security risk.

1. Violation of published guidelines.Every platform has different development guidelines when it comes to security. The application should follow the best practices recommended for the platform to avoid being exposed to risk. An example is the Apache Cordova plugin SecureStorage. The implementation for the developer becomes abstract, but the implementation should follow the best practices, for, e.g., iOS Secure Enclave or vice versa for Androids Keystore. If it were to use something like SQLite for storage, it would be flawed and not follow the platform guidelines.

2. Violation of convention or common practice.Not every best practice isde jure. Some are commonly known throughout the community, and these best practices will most likely change over time as the technologies mature and discoveries are made. Having a developer with some experience with the technology stack can be a good idea to catch common mistakes and promote better practices during code reviews.

3. Unintentional Misuse. Sometimes, the implementation is flawed simply by mistake from the developer. It could be a simple bug like enabling logging in production or a weakness in the implementation caused by a misunderstanding of an API.

Flaws in the use of the platform’s permission model also fall into this category. E.g., the app requests unnecessary permissions or invoke them at the wrong time (OWASP.org, 2016). Requesting unneeded permissions is not only a violation of the development guidelines for both platforms.

24

(43)

It could lead to privacy implications, but also unnecessary broadens the attack surface or increases the impact if anything were to happen.

Three requirements can be derived from OWASP Top 10, shown in Table 3.1, and fall into this category. That isA6 - Sensitive Data Exposure, A7 - Missing Function Level Access ControlandA9 - Using Known Vulnerable Components.

MASVS Requirements

There are several requirements regarding the improper use of platforms in MASVS. Here are the ones of relevance for the PoC applications.

• V2.3:"No sensitive data is written to application logs."

• V2.7: "No sensitive data, such as passwords or pins, are exposed through the user interface."

• V2.9: "The app removes sensitive data from views when backgroun- ded."

• v2.11: "The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode."

3.2.2 Data storage

In mobile security the confidentiality of sensitive data and personal information is critical. If the application uses insecure practices for storing or retrieving such information it can be intercepted, a risk discussed in Section 5.2.1. The data can be at risk either at rest or during transmission.

The use of web technologies opens up for an even greater selection of storage solutions. Such as the browsers local storage or cookies. Other ways an application can disclose sensitive data are cloud storage solutions, backups or cache (Schleier et al., 2019). Additionally, the inherent risk of physical loss is present. Although the loss of availability, devices should be sufficiently protected by the operating system so that confidentiality is not breached.

When developing mobile apps, special caution is needed when storing data. I.e., use appropriate storage APIs and take advantage of hardware- backed security features if available (OWASP.org, 2019a).

According to OWASP, fragmentation is a problem to deal with, especially on Android devices. As explained in Chapter 2, Android devices run on a variety of hardware made by different manufacturers with a

(44)

Chapter 3

complicated pipeline. In some cases, resulting in unsupported hardware or software and the lack of hardware-backed secure storage mechanisms.

In order for an application to support these out-of-date devices, it would have to use an older version of Android’s APIs, which may miss crucial security features. It is therefore recommended to create apps that support the current API version and security solutions. The chosen implementation should provide a middleway, supporting current features while being reasonable backward compatible. Support should be ended if sufficient mechanisms are not available, even though it will exclude some devices (OWASP.org, 2019a).

3.2.3 Communication

A communication protocol can be seen as a system that facilitates two or more entities to exchange and transmit information. Mobile devices use a variation of different communication protocols, e.g., Wifi, NFC, 4G, and Bluetooth. The use of these different protocols come with several different attack vectors, ranging from simple to sophisticated. These protocols could pose all kinds of threats, as discussed in 5.2.1, including interruption, interception, modification, and fabrication. Therefore it is crucial to properly secure the protocols used while keeping the scope limited. As a fundamental necessity, mobile apps must set up a secure, encrypted channel for communication using the Transport Layer Security (TLS) protocol with appropriate settings (Schleier et al., 2019).

3.2.4 Authentication and Authorization

Authentication is the process of verifying users are whom they say they are, while authorization is the process of determining who has access to what. Authentication is a fundamental functionality in applications that handle personal data or otherwise customize the experience for its users.

There are several different ways user authentication can function, but most commonly much of the logic typically resides on the backend. Mobile devices have had the advantage for some years that it offers biometric- authentication, not yet wildly used on the web or traditional computers.

While this allows for a simpler process it also includes adds complexity and room for errors (OWASP.org, 2019a).

In addition to the common username and password approach applications frequently include authorization frameworks such as OAuth2. An- other approach is to delegate the logic and part of the risk to a authentication and authorization platform like Auth0. According to OWASP Mobile

26

(45)

Figure 3.5: Authentication request flow.

Top 10, authentication and authorization are a regular place for flaws. Con- sequently, architects responsible for making decisions need to be aware of the risk the different implementations introduces (Schleier et al., 2019).

Figure 3.5 shows an example of how the request flow can be implemented. It is commonly used as it is optimized server side, where no sensitive logic is publicly exposed in the client. This flow requires redirections through the user-agent, in this case, the Ionic container, to receive the API calls. Another common way of doing this is the implicit type whereclient secretconfidentiality is not guaranteed, and the principle is that it relies on callback URIs from, e.g., other identity providers.

3.2.5 Cryptography

Name Type

DES, 3DES Block chiper

RC2 Block chiper

RC4 Stream chiper

BLOWFISH Block chiper

MD4 Stream chiper

MD5 Hash function

SHA1 Hash function

Table 3.2:Cryptographic algorithms that are known to be weak and should be replaced by more secure alternatives.

The purpose of cryptography is to provide a defense to the core principles of information security; confidentiality, integrity, and authenticity (Schleier et al., 2019). I.e., that a receiver can be sure the data is sent by the trusted sender and is not altered or obtained by someone else.

(46)

Chapter 3

For cross-platform applications, it is essential to make sure that the cryptographic functions used do not implement any of the flawed algorithms as shown in Figure 3.2. Even more importantly, is that the application uses cryptography at all. For the last couple of years people have been educated on the web to look for a secure connection when interacting with sensitive information. However, it is not as user-friendly on mobile platforms. In fact, just in recent years Google and Apple have started enforcing secure channels for e.g., push notifications. In 2020, secure channels will be the only option for that native applications can use for communication. Despite the fact that applications running is the browser are allowed by bypass these restrictions.

Even though an algorithm is considered secure today does not mean it will be forever. Flaws can be found in the implementation and with the constant increase of computing power, there is no certanty. Developers should refer to institutions like NIST that advises the expected lifespan. If possible, the cross-platform applications should rely on secure hardware for storing encryption keys and performing cryptographic operations (Schleier et al., 2019). The name of the cryptographic APIs might differ between different operating systems even if they use the same algorithms.

According to Mobile Security Testing Guide, the following algorithms are recommended (2019):

• Confidentiality algorithms: AES-GCM-256 or ChaCha20-Poly1305

• Integrity algorithms: SHA-256, SHA-384, SHA-512, Whirlpool-512

• Digital signature algorithms: RSA (3072 bits and higher), ECDSA with NIST P-384

• Key establishment algorithms: RSA (3072 bits and higher), DH (3072 bits or higher), ECDH with NIST P-384

Hashingis a process that takes a text input and computes a value unique for that string. Important characteristics are that if the text slightly changes the value should be different. Hashing is a one-way process, meaning that it should not be feasible to make a value that matches a text string.

Message Authentication Code (MAC)is a process often used in conjunc- tion with hashing and symmetric encryption. It is a tag passed along to au- thenticate data. The process can be divided into three parts: the generation,

28

(47)

signing, and verifying algorithm. The latter is used to prove authenticity and is commonly combined with secret keys.

Signaturesis the process of combining asymmetric cryptography with the one-way hashing technique. This works by encrypting the hashed message with a private key. Giving the receiver confirmation that the message was delivered by the trusted sender since the secret key should be unknown to a third-party (Schleier et al., 2019).

There are several requirements regarding the use of cryptography in MASVS.

• V3.1: "The app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption."

• V3.2: "The app uses proven implementations of cryptographic primitives."

• V3.3: "The app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices."

• V3.4: "The app does not use cryptographic protocols or algorithms that are widely considered depreciated for security purposes."

3.2.6 Client code quality

The applications made today run on several different platforms and are written in distinctive languages with different syntax. Fundamentally the platforms can have different strategies to how they attempt to prevent certain vulnerabilities. These flaws can manifest in multiple layers. It may concern both of the platforms operating systems, or even target the backend the application communicates with. Besides, flaws can also reside on the layer of the cross-platform framework.

Below are some of the attack vectors most frequently exploited. This falls in the same category as the OS-specific instances and exploits mitigation features discussed earlier in Section 3.1.1.

• Injection Flawsreferrers to a vulnerability that allows a user tobreak outof the sandbox environment.

(48)

Chapter 3

• SQL Injection. While the APIs to the backend should receive sanitized data, we still need to consider the mobile client application as a frontend that can be modified. As we know, applications does not only get data from a backend service but can also useclient-side storage. The impact of a typical SQL injection flaw would increase if the application were designed to have more then one user account, or mistakenly not use secure storage. Ionic application extensively relies on databases such as SQLite, which is the most used database engine in the world². Since this technology is used in literally every mobile device, as well as PCs/Macs, currently counting and over 1 trillion databases across the devices, it is an attack vector that needs to be addressed.

• XML Injection. A hybrid application would, in most cases, not parse much XML data. If it were to communicate through XML with a service, the backend should verify that the data does not try to alter structures and change the logic of the application. In the most common use-cases, I, therefore, consider this to be a vector outside of the scope.

• Buffer and Integer Overflows. Some languages such as Java used in native Android does not handle integer underflow and overflows by default. As such, the behavior when an integer overflows it goes back to the minimum value, and the opposite for an overflow. Swift, on the other hand, has advanced operators³to deal with overflows.

– &- for subtraction – &+ for addition – &* for multiply

In theory, this could be exploited since the Cordova plugins use native code. I would, however, be more concerned to test how it is handled in the web layer, using checks such asNumber.isSafeInteger() and having a good test coverage of inputs during dynamic testing.

• Cross-Site Scripting. According to the Ionic documentation⁴ using components such asion-alerttakes HTML and should be considered untrusted. As with anything web-related, using things like Inner- HTML without sanitation provides an attack vector for bad actors.

2According to https://www.sqlite.org/index.html.

3From Swifts documentation https://docs.swift.org/swift-book/LanguageGuide/

AdvancedOperators.html.

4See https://ionicframework.com/docs/faq/security.

30

(49)

By default, the Ionic components are sanitized, but for custom made components, it is up to the developer to do so.

In Angular theDomSanitizerclass avoids this by default. As it would treat the example bellow as unsafe:

let url: string = 'javascript:alert("XSS attack!")';

<a [href]="url">Button</a>

In React, the values in JSX are converted to strings, but they can still be injected. It is considered the best practice to use a package such as sanitize-html⁵.

There is a requirement regarding the use of code quality in MASVS.

• V6.2: "All inputs from external sources and the user are validated and, if necessary, sanitized. This includes data received via the UI, IPC mechanisms such as intents, custom URLs, and network sources."

3.2.7 Code tampering

Making it completely impossible to inspect the contents of an application should not be a goal in most cases. As it should be assumed that anyone who put in enough effort will with time to able to examine the contents of the downloaded binary. Countermeasures such as code obfuscation of either the web code or lower lever can be preventative, but at some point, it will not keep bad actors away. Compiling an Ionic application with the –prod fag will run uglify.js, which minifies the code for production thus making it harder to read. Like illustrated in Figure 3.5, authentication secrets should be kept safe or simply not at all. An example of keys on the client-side would be the Firebase initialization code.

export const environment = { production: false,

firebase: {

apiKey: "AIzaSyCON0S9GVuDINKhVQqGEQCm58v_9pd3Qig", authDomain: "master_bank-d44bc.firebaseapp.com",

databaseURL: "https://master_bank-d44bc.firebaseio.com",

5sanitize-html can be found at the npm registry https://www.npmjs.com/package/

sanitize-html.

(50)

Chapter 3

projectId: "master_bank-d44bc",

storageBucket: "master_bank-d44bc.appspot.com", messagingSenderId: "977565616813"

} };

For the web, the solution could be to whitelist the specific domain in the Firebase console, but since this web app is, in fact, running as a local server, we are not getting anywhere without allowing calls from127.0.0.1.

Different solutions for this are explored in Chapter 5.

3.2.8 Reverse engineering

In the earlier days of computer security, reverse engineering was a common practice, even among hobbyists and so alike. Used to bypass and remove restrictions set by the manufactures, such as serial numbers or to get advantages in games. However, it has become a more common skill needed for mobile security tester. The mechanisms have become more sophisticated and as such, the creativity of the attack vectors has increased.

The next chapter will introduce security levels, and we will see that the last defense is resiliency against reverse engineering and tampering. Indicating that there is a need for some application to prevent resistance against bad actors looking into the application either before or during runtime.

Reverse engineering is the method of examining the compiled application to learn about its behavior. The purpose of this is to gain knowledge of the code and is often followed by tampering.

Tampering is the method of modifying a mobile app to change its actions. E.g., modifying the contents of the application to give information to a middle-man or unlocking functionality that normally costs money.

There is a requirement regarding reverse engineering in MASVS.

• V8.1: "The app detects, and responds to, the presence of a rooted or jailbroken device either by alerting the user or terminating the app."

• V8.9:"All executable files and libraries belonging to the app are either encrypted on the file level and/or important code and data segments inside the executables are encrypted or packed. Trivial static analysis does not reveal important code or data."

32