Emerging cross-platform technologies - DUO (uio.no)

Emerging cross-platformtechnologies

Implementation and evaluation from asecurity perspective

Marius Christensen

Thesis submitted for the degree ofMaster in Programming and System Architecture

60 credits

Department of InformaticsFaculty of mathematics and natural sciences

UNIVERSITY OF OSLO

Autumn 2019

Emerging cross-platformtechnologies

Implementation and evaluation from asecurity perspective

Marius Christensen

© 2019 Marius Christensen

Emerging cross-platform technologies

http://www.duo.uio.no/

Printed: Reprosentralen, University of Oslo

Abstract

Mobile applications are considered to be a fundamental tool we use forhours every day. In just a decade, it has changed many of the smallthings 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. Forbusinesses, this means that more resources are needed to build separateapplications 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 risksfor developers using such frameworks. It is done through Proof ofConcepts applications comparing available methods for developers in boththe native and web-based approaches. A major part of this thesis isdevoted to an analysis of the current solutions. It is done to explain someof their limitations, in addition to some of the proposed best native andweb practices, with the ultimate goal of increasing the overall security inapplications on mobile phones. The consequences and impacts of thesesecurity mechanisms are discussed extensively, followed by suggestionson how to improve. Although a great portion of the attack surface lies onthe network or back-end, this will need to be implemented correctly.

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

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

i

Acknowledgements

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

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

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

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

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

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

Marius ChristensenUniversity of OsloNovember 2019

iii

Contents

1 Introduction 11.1 Personal Motivation . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Research Question . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 72.1 A brief historical background . . . . . . . . . . . . . . . . . . 7

2.1.1 The state of mobile security in 2019 . . . . . . . . . . 82.2 Native applications . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Hybrid app frameworks . . . . . . . . . . . . . . . . . . . . . 112.3.1 Available frameworks . . . . . . . . . . . . . . . . . . 132.3.2 Evaluation of Ionic . . . . . . . . . . . . . . . . . . . . 152.3.3 Evaluation of React Native . . . . . . . . . . . . . . . 162.3.4 Summary of frameworks . . . . . . . . . . . . . . . . 16

3 Deploying a theoretical framework 193.1 Common mobile attack surfaces . . . . . . . . . . . . . . . . . 19

3.1.1 Cross-platform attack surfaces . . . . . . . . . . . . . 203.2 Open Web Application Security Project (OWASP) . . . . . . 23

3.2.1 Platform usage . . . . . . . . . . . . . . . . . . . . . . 243.2.2 Data storage . . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Communication . . . . . . . . . . . . . . . . . . . . . . 263.2.4 Authentication and Authorization . . . . . . . . . . . 263.2.5 Cryptography . . . . . . . . . . . . . . . . . . . . . . . 273.2.6 Client code quality . . . . . . . . . . . . . . . . . . . . 293.2.7 Code tampering . . . . . . . . . . . . . . . . . . . . . . 313.2.8 Reverse engineering . . . . . . . . . . . . . . . . . . . 32

v

3.2.9 Extraneous functionality . . . . . . . . . . . . . . . . . 333.3 Summary of technical groundwork . . . . . . . . . . . . . . . 33

4 Methodology and theory 374.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2 Literature study . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Risk rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4.1 Security levels . . . . . . . . . . . . . . . . . . . . . . . 434.5 The approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5.1 Generally exposed areas . . . . . . . . . . . . . . . . . 454.6 Recommendation of relevant tools and resources . . . . . . . 474.7 Ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Implementation 495.1 The goal of the system . . . . . . . . . . . . . . . . . . . . . . 495.2 Principles for a Secure System . . . . . . . . . . . . . . . . . . 50

5.2.1 Security Threats . . . . . . . . . . . . . . . . . . . . . . 515.3 Requirement analysis . . . . . . . . . . . . . . . . . . . . . . . 51

5.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 525.3.2 The architecture of the system . . . . . . . . . . . . . 545.3.3 Design template for the application . . . . . . . . . . 54

5.4 Technical implementation . . . . . . . . . . . . . . . . . . . . 545.4.1 Data Storage and Privacy . . . . . . . . . . . . . . . . 545.4.2 Cryptography . . . . . . . . . . . . . . . . . . . . . . . 585.4.3 Authentication and Session Management . . . . . . . 605.4.4 Network Communication . . . . . . . . . . . . . . . . 625.4.5 Platform Interaction . . . . . . . . . . . . . . . . . . . 645.4.6 Defense in depth . . . . . . . . . . . . . . . . . . . . . 66

5.5 Technical issues . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6 Testing 716.1 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.1.1 OWASP MASVS . . . . . . . . . . . . . . . . . . . . . 716.1.2 OWASP Mobile Security Testing Guide . . . . . . . . 726.1.3 Mobile App Security Checklist . . . . . . . . . . . . . 726.1.4 OWASP Summary . . . . . . . . . . . . . . . . . . . . 726.1.5 CVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.2.1 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . 746.2.2 Burp Suite . . . . . . . . . . . . . . . . . . . . . . . . . 74

vi

6.3 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.3.1 Data Storage and Privacy . . . . . . . . . . . . . . . . 756.3.2 Authentication and Session Management . . . . . . . 756.3.3 Network Communication . . . . . . . . . . . . . . . . 766.3.4 Platform Interaction . . . . . . . . . . . . . . . . . . . 776.3.5 Code Quality and Build Settings . . . . . . . . . . . . 786.3.6 Defense in depth . . . . . . . . . . . . . . . . . . . . . 78

7 Findings & discussion 817.1 Results & discussion . . . . . . . . . . . . . . . . . . . . . . . 817.2 Recommendations for Improvement . . . . . . . . . . . . . . 827.3 Risk rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8 Conclusion 918.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Bibliography 95

Appendices 101

A Mobile Application Verification Standard test results 103

B Severity list rating for requirements 107

vii

List of Figures

1.1 Simplified architectural overview. . . . . . . . . . . . . . . . . 5

2.1 A look at how the two frameworks differs in rendering. . . . 152.2 Comparison of development team structures. . . . . . . . . . 17

3.1 WebView and Cordova connects OS functionallity. . . . . . . 203.2 Architecture of applications using Cordova to tap into native

functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Example showing how tokens can be misused. . . . . . . . . 233.4 Two different ways biometric authentication calls can be

performed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Authentication request flow. . . . . . . . . . . . . . . . . . . . 27

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

4.2 Risk rating hierarchy model. . . . . . . . . . . . . . . . . . . . 434.3 MASVS requirement levels and their meaning. . . . . . . . . 44

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

5.2 Onboarding process pages. . . . . . . . . . . . . . . . . . . . 555.3 Application content pages. . . . . . . . . . . . . . . . . . . . . 555.4 Security architecture diagram of iOS (Apple, 2019). . . . . . 595.5 Contents of the JWT used in the Master Bank implementation. 625.6 A snippet from the obfuscated code from auth.service.ts. . . 68

6.1 Overview of how the different parts of the OWASP projectare related. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

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

6.3 Firebase’s use of local storage. . . . . . . . . . . . . . . . . . . 766.4 Encrypted TLS v1.2 traffic inspected with Wireshark. . . . . 76

ix

6.5 Error shown (in Norwegian) due to SSL pinning. . . . . . . . 776.6 Remote code execution vulnerability found during testing. . 78

7.1 Mobile Security Checklist compliance score for the test results. 90

x

List of Tables

2.1 Overview of features supported in different mobile appapproaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Platform Idiosyncrasies between iOS and Android. . . . . . 112.3 Benefits and downsides of cross-platform development . . . 132.4 Comparison of frameworks in cross-platform development. 14

3.1 OWASP top 10 mobile . . . . . . . . . . . . . . . . . . . . . . 203.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 andcould be a good reference in a Forensic Analysis. . . . . . . . 42

4.2 Overview of common attacks on mobile devices and itsinfrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 Functional and non-functional requirements. . . . . . . . . . 535.2 Comparison between stateful and stateless authentication. . 62

7.1 Likelihood and impact levels . . . . . . . . . . . . . . . . . . 887.2 Test results from the eight different categories. . . . . . . . . 89

B.1 Severity listed for each of the requirements. . . . . . . . . . . 110

xi

List of Acronyms

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

API Application programming interface . . . . . . . . . . . 2BaaS Backend-as-a-Service . . . . . . . . . . . . . . . . . . . 83CORS Cross-Origin Resource Sharing . . . . . . . . . . . . . 75CVE Common Vulnerabilities and Exposures . . . . . . . . 66CVSS Common Vulnerability Scoring System . . . . . . . . . 66DAST Dynamic Application Secuirty Testing . . . . . . . . . 41IAST Interactive Application Security Testing . . . . . . . . 41IDE Integrated Development Environment . . . . . . . . . 56IdP Identity Provider . . . . . . . . . . . . . . . . . . . . . 60JSX JavaScript XML . . . . . . . . . . . . . . . . . . . . . . 14JWT JSON Web Token . . . . . . . . . . . . . . . . . . . . . 60MAC Message Authentication Code . . . . . . . . . . . . . . 28PoC Proof of Concept . . . . . . . . . . . . . . . . . . . . . . 2RCE Remote Code Execution . . . . . . . . . . . . . . . . . 78SAST Static Application Security Testing . . . . . . . . . . . 40SDK Software development kit . . . . . . . . . . . . . . . . 2SDLC Systems development life cycle . . . . . . . . . . . . . 43TLS Transport Layer Security . . . . . . . . . . . . . . . . . 26

xiii

Chapter 1

Introduction

"Software is like entropy: It is difficult to grasp, weighsnothing, and obeys the Second Law of Thermodynamics;i.e., it always increases."

— Norman Augustine

Nowadays, mobile applications are considered to be an essential part ofour daily life. In just a decade, it has changed many of the small things wedo each and every day across our world. People have adapted their habitsof how we create, share, and communicate with each other. To understandthe value of this revolution, which is considered to be roughly 12 yearsago with the introduction of the first iPhone, we should look at how oureveryday life has changed and thus how we have changed with the newflow of information available. One could argue that much of the successof the modern smartphone lies 1.8 million mobile applications connectingusers and enrichening their lives. Now, more then ten years later, theprimary user-mobile interaction is still app-centered. While some predictthat in the next mobile revolution, we will see action-based interactionsreplace this. However, we are not yet there.

Just like in the early days of the landline phone, we need an operator toconnect 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 sincethe content is essentially locked inside the app (Perrin, 2017).

Mobile applications are considered to be a fundamental tool we usefor hours every day. In just a decade, it has changed many of the smallthings 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. Forbusinesses, this means that more resources are needed to build separateapplications since the tools and technologies are unique for each platform.

1

Chapter 1

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

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

Two PoC Mobile applications were created for this master project. ThePoCs exposes many common attack vectors, as detailed in Section 3.3.Besides, the thesis discusses how the PoCs ranks on a set of recognizedsecurity assurance levels across different domains. The consequences andimpacts of these findings are discussed extensively, followed by solutionsor suggestions for improving security. Although a great portion of theattack surface lies on the network or back-end, this client-side frontendmust be done right.

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

1.1 Personal Motivation

As I write this thesis, I am like most people surrounded by devicesconnected to the internet; laptops, watches, audio-systems, phones andmore. For the past decade, I have closely been following various mobiledeveloper conferences with big eyes. Like many others, I was blownaway years ago with the introduction of mobile Software developmentkits (SDKs), which let developers create new experiences for people thatsimply weren’t possible before. I remember being amazed by the thoughtof potentially reaching millions of people easily with an idea through thephone. Still, in my early teens, I was making small games during theweekends, passing them along to friends on USB drives during recess.I never made it to the slightly more complicated mobile world at thattime, but the interest for has been there all along. As years have passed,the technologies and Application programming interfaces (APIs) havematured and aged - so have I. Last summer, I was so fortunate to begiven the opportunity to work on a cross-platform project at Sopra Steria.

2

Introduction

It really sparked my interest and let me see just how accessible thesetechnologies have made mobile application development for someone onlyhaving experience with web development – which is probably a lot morethan mobile.

Stepping into the consulting world, it is easy to see how creating regularapplications for the most common platforms requires a lot of resourcessince it is needed to write the same code twice. Due to variations inlanguages, dependencies, and architecture styles having the applicationrun on the same codebase is simply not possible. Multiple frameworksinterestingly try to address these problems.

During my years here at the University of Oslo, I have had manyconversations with fellow students and professors that have fueled myinterest. I feel fortunate to have met so many dedicated people; someare 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 somewhatinclined I was to combine my passion with academic research.

Writing this thesis conducts my five-year learning adventure, but Iam 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 applicationdevelopment. Aiming to explore the different security concerns we needto consider when using cross-platform development tools. I want toinvestigate through research and development how to properly implementsecurity measurements and potentially uncover weaknesses, as well as topromote 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-platformframework and what security concerns are relevant when developing forit?

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

3

Chapter 1

1. Investigate if there are specific challenges related to the cross-platform framework in general, and how the development andimplementation 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 vectorsfound in a secure manner.

3. Test and evaluate the process and its findings through an establishedtesting standard used in the industry as a means to identify potentialweaknesses that would fit into discovery to answer the researchquestion.

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

1.4 Scope

The main focus of this thesis will be on the available security mechanismsprovided in the two different PoC concepts. Security-wise this has tobe treated as a front-end that provides minimal security by itself. It isimportant to point out that the back-end and network, shown in Figure1.1, is just as essential to secure and test, even though it is not given muchattention in this thesis. As described in Section 2.3.4, the focus in thisthesis will be on a few selected technologies, while in fact, there are a lotof promising cross-platform technologies available as presented in Section2.3.1.

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

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

4

Introduction

Figure 1.1: Simplified architectural overview.

1.5 Thesis structure

Chapter 2: Background describes prerequisite information I find essen-tial for the reader to understand before handling the main body of thethesis, as well as relevant concepts in mobile security. I also describe howcross-platform application fits into the context of modern mobile applica-tion development.

Chapter 3: Deploying a technical framework presents an introductionto the security landscape, literature, and the historical background.Several domains are introduced that forms my theoretical framework foraddressing security testing in cross-platform frameworks.

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

Chapter 5: Implementation presents the goal, requirements, and archi-tecture for the system. As well as the technical implementation and issuesmet.

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

Chapter 7: Findings & discussion presents findings uncovered by theproject, reflections on the process, and its findings. The discussion isdivided 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-

5

Chapter 1

platform development. As well as suggesting further research in securingsuch systems.

6

Chapter 2

Background

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

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

2. Native application development (Section 2.2).

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

2.1 A brief historical background

Nowadays, almost 70% of all Internet users access the Internet using mobiledevices like smartphones or other mobile computers (Gröger, Silcher,Westkämper and Mitschang, 2013). Apps on these devices are becomingthe 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, andthe increasing need for mobility and flexibility, apps are gaining more andmore attention in business and everyday life. Mobile internet usage alreadysurpassed traditional desktop usage back in 2016, measured in percentageof global web traffic visits (Enge, 2018).

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

7

Chapter 2

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

The cost of mobile devices has increased over the years. Most modelsare relatively expensive and if it were to be unavailable it would expectedlybe a major inconvenience. Moreover, when we address the security ofsuch devices, it is crucial to be aware of what kind of information isstored or accessible on these devices because they contain large amounts ofsensitive data that can be lost or fall into the wrong hands. These data mayinclude 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 likelycause a significant inconvenience (‘Security in a Multi-Device World: TheCustomer’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, 113cell phones are lost or stolen every minute (Schweber, 2013). Note thatthese reports are written years before anti-theft systems became common.Studies have also looked at the potential risk, as these devices by theirnature, are inherently more likely to get lost or stolen. Which may have thefollowing consequences: (1) loss of the device i.e., the potential for physicalproperty loss, (2) loss of data i.e., the potential of being unable to accessneeded data and giving others potential access to such data, and (3) loss ofservice access. i.e., losing the ability to access needed applications remotelyand potentially allowing unauthorized access to such applications (Tu,Turel, Yuan and Archer, 2015).

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

8

Background

often extended upon by the manufacturer, adding complexity and a longerpipeline i.e., slower security updates. Both companies show conscientiousefforts to make the operating system secure. However, they have quite thedifferent philosophy regarding privacy and control. While Apple keepsthe App Store under tight review, the Google Play Store is more open andknown 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 softwareinteraction is expected to occur in mobile devices (2013). Today, having amobile-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 applicationand native, as seen in Table 2.1. Firstly, native applications are consideredto be superior with regard to performance to webview since they do notrely upon the browser’s engine to display content.

9

Chapter 2

Since native applications are written for a particular device or platform,they are using platform-specific languages. Applications for iOS arewritten 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 theentire codebase has to be rewritten for every platform (Abrahamsson andBerntsen, 2017).

Native apps have the benefit of access to the capabilities of the device. Itis possible to send push notifications, leverage the hardware on the devices,like GPS for location-based services, along with advanced camera systemswith augmented reality support, and more. The great benefit is thatfeatures and security fixes become immediately available1 to developers asthey are released. However, with different operating systems and devices,which require different source codes to run natively, targeting a mobileaudience 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, thereare both benefits and drawbacks for each different option. It is essential tokeep in mind that the decision should be based on the circumstances for agiven project, the team, and the requirements. Later in this paper, we willlook into more detail of what the current landscape of security on mobiledevices is like since developing using native SDKs is no longer the onlyviable option.

These other options need to ensure proper coverage of the two mostpopular and deployed mobile OSes: iOS and Android. While theseplatforms have many similarities for users, there is a need to identifycritical differences in architecture and configuration to provide uniformcoverage across both platforms. Platform Idiosyncrasies that might affectsecurity 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.2

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

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

10

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.3

iOS AndroidApp Transport Security Inter Process Communication

Touch/Face IDWorld Readable,World Writeable,World executable files

Local Authentication ObfuscationKeychain Java Crypto ArchitectureStack Smashing

Table 2.2: Platform Idiosyncrasies between iOS and Android.

How should the developers best perform security testingfor iOS and Android when taking system architecture andidiosyncrasies into account?

2.3 Hybrid app frameworks

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

Hybrid apps are essentially written as a web application, using standardweb technologies like HTML, JavaScript, and CSS, that are embeddedwithin a native wrapper. Allowing it to run on any device whilebypassing the restrictions common browser websites (‘Cross PlatformApps Development’, 2019). I.e., they can access a device’s hardware andtap into the mobile operating systems native code to use, e.g., biometric

3Data collected by Google on May 7, 2019.

11

Chapter 2

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

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

The advantages to this are that we do not need to hire developers who arespecialized in each platform, building the same apps for each with entirelydifferent codebases, and then maintaining and updating those separateversions with the same features. This can be complex, expensive, andtime-consuming, which leads to longer development cycles if we try tokeep functionalities across platforms in sync. Typically there is a need tomaintain two teams with expertise on each platform, which naturally couldlead to a higher cost. Of course, this approach does not come without itsdrawbacks either, and I would like to point out three of them.

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

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

• This also means that there are framework dependencies. Choosingthis approach means placing trust in the framework community thatmaintains it in order to keep up with the latest features and securityfixes. While it is in everyone’s interest to keep up with the newAndroid and iOS versions, there is an added layer and a factor toconsider nonetheless.

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

12

Background

Benefits DownsidesCode reusability Limited feature supportCost-effectiveness PerformanceConsistency in UI Components Not optimal platform specific UXFewer language barriers Dependent on framework updatesShorter 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 severalpromising cross-platform frameworks. The results can be seen in Table2.4. While I wont to restate all the results found, two of the approachesto cross-platform development seemed particularly interesting.

• Ionic is built by a startup from Silicon Valley. Most of the project isopen-source, while they capitalize on a few selected features gearedtowards enterprise customers. In some way, the project looked atas an evolution of Apache Cordova and PhoneGap. Historically thesame components were used to enable the webview application to tapinto native functionalities of the different platforms. The frameworkinherits most of its technologies from the web since the applicationis rendered in the webview. Premade components that resemblethe native functionality of the platform are pre-made with HTML,CSS, and JavaScript. Since running an application in the webview isthe most platform-agnostic approach that exists it allows for a greatamount of code reuse while also being an accessible technology formost.

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

As many as 35,609 applications use Ionic as of 2019.4 Itis also the most budget-friendly framework among thedescribed, thanks to its web nature.

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

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

13

Chapter 2

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

meaning that it is also open source like Ionic. The language isJavaScript-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 iftheir mobile application shares similarities in functionality with theweb. Unlike frameworks like Ionic, the canvas is rendered naively,i.e., not in a webview, meaning that it has several performancebenefits and is considered to be fast. It is built on the principle ofcomponents so that both the iOS and Android versions can look thesame. This can both be a benefit or a drawback depending on whetherthe goal is resembling platform-specific design principles and feel orits own. As much as 96% of the code is platform agnostic and can

14

Background

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

The real benefit of React Native is the growing communityand that the main logic of the react-native can be sharedbetween 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 mostbudget-friendly framework among all the different frameworks. It is easyto pick up for someone with experience from the web, making it a choice toconsider for many. While it is slightly behind strictly native in performance,it comes with many benefits and few hindrances. It gives the developersmuch more flexibility when it comes to design since it is using CSS, whilealso 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 codefrom within the container using an already huge and growing library ofJavaScript plugins to make calls to system components such as biometricauthentication.

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

15

Chapter 2

- allowing developers to choose between front-end frameworks such asReact or Vue, making it a good fit for code reusability if the companyalready has components for the web. It is also worth to mention thatdevelopers can take advantage of the many packages in npm5 in the webenvironment. Which of course, makes life more comfortable, but also posesa risk as it might be unknown or vulnerable third-party packages. Therehave also been numerous flaws found in well known and wildly usedpackages. Besides, vulnerabilities may propagate in dependent packagesof 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 considerwhen building new experiences for mobile. As shown in Table 2.4, itallows for a great amount of code reuse while giving users smooth nativeanimations and experiences. It is backed by Facebook that uses it forits main application, Instagram, and Messenger, so there is proof it canscale well. It is also chosen as the core technology behind both the VoIPapplications Discord and Skype. It shows that it is a matured technologythat can deliver great experiences to millions of people. React native is alsoby far the most popular framework, as measured in GitHub Stars, and hasa huge community with lots of support. On the other side, there might be alack of visibility into such a large company that can bring frustrations whenso many people depend on their contributions and maintenance.

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

2.3.4 Summary of frameworks

At the time of writing this, the choice seems obviously to be between thetwo latter frameworks. Adobe PhoneGap is beginning to look like a datedtechnology with the best plugins being made available to Ionic troughApache Cordova. Xamamarin is costly as a student, and the learning curveseems too steep unless you pursue a professional career. Flutter lookslike 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 defaultpackage manager for the JavaScript runtime environment Node.js.

16

Background

Figure 2.2: Comparison of development team structures.

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

17

Chapter 3

Deploying a theoreticalframework

Part of this chapter contains information about threats for mobile applica-tions, hybrid applications, and the mobile application platform in general.After that comes apart with theory about application architecture, securitytheory, and modifiability 1 for adapted web security controls. The chapteralso contains some theory I find useful to include before presenting themethodology.

3.1 Common mobile attack surfaces

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

Almost every application talks to a back-end service, and those servicesare prone to the same types of attacks we are familiar with on web and indesktop environments (Schleier et al., 2019). Mobile client-side applicationsdiffers in that there is a larger attack surface because it has a lot of sensorsand 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 theflexibility with which the system adapts to such changes.

19

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., dataprotection on the device is essential.

1. Improper Platform Usage2. Insecure Data Storage3. Insecure Communication4. Insecure Authentication5. Insufficient Cryptography6. Insecure Authorization7. Poor Code Quality8. Code Tampering9. Reverse Engineering10. 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 ApacheCordova architecture. The cross-platform hybrid mobile frameworkmanages the connection between the native layer and the embedded webbrowser component. It enables the JavaScript applications to communicatewith the native application programming interfaces (APIs) to access nativeresources, such as the network, camera, GPS, and contacts. Besides, severalcomponents provide capabilities to control and set up the communicationchannel between the embedded web browser and the hosted native app

20

Deploying a theoretical framework

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

According to Brucker and Herzberg, hybrid apps pose several chal-lenges from a security development perspective (2016). We need to beaware that, e.g., an XSS attacker becomes much more powerful as attackersmight be able to break out of the JavaScript environment and inject codethat is executed in the context of the native part of the app, increasing thedamage potential. The combination of web technologies and native mobilecode is not yet supported by state of the art automated security testing toolsin 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 soft-ware industry (Bessey et al., 2010). He further suggests that one solution tothis problem could be to develop a static code analysis approach that sup-ports hybrid mobile apps developed using Apache Cordova (Brucker andHerzberg, 2016).

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

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

21

Chapter 3

interface. The native library provides native APIs that are developed asabstract 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 deviceresources such as location services, camera, and storage (Phung, Mohanty,Rachapalli and Sridhar, 2017).

There are many threats associated with using WebViews in mobileapps like cross-site scripting, excess authorization, file-based cross-zonescripting, weakening of TCB and sandbox to mention a few (Bhavani,2013) (Luo, Hao, Du, Wang and Yin, 2011) (Chin and Wagner, 2014). TheWebView interface and URL loading methods can easily be exploited tointroduce 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 theCordova API to access and exploit native OS functionalities, i.e., gainingaccess to sensors and secure storage, that would otherwise be off-limits ina sandboxed environment.

Several security measurements can be implemented to mitigate the riskof such attack vectors; however, in general, adding an existing layer on topof native shell broadens the possible attack surface and further complicatesthe codebase. There is an OWASP Security by design principle that stateswe should keep security simple and minimize the attack surface area.Having this additional layer could add security concerns beyond whattypical web developers would be familiar with if such feature plugins areto be used or developed in-house.

According to the most recent Stack Overflow Survey, only 6.5% of alldevelopers cited Swift and Objective-C as familiar languages (languagesused explicitly for native development on iOS and Apple’s ecosystem).While in contrast, web developers made up 72.6% of respondents, andJavaScript appeared as the most commonly used programming languagein the survey (Stack Overflow Developer Survey, 2018) (Introduction to cross-platform hybrid development for architects, 2018). While this makes a greatargument as to why companies could benefit from the approach and usethe existing knowledge of their developers, it is, however, scary from asecurity point of view. As shown in Figure 3.1, these plugins use nativeAPIs and third-party libraries that would not be familiar.

Furthermore, these plugins tend to be made available at the globalscope of the application and called from anywhere, thus breaking theprinciple 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 JavaScriptsource code, where the core idea is to search for all Cordova execution calls

22

Deploying a theoretical framework

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 notestablished as a secure default nor seem to be a widely adopted practicethroughout the developer community.

Figure 3.3: Example showing how tokens can be misused.

OWASP MASVS recommends following the platforms recommendedbest practice for using secure storage. As shown in Figure 3.3, this is atypical scenario where we want to securely store an authentication tokennatively on the device with, for instance, the Cordova plugin for securestorage, and avoid relying on the browsers localStorage (Chen et al.,2014). In addition to this, a typical application would need as many as 11plugins for the authentication process. These plugins used together havean imminent flaw in the way that they are separated and do not talk to eachother. Figure 3.4 shows a pseudocode example of how one could programthis functionality using separate plugins. In the first line, an attacker couldoverride the biometric function to always return true, and the hardwarecheck will then be bypassed and return the token automatically, thusallowing the attacker to get a hold of the token. The better solution wouldbe to tie together all the native functions in a way that it returns the tokenin the same call. In the second line, it is all performed with a single call tothe hardware chip, so that there is no way to bypass that piece of code. Thisprocess is typically carried out by the iOS Secure Enclave or the equivalentAndroid 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-sourcesecurity methodologies, documentation, and tools. Their goal is to makesoftware security visible so that individuals and organizations can make

23

Chapter 3

informed decisions (‘OWASP’, 2019). During the next chapter, I will referto their documentation as they are a group that provides unbiased andpractical information for application security. Members of the project covera diversity of security experts from around the world who share theirknowledge of vulnerabilities, threats, attacks, and countermeasures. Theorganization is probably most known for the publication of a popular TopTen 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. Thereare some scenarios worth mentioning since there are several ways thesetopics can expose a security risk.

1. Violation of published guidelines. Every platform has different de-velopment guidelines when it comes to security. The applicationshould follow the best practices recommended for the platform toavoid being exposed to risk. An example is the Apache Cordova plu-gin SecureStorage. The implementation for the developer becomesabstract, but the implementation should follow the best practices, for,e.g., iOS Secure Enclave or vice versa for Androids Keystore. If it wereto use something like SQLite for storage, it would be flawed and notfollow the platform guidelines.

2. Violation of convention or common practice. Not every best practiceis de jure. Some are commonly known throughout the community,and these best practices will most likely change over time as thetechnologies mature and discoveries are made. Having a developerwith some experience with the technology stack can be a good ideato catch common mistakes and promote better practices during codereviews.

3. Unintentional Misuse. Sometimes, the implementation is flawedsimply by mistake from the developer. It could be a simple bug likeenabling logging in production or a weakness in the implementationcaused by a misunderstanding of an API.

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

24

Deploying a theoretical framework

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

Three requirements can be derived from OWASP Top 10, shown inTable 3.1, and fall into this category. That is A6 - Sensitive Data Exposure,A7 - Missing Function Level Access Control and A9 - Using Known VulnerableComponents.

MASVS Requirements

There are several requirements regarding the improper use of platforms inMASVS. 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 exposedthrough 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 personalinformation is critical. If the application uses insecure practices for storingor retrieving such information it can be intercepted, a risk discussed inSection 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 ofstorage solutions. Such as the browsers local storage or cookies. Otherways an application can disclose sensitive data are cloud storage solutions,backups or cache (Schleier et al., 2019). Additionally, the inherent risk ofphysical loss is present. Although the loss of availability, devices should besufficiently protected by the operating system so that confidentiality is notbreached.

When developing mobile apps, special caution is needed when storingdata. 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 devicesrun on a variety of hardware made by different manufacturers with a

25

Chapter 3

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

In order for an application to support these out-of-date devices, itwould have to use an older version of Android’s APIs, which may misscrucial security features. It is therefore recommended to create appsthat support the current API version and security solutions. The chosenimplementation should provide a middleway, supporting current featureswhile being reasonable backward compatible. Support should be ended ifsufficient mechanisms are not available, even though it will exclude somedevices (OWASP.org, 2019a).

3.2.3 Communication

A communication protocol can be seen as a system that facilitates twoor more entities to exchange and transmit information. Mobile devicesuse a variation of different communication protocols, e.g., Wifi, NFC, 4G,and Bluetooth. The use of these different protocols come with severaldifferent attack vectors, ranging from simple to sophisticated. Theseprotocols could pose all kinds of threats, as discussed in 5.2.1, includinginterruption, interception, modification, and fabrication. Therefore it iscrucial to properly secure the protocols used while keeping the scopelimited. 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 theyare, while authorization is the process of determining who has access towhat. Authentication is a fundamental functionality in applications thathandle personal data or otherwise customize the experience for its users.There are several different ways user authentication can function, but mostcommonly much of the logic typically resides on the backend. Mobiledevices 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 complexityand room for errors (OWASP.org, 2019a).

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

26

Deploying a theoretical framework

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 ofthe risk the different implementations introduces (Schleier et al., 2019).

Figure 3.5 shows an example of how the request flow can be implemen-ted. It is commonly used as it is optimized server side, where no sensit-ive logic is publicly exposed in the client. This flow requires redirectionsthrough the user-agent, in this case, the Ionic container, to receive the APIcalls. Another common way of doing this is the implicit type where clientsecret confidentiality is not guaranteed, and the principle is that it relies oncallback URIs from, e.g., other identity providers.

3.2.5 Cryptography

Name TypeDES, 3DES Block chiperRC2 Block chiperRC4 Stream chiperBLOWFISH Block chiperMD4 Stream chiperMD5 Hash functionSHA1 Hash function

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

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

27

Chapter 3

For cross-platform applications, it is essential to make sure thatthe cryptographic functions used do not implement any of the flawedalgorithms as shown in Figure 3.2. Even more importantly, is that theapplication uses cryptography at all. For the last couple of years peoplehave been educated on the web to look for a secure connection wheninteracting with sensitive information. However, it is not as user-friendlyon mobile platforms. In fact, just in recent years Google and Apple havestarted enforcing secure channels for e.g., push notifications. In 2020,secure channels will be the only option for that native applications canuse for communication. Despite the fact that applications running is thebrowser are allowed by bypass these restrictions.

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

According to Mobile Security Testing Guide, the following algorithmsare 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), ECDSAwith NIST P-384

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

Hashing is a process that takes a text input and computes a value uniquefor that string. Important characteristics are that if the text slightly changesthe value should be different. Hashing is a one-way process, meaning thatit 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

Deploying a theoretical framework

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

Signatures is the process of combining asymmetric cryptography with theone-way hashing technique. This works by encrypting the hashed messagewith a private key. Giving the receiver confirmation that the message wasdelivered by the trusted sender since the secret key should be unknown toa third-party (Schleier et al., 2019).

MASVS RequirementsThere are several requirements regarding the use of cryptography inMASVS.

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

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

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

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

3.2.6 Client code quality

The applications made today run on several different platforms and arewritten in distinctive languages with different syntax. Fundamentally theplatforms can have different strategies to how they attempt to preventcertain vulnerabilities. These flaws can manifest in multiple layers. Itmay concern both of the platforms operating systems, or even target thebackend the application communicates with. Besides, flaws can also resideon the layer of the cross-platform framework.

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

• Injection Flaws referrers to a vulnerability that allows a user to breakout of the sandbox environment.

29

Chapter 3

• SQL Injection. While the APIs to the backend should receivesanitized data, we still need to consider the mobile client applicationas a frontend that can be modified. As we know, applications doesnot only get data from a backend service but can also use client-sidestorage. The impact of a typical SQL injection flaw would increase ifthe application were designed to have more then one user account,or mistakenly not use secure storage. Ionic application extensivelyrelies on databases such as SQLite, which is the most used databaseengine in the world2. Since this technology is used in literally everymobile device, as well as PCs/Macs, currently counting and over 1trillion databases across the devices, it is an attack vector that needsto be addressed.

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

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

– &- for subtraction

– &+ for addition

– &* for multiply

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

• Cross-Site Scripting. According to the Ionic documentation4 usingcomponents such as ion-alert takes HTML and should be considereduntrusted. 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

Deploying a theoretical framework

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

In Angular the DomSanitizer class avoids this by default. As it wouldtreat 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 stillbe injected. It is considered the best practice to use a package such assanitize-html5.

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

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

3.2.7 Code tampering

Making it completely impossible to inspect the contents of an applicationshould not be a goal in most cases. As it should be assumed that anyonewho put in enough effort will with time to able to examine the contentsof the downloaded binary. Countermeasures such as code obfuscation ofeither 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 thusmaking it harder to read. Like illustrated in Figure 3.5, authenticationsecrets should be kept safe or simply not at all. An example of keys onthe 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.

31

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 inthe Firebase console, but since this web app is, in fact, running as a localserver, we are not getting anywhere without allowing calls from 127.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 commonpractice, even among hobbyists and so alike. Used to bypass and removerestrictions set by the manufactures, such as serial numbers or to getadvantages in games. However, it has become a more common skillneeded for mobile security tester. The mechanisms have become moresophisticated and as such, the creativity of the attack vectors has increased.The next chapter will introduce security levels, and we will see that the lastdefense is resiliency against reverse engineering and tampering. Indicatingthat there is a need for some application to prevent resistance against badactors looking into the application either before or during runtime.

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

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

MASVS Requirements

There is a requirement regarding reverse engineering in MASVS.

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

• V8.9: "All executable files and libraries belonging to the app are eitherencrypted on the file level and/or important code and data segmentsinside the executables are encrypted or packed. Trivial static analysisdoes not reveal important code or data."

32

Deploying a theoretical framework

• V8.10: "Obfuscation is applied to programmatic defenses, which inturn impede de-obfuscation via dynamic analysis."

3.2.9 Extraneous functionality

Backdoors or security controls can be helpful during development tospeed up up the process. It is often hidden functionality or code that isunintended to be released into a production environment. Examples ofthis can be, but not limited to, steps to bypass login during testing, calls todevelopment APIs, or debug logging that reveals internal structures. Thetypical characteristic of this risk is leaving functionality enabled that is notintended for the public audience (OWASP.org, 2019b).

According to Marit Iren Tokle, a security specialist at Sopra Steria, thereare a few important things to be aware of especially:

• Do not push directly to production.

• Remove method calls to log class for release builds.

• Disable ’ANDROID: DEBUGGABLE’ flag in production builds.

• On iOS disable NSLog statements.

"A very concerning 92% of Android apps tested have ex-traneous functionality issues while only a tiny 2% of iOS appsshow these issues (Tokle, 2018)."

3.3 Summary of technical groundwork

Bellow are every requirement the applications should fulfill listed in sevendifferent categories. Some of the concepts were explained in this chapter,while the rest will be explained as they are presented in Chapter 5. Notethat in order for the requirements regarding defense in dept to be effective,it requires the application to fulfill all the controls associated with MASVSlevel 1 (See Section 4.4.1 and Figure 4.3 for more information regardingsecurity levels). The requirements listed are by no means a comprehensivelist of everything a mobile security test should include, but merely a subsetthat makes sense given the time and scope for this thesis.

Data Storage and Privacy

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

33

Chapter 3

• V2.7: "No sensitive data, such as passwords or pins, is exposedthrough 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."

Cryptography

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

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

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

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

Authentication and Session Management

• V4.1: "If the app provides users access to a remote service, someform of authentication, such as username/password authentication,is performed at the remote endpoint."

• V4.2: "If stateful session management is used, the remote endpointuses randomly generated session identifiers to authenticate clientrequests without sending the user’s credentials. If stateless token-based authentication is used, the server provides a token that hasbeen signed using a secure algorithm."

Network Communication

• V5.2: The TLS settings are in line with current best practices, or asclose as possible if the mobile operating system does not support therecommended standards.

• V5.3: The app verifies the X.509 certificate of the remote endpointwhen the secure channel is established. Only certificates signed by atrusted CA are accepted.

• V5.4: The app either uses its own certificate store, or pins the end-point certificate or public key, and subsequently does not establishconnections with endpoints that offer a different certificate or key,even if signed by a trusted CA.

34

Deploying a theoretical framework

• V5.6: The app only depends on up-to-date connectivity and securitylibraries.

Platform Interaction

• V6.1: "The app only requests the minimum set of permissionsnecessary."

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

Code Quality and Build Settings

• V7.2: "The app has been built in release mode, with settingsappropriate for a release build (e.g. non-debuggable)."

• V7.4: "Debugging code has been removed, and the app does not logverbose errors or debugging messages."

Defense in depth

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

• V8.9: "All executable files and libraries belonging to the app are eitherencrypted on the file level and/or important code and data segmentsinside the executables are encrypted or packed. Trivial static analysisdoes not reveal important code or data."

• V8.10: "Obfuscation is applied to programmatic defenses, which inturn impede de-obfuscation via dynamic analysis."

35

Chapter 4

Methodology and theory

“The heart and soul of good writing is research; youshould write not what you know but what you can findout about."

— Robert J. Sawyer

In this chapter, the research method is first described with problems andessential decisions along with theory about the ways the implementationwill be measured in Chapter 7. The chapter covers the research processused in the study for evaluating technical factors affecting the security ofthe framework being looked into. Risk and testing theory are describedin order to better understand how these factors remodel the attacksurface. This research also investigates difficulties in securing the systemconcerning attributes affecting the ease of implementation. The processis kept as general and transparent as possible so that the work can bereplicated or built upon by other researchers later.

4.1 Methodology

In 2017 Mujaj took an experimental approach to compare secure messagingprotocols and implementations (2017). This study has close similaritiesin the approach taken to investigate the security properties of the cross-platform framework. Through this secondary source I found that Crnkovicwrote The Scientific Method in Computer Science and classified threescientific methods that could be applied to Computer Science researchpapers (2002):

• Theoretical Method: Theoretical Computer Science has its roots inlogic and mathematics. It adheres to the traditional methodology ofdeveloping theories and logical systems with rigorous definitions of

37

Chapter 4

objects and rules for proving hypotheses. The method principallyseeks to explain the limits of computation and the power of compu-tational paradigms (Dodig-Crnkovic, 2002).

• Experimental Method: Experimental computer science is best suitedfor a problem that requires the creation of software. The methodcan be used to obtain results from the software created and acquireinformation (Freitas, 2009). This approach is ideal to facilitateconcepts to solutions that can be tested through the making ofprototype systems.

• Simulation Method: Computer simulation makes it possible toexamine concepts beyond experimental capabilities and phenomenawhich can not be reproduced in a controlled environment. Thesimulations are led by theory and experiential results. (Dodig-Crnkovic, 2002).

The experimental method is applicable for this research, where the pro-totype application can be tested and used to obtain results from the con-cepts found in the literature. Chapter 5 presents the practical implementa-tion of these different security properties. Technical implementation detailsare laid out, step by step, for transparency and later replication on how eachof the prototypes could be built to get the results found. The evaluation ofthe experiment is done in Chapter 7, where the results for each domain arediscussed as a whole according to the requirements set for the prototype,and what could be done to mitigate the risk or obtain the missing proper-ties.

The structure of this research follows an adopted approach fromRummel and Ballaine (1963). In total, it consists of six different steps splitinto three different phases, as illustrated in Figure 4.1. The preparation forthis thesis started earlier with an essay exploring the possibilities in phase1; research proposal. This thesis iterated on those findings and continuedwith the research and presentation activities.

Progression on this project has generally been made by carefully goingthrough each step in a linear way. There have, however, been doneiterations going back and forth between steps two and three to find andbetter formulate the research questions.

4.2 Literature study

The literature study began as a preparation essay prior to this thesis. Thegoal was to do a state of the art of hybrid application security. Some of

38

Methodology and theory

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

the material was found in collaboration and guidance by the supervisors.Initially, I met some resistance as much of the prior research revolvesaround very specific (and often the theoretical aspects) of, e.g., protocols.There is not a lot of written, printed material on the subject, and thelittle that exists quickly gets dated. A librarian helped with refiningsearch terms online and finding perpetual theory on the concepts in thisthesis. The references for the material located were examined, extending tothat the process was repeated for interesting problems uncovered to findsupplemental material. The background study is a historical review givinga brief overview of how traditional handheld devices quickly have evolvedinto the complex computers that require security testing, just as much asdesktop or web application security testing.

4.3 Testing

Let us start by defining some key concepts:

• Black-box testing is, as the name implies, testing performed withoutthe tester having access to the applications code and information

39

Chapter 4

about its internal structures. The goal of this method is to test thefunctionality of the application. It can be useful when, e.g., testingboundaries or states.

• White-box testing is the opposite of the technique above. It is definedby ISTQB as "Testing based on an analysis of the internal structure ofthe component or system." So opposed to having zero knowledge ofthe application, the tester has access to the whole implementation.This allows for testing the application earlier in the process to andmore involved process as the tester has a clear view of e.g., thedocumentation.

• Gray-box testing is a combination of black and white box testingpresented above. Some information or clues are given, such ascredentials for authentication. As the approach can combine both ofthe benefits from the other methods it is useful for security testingsince it is possible to ensure whether the given results match thecriteria. I.e., malicious code can be sent from the client and the resultscan be checked on the backend.

I will have knowledge of the internal workings and source code frommemory that could cause black-box techniques to be biased during thereview. Although, it is inconsiderable since it is not a pen-test competition.

To test efficiently, it is strongly advised that the source code is beinglooked at, so that the test can be as time and cost-efficient as possible. Whilehaving code access is not the same as facing real threats out in the world,it does help to identify potential problems by verification of identifiedanomalies or flawed operations more easily (‘Mobile App Security Testing’,2019).

For this work, the white-box testing techniques is the favored way formost requirements. Even though some requirements are evaluated on apass-fail basis, it allows for quicker testing and it is easier to gain trustin the system. As some of the requirements are technical it would not bepossible to check the result given by the application by itself.

In mobile application security testing, it is essential that the analysis isadequate and cover all four of the separate areas. So that the entirety isevaluated and we can be confident that the results are accurate.

1. Static Application Security Testing (SAST), also known as white-boxtesting, means testing the application without running it. This canbe done by going through the source code to find potential flawsin the code. Some tools can help with this and give quantitative

40

Methodology and theory

measurements on things like code quality in the form of, for instance,cyclomatic complexity or test coverage.

• Codelyzer provides tslint1 rules for Angular TypeScripts pro-jects. Ionic (up until version 4.0) relies exclusively on Angular,thus making it a good fit for running static code analysis duringdevelopment.

• TypeScript is almost always for Ionic as it is default forthe Angular framework. It is a superset of Javascript andhas proven to enhance code quality and understandability byMicrosoft, Google, and Facebook in larger teams. However, Ibelieve it is not necessary to have a large team to benefit fromTypeScripts many enhancements, such as tooling, static typing,promoting object-oriented code, and a more declarative style ofprogramming in general. All of whom can lead to flaws nevermake it into production and faster development time.

• Dependency-Check. The danger of third-party packages hasbeen mentioned numerous times. Having a dependency checkerthat goes through, for instance, npm packages, identifies pro-ject dependencies, and checks if there are any known, pub-licly disclosed, vulnerabilities is crucial (‘OWASP’, 2019). Git-hub provides such functionality by reading the repositories pack-age.json file for free.

2. Dynamic Application Secuirty Testing (DAST), is a form of black-boxtesting, it is testing done more behaviorally. So that tester can findproblems not specifically tied to code, but something that happensduring use. Such as risky behavior performed by users in its runningstate. In the domain of mobile cross-platform security, this meanslooking for things such as requests and responses, scripting, sessions,and authentication.

• Frida or Burp Suite is a dynamic instrumentation toolkit thatis open-source. It is widely used by security researchers andreverse-engineers to test both Android and iOS applications.

3. Interactive Application Security Testing (IAST), is a combination of thetwo above. It analyses the code for security vulnerabilities, typicallydone in its environment by automated functional tests. Essentially,IAST combines the SAST philosophy of examining from within, with

1Linting is the process of checking the code for programmatic and style errors.

41

Chapter 4

the DAST view of the running the application. It has the benefit ofhaving a good code coverage while still resemble a real-world usecase.

4. Forensic Analysis, is useful in addition to the ones mentioned aboveto find, for example, leftover information from the developmentprocess. It is important to prioritize and have a systematic approachso that the high-risk areas are checked. Table 4.1 shows commonattacks on mobile devices. The first thing we learn in testing theoryis that exhaustive testing is impossible. As a result the amount ofeffort put into testing need to be weighted according the resourcesavailable and findings from risk assessment. It is also important tobe aware that such a forensic analysis can only reveal the presence ofdefects, not the absence of defects.

Browser System AppsPhishing Weak Passcode Sensitive DataFraming Jailbreak/Rooting StorageMITM Data accessible Weak EncryptionOverflow Weak Encryption Improper SSLData caching User-initiated Code Validation

Config manipulationDynamic Runtime InjectionEscalated Privileges

Table 4.1: Functionality and functions that often contains flaws and could be a goodreference in a Forensic Analysis.2

4.4 Risk rating

As part of the evaluation, the requirements from the end of the last chapterwill be evaluated based on a common risk rating methodology. Thestandard risk model is shown in equation 4.1. While there are manyapproaches to risk analysis, I have chosen to go with the OWASP approachas it is customized for application security (OWASP.org, 2019c). Ultimatelyrisk should be based on the severity of an incident happening within theorganization. In this case, the organization is fictive, but we base ourrating on a typical company in the intended sector and the technical impactfactors.

I find it essential to include risk rating as part of the evaluation of therequirements because there might be some specific technology that prove to

2Testing is context dependent - which means that depending on the type of applicationdifferent approaches, methodologies, techniques should be used.

42

Methodology and theory

be troublesome to implement for a set of requirements. That does, however,not mean that it is necessary as severe as, e.g., failing to secure TLS withsecure defaults, as the impact probably would be much higher than lack of,e.g., obfuscation techniques.

Risk = Likelihood ∗ Impact (4.1)

The second principle in testing theory is that exhaustive testing is notfeasible. So the amount of testing is a compromise based on the riskassessment of the application. It is also essential to be aware that it canonly reveal the presence of defects, not the absence of defects. Figure4.2 illustrates the chain of risk hierarchy that are factors of severity. Thetechnical aspect of the third layer in this figure is explained in detailin Section 5.2, while the range of factors concerning threat agents andvulnerabilities are addressed in Section 7.3.

Figure 4.2: Risk rating hierarchy model.

4.4.1 Security levels

Different kinds of applications have different security level demands.Usually, the extent of protection needed is determined early in the Systemsdevelopment life cycle (SDLC). Although Level 1 controls should beconsidered a minimum requirement for every mobile application (‘MobileApp Security Testing’, 2019). Requirements for both L1 and L2 are chosenfor the PoC application. In addition, some methods to combat reverseengineering and tampering are looked into.

43

Chapter 4

Figure 4.3: MASVS requirement levels and their meaning.

Businesses possess different assets. Such distinction changes thesecurity landscape and, consequently, the requirements and level as seenin Figure 4.3. It can also be a factor of resources available, regulations orpolicies.

E.g., a bank might have a policy that applications cannot be launchedon rooted devices. A recent regulatory example is the newly enforcedEU directive PSD2 (Payment Services Directive 2) that requires strongercustomer authentication, e.g., 3D Secure or biometric authentication.

4.5 The approach

I choose to categorize the different kinds of attack vectors found intothree different sections. This approach is slightly different than whatNeugschwandtner, Lindorfer, & Platzer did in their threat scenario onWebView Explanation, but is more in line with how it is categorized bymobile security testing firms, such as NowSecure (2019), as well as OWASPMobile Security Testing Guide (2013). Depending on the attack surface, itwill be divided into one of three different categories:

• The device attack surface

• The network attack surface

• The backend attack surface

As we assess the security risks of cross-platform frameworks, the focuswill be on the attack surface of the device. We will talk about both the term

44

Methodology and theory

attack surface, which is not to be confused with the term attack vector. Byattack surface, I refer to the sum of possible entry points for an attacker, andby attack vector the means of how an intruder gains access to the system.

4.5.1 Generally exposed areas

This section present and discuss the security concerns of frameworks whichunifies numerous heterogeneous devices and their software ecosystemsinto a single flexible platform. The results provide a foundation thatconsiders the myriad of security and privacy implications that are possiblydifferent from a traditional application development with native SDKs(Olalere, Taufik Abdullah, Mahmod and Abdullah, 2015). I will shed somelight on common vulnerabilities and differences found in the literaturesearch and my limited knowledge of working with such frameworks. Inthe end, I will summarize the considerations needed in order to designapplications using these technologies, and what such a unified, flexibleapproach brings to the table in terms of security concerns. Doing securityevaluations is necessary for the present and approaching demands ofenterprise security, timeliness, and accessibility of mobile applications(Jaramillo et al., 2013).

In general, some areas of the application will always be more prone toflaws and issues than others. This principle also extends over to mobile,and these are the typically high-risk areas that should be tested thoroughlyaccording to OWASP (2019a):

• Internet-facing code

• Forms

• Files from outside of the network

• Backward compatible interfaces with other systems – old protocols,sometimes old code, and libraries

• Custom APIs or protocols are more likely to have mistakes in designand implementation

• Security code. Anything to do with cryptography, authentication,authorization (access control) and session management

These areas are common places to be exposed to an attack, especiallywhere anonymous or public access is allowed.

As shown in Table 4.2, a mobile attack can involve the device layer,the network layer, the backend, or a combination of these (NowSecure,2019). Most of these attack examples are quite general and do not reflect the

45

Chapter 4

Table 4.2: Overview of common attacks on mobile devices and its infrastructure

ways they are executed. What is slightly different is how these attacks arecarried out and what kinds of protection mechanisms are used to mitigatethese attacks. Other more exclusive entry points for the platform wouldbe Phone/SMS, operating system, or wireless RF protocols such as NFC orBluetooth. Frequently reported over the last years have been breaches inthe SS7 protocol. A protocol mobile operators use for SMS delivery, thatcan be exploited to attack authentication systems that rely on verificationcodes sent through SMS.

46

Methodology and theory

4.6 Recommendation of relevant tools and resources

In preparation for a master thesis looking at the state of security amongstart-ups, Søhoel defined a list of criteria for developers to successfullyadapt (2018). The concepts are quite general, and I believe they translatewell into important factors to consider when evaluating criteria for cross-platform tools and resources:

• The tools should be free or not too costly; There is a saying amongphotographers that the best camera is the one that is with you. In awider context, development teams often do not have a lot of resourcesto pay for expensive tools. Think about the benefit/cost ratio. Open-source solutions can, in many scenarios, yield good results (Søhoel,2018).

• The tools should be quick and easy to install and use; for non-experts, whose main priority is developing a good application, itshould be easy and intuitive to get started with security improvingtools (Søhoel, 2018).

• There should be a limited amount of tools to cover all of OWASPtop ten; the collected set of tools should cover all of OWASP topten, but the number should be limited to make it both easier andfaster to get acquainted with all (Søhoel, 2018). This should be theabsolute minimum and needs to be evaluated depending on the typeof application. As previously discussed in Section 4.4.1.

• One should not need to be an expert in order to benefit from thetools; assume the recipient is a non-expert in the field (Søhoel, 2018).They should provide secure defaults and not require an unnecessaryamount of confusing configuration.

• The tools should give a limited number of false positives; If thetools give too many false positives, verifying all positives gets tediousand actual positives can be missed (Søhoel, 2018).

• The tools should be well documented; This is important foraccelerating the learning process and making the tools useful in lesstime (Søhoel, 2018).

The tools chosen are described in detail in Chapter 6.2.

47

Chapter 4

4.7 Ethics

The methods used to test these applications is an approved and proactiveattempt to demonstrate potential vulnerabilities in cross-platform applica-tions through research and practice. Security tests are useful for verifyingthe effectiveness of implemented security controls and whether the secur-ity policies are effective, and for gaining a status of infrastructure resili-ence. The applications tested are made specifically for these tests and maycontain flaws. While questionable actors may have other intentions, thisresearch has the following purpose:

• Determine if the systems have a satisfactory level of security and arein accordance with the requirements and needs.

• Identify the threats and vulnerabilities cross-platform applicationsfaces.

• Identify and prioritize security risks, as well as proposals formeasures that should be considered.

• Ensure that the systems are tested in an objective manner that can bereplicated by others later.

48

Chapter 5

Implementation

"To program is to understand"

— Kristen Nygaard

This chapter will first present some general key concepts and overallgoals before we go deeper into how these concepts fit together. Themajority of this chapter is, however, devoted to the implementation of thesix categories of requirements discussed in Section 3.3 and recapitulatedbellow.

1. Data Storage and Privacy

2. Cryptography

3. Authentication and Session Management

4. Network Communication

5. Platform Interaction

6. Defense in depth

5.1 The goal of the system

The goal of these systems is try to implement the requirements successfullyand find possible hindrances. This will be the groundwork for furthertesting and analysis along with the availability and easy of use presentedin this chapter. While these systems aim to implement the securityrequirements listed, it is by no means a comprehensive suite of everythingan application in production should fulfill. These applications aredeveloped solely to evaluate said controls.

49

Chapter 5

5.2 Principles for a Secure System

"Software security is the practice of building software tobe secure and to continue to function properly undermalicious attack."

— Gary McGraw

Designing a secure system is not an easy task. In information security,we aim to follow the three properties of confidentiality, integrity, andavailability (shown in Figure 5.1) that covers the most crucial componentsof security (Pfleeger, Pfleeger and Margulies, 2015). In order to be secure,all of these properties must be intact.

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

Confidentiality is the property that information is not made available ordisclosed to unauthorized individuals, entities, or processes (ISO 27000).Perhaps the most obious It is present when only authorized parties accessevery system component. The term access includes knowing the veryexistence of the system component, viewing, or printing (Pfleeger et al.,2015).

Integrity is the property of accuracy and completeness (ISO 27000).Integrity ensures that only authorized parties can modify the systemcomponents. The modification includes writing, changing, changingstatus, deleting, and creating (Pfleeger et al., 2015).

Availability is the property of being accessible and usable upon demandby an authorized entity (ISO 27000). An antonym of availability would be

50

Implementation

the denial of service, where access to a particular set of objects is denied ata given time (Pfleeger et al., 2015).

5.2.1 Security Threats

Applications are threatened in many different ways. These threats canbe classified into four different categories; interruption, interception,modification, and fabrication (Pfleeger et al., 2015).

1. Interruption affects the availability of the system. It is an unauthor-ized disruption of system resources that alter the way its assets func-tion (Pfleeger et al., 2015).

2. Interception affects the confidentiality of the system. It is a resultof unauthorized access to a system leading to leakage of information(Pfleeger et al., 2015).

3. Modification is also the result of unauthorized access and leads toassets being altered or deleted. Affecting both confidentiality andintegrity (Pfleeger et al., 2015).

4. Fabrication affects the authenticity of the data. It is the creation orchange by the introduction of forged data to the application (Pfleegeret al., 2015).

5.3 Requirement analysis

As a theme for this project, I have chosen to go with an applicationthat resembles information for a fictive banking platform named MasterBank. I found some inspiration from a successful penetration projectcalled InsecureBank v.21 that are made for developers to learn aboutAndroid weaknesses by testing that unsafe application. The Master Bankapplication will display data that could fit such a domain, but might not.The objective is to answer the research question, and the theme is there togive some context to the pages and knobs.

1See https://github.com/dineshshetty/Android-InsecureBankv2.

51

Chapter 5

5.3.1 Requirements

Table 5.1 describes both functional and non-functional requirements for thesystem. The functional requirements describe what the system should do,while the non-functional requirements state how the system should do so.

The application will implement some standard features that are presentin most applications. However, they are listed below, so they are not to beconfused with the security requirements in Table 5.1.

• Sign-up and login

• CRUD operations to the database

• Tables

• Navigation

• Image gallery

• Forms

• Push notification

• Image upload

• Maps

• Application analytics

The application will be built to support the latest version of iOS andAndroid (Currently iOS 12 and Android Pie 9.0). For the backend Firebase2 will be used. It is a product from Google, with a free tier for the scopeof this project. It is a service that makes it easy to bootstrap the basicfunctionality, such as authentication and databases, without spending toomuch unnecessary time setting it up. As for external API calls and data,the application will use a combination of calls to JSONPlaceholder3 andfaker.js 4 to get some dummy data to populate, e.g., tables and lists. As forthe developer account and provisioning profile, they are not needed for thepurpose of this project. In recent years it has been possible to develop andtest applications on iOS without a paid Apple Developer account. As forthe development environment, there is currently no way to run Xcode onWindows, so Mac is required since Android studio runs on both Windowsand macOS.

2More information about Firebase can be found at https://firebase.google.com.3Documentation available at https://jsonplaceholder.typicode.com/guide.html.4Documentation available at https://github.com/marak/Faker.js.

52

Implementation

Functional Requirements Non-functional RequirementsThe application should displaya splash screen when backgrounded.

The application should only requestpermissions when needed.

The application should authenticateusers.

The applications traffic should beencrypted over TLS.

The application should have twoauthorization levels.

The application should make a strongrandomly generated session identifier.

The application should sanitize allforms of user input, includingcustom URLs and network sources.

The application should not verboseinternal errors or debugging messages.

The application should show awarning if it is loaded in a rootedor simulated environment.

The applications internal structuresshould be protected against trivialstatic analysis.

The application should enforce aminimum device-access-securitypolicy.

The application should use obfuscationin the production environment.

The application should pin thecertificate of the backend serviceand deny other signed certificates.

The application should not writesensitive data to application logs.

The application does not exposesensitive data through the userinterface.The application should use industrystandard cryptography andimplementation for its particularuse-case with parameters thatadhere to industry best practices.The applications developerenvironment should verify that theapplication is compiled withup-to-date packages.The application should not requestunnecessary permissions.The application should verify theX.509 certificate of the backendservice when a secure channel isestablished.The application should be built inrelease mode with appropriate settings.

Table 5.1: Functional and non-functional requirements.

53

Chapter 5

5.3.2 The architecture of the system

Implementation decisions

When faced with the task of implementing native functionality within ahybrid application, it comes down to three approaches to choose from.

1. Open Source plugins are widely available and the go-to solution inmost cases. Over the years, the database of plugins has grown hugeand offers functionality for even the most niche problems. A pluginoften tries to solve a small problem, and nesting many differentplugins can get difficult or result in bad UX or security (Huynh,Ghimire and Truong, 2017).

2. Enterprise Products. As a solution to the problem above, IonicNative, have evolved. It is described as an enterprise-level solution tosecure mission-critical apps. Stability and support are guaranteed forfeatures such as authentication to Auth0, Azure AD, or AWS. This isalso guaranteed to work hand in hand with Identity Vault. On paper,it provides an all-in-one frontend security to deal with the securityproblems presented by Shehab & AlJarrah (2014).

3. Make your own native plugin - If none of the options above ispossible, we are left with the choice of writing our own solution tothe problem. In Section 1.4, I considered this to be outside of thescope for this thesis, as it requires writing native code for multipleplatforms. However, it is still a valid option.

5.3.3 Design template for the application

A high fidelity wireframe for the application was made to make the processeasier, and to not have to deal with the design decisions during thetechnical implementation. A few principles and tools from my bachelor’sdegree in interaction design came in handy. Illustrations were kindlyprovided by Katerina Limpitsouni.5

5.4 Technical implementation

5.4.1 Data Storage and Privacy

• Sensitive data. It is quite common for developers to frequentlylog things to the console or files during development and testing.

5Provided free of charge by courtesy of https://undraw.co.

54

Implementation

(a) Splash screen.

(b) Information given dur-ing the onboarding pro-cess. (c) Login screen.

Figure 5.2: Onboarding process pages.

(a) Home page.(b) Data displayed fromthe API.

(c) Page for basic CRUDoperations.

Figure 5.3: Application content pages.

55

Chapter 5

An example from recent years is a Norwegian power consumptionapp, that wrote all incoming SMS to a file named HafslundLog.txton the memory card.6 Since the Angular framework already comeswith environment variables, it is a good practice to use them tohide such information. Even though such logs should not containsensitive information since the frontend processes them. It can befurther automated by a Integrated Development Environment (IDE)config file in the repository of the project. The console is also notas accessible as it is for a web application, so it more relevant forperformance-wise.

// Disable console log on productionif env === 'prod' { console.log = debugFunction() {}; }

Password, pins, and other elements are hidden behind the HTMLinput type password. This does not provide security but someobfuscation at best. In Figure 5.3c, the masked characters should notbe the actual password. If it were, it would mean that the passwordwould not be one-way, and the implementation would be flawedas the password would have to be saved in clear-text and not onlycompared to the hashed value for verification.

It is common for an app that contains sensitive information to hideits contents from, e.g., multitasking views when backgrounded. Toshow the splash screen from Figure 5.2a when the app is not active welisten to the lifecycle hook ionViewDidLeave. This can be implementedwith a new Web Component made with Capacitor that works acrossall platforms.

import { Plugins } from '@capacitor/core';const { SplashScreen } = Plugins;

ionViewDidLeave { SplashScreen.show() }ionViewWillEnter { SplashScreen.hide() }

• Device-access-security policy. Previously Intel provided an APIthrough an extension called "Intel Security" which made it easy tocache data locally, and data protection came built-in with the imple-mentation. However, it has not received updates since late 2017, andhence cannot longer be recommended. Another abandoned project

6As reported by Digi.no https://www.digi.no/artikler/hafslund-app-med-skjult-lagring-av-tekstmeldinger/217669.

56

Implementation

is Secure Storage, as it is named in Ionics official documentation. Boththe solutions advertised in the documentation are no longer suited fornew projects, so the framework lacks an officially supported solution.

For securely saving shorter strings, such as tokens, the devices secure-key-store7 is a good solution. It has a simple interface of threemethods for saving, retrieving, and removing sensitive data from thedevice, where it is stored securely using the intended storage locationfor the platform. It is as simple as including the package and callingits set, set or remove methods.

When it comes to storing larger chunks of sensitive data, thereare several approaches to choose. For various reasons, it is notrecommended to use the browsers HTML5 Web Storage. Althoughit should be an established standard across browsers, there is noguarantee it will be supported on, e.g., older versions of Android.The better solution would be to use an encrypted SQLite databasefor such data. This allows for a standardized interface across allplatforms. In cases where the platform does not support the interfaceor cryptographic protocols; it is time to consider to end support forthe OS version.

Although the sqlcipher-adapter8 is only in maintenance mode, it isstill the best solution to be found. It supports SQLCipher 4 (withPBKDF2-HMAC-SHA512 as the Key derivation algorithm). It isensuring strong cryptography for many years to come as long aspotential implementation flaws are addressed. It is slightly harderto get up and running then the key storage mentioned above, but ithas an almost standardized API similar to others. With modifiabilityin mind, it should be a question of adaption rather than a full rewritedown the road.

With these two functions up and running, we now have a secureway to store both tokens or passwords as well as longer content inthe application. It is essential to be aware that this does not coverthe topic of retrieval of said data. I.e., you cannot expect to getanything of this if private keys are included with the applicationand not retrieved and secured using the said method after, e.g.,authentication.

There should be no need to enforce a stronger passcode than the one

7Available from https://github.com/pradeep1991singh/cordova-plugin-secure-key-store.

8Avaiable from https://github.com/brodybits/cordova-sqlcipher-adapter.

57

Chapter 5

set by the OS, nor is it an option as the APIs do not reveal such details.As of iOS 9, the default length of the pin code six digits, protected byvarious brute-force and timeout mechanisms. Android does not havea set length and is more flexible in the way that it also allows patternlock.

For people building mission-critical apps, Ionic Native isa curated collection of plugins and integrations that arebuilt and supported by Ionic, with stability assurances andguaranteed to work on all major platforms and versions. -Ionic Pro Documentation.

When it comes to the actual implementation of this, it is very straightforward. It is a single method call that returns a boolean. It can befurther expanded with logic to allow the user to, e.g., bypass pin orbiometric authentication. It is supported by the Ionic Native project.

import { PinCheck } from '@ionic-native/pin-check';

constructor(private pinCheck: PinCheck) { }

this.pinCheck.isPinSetup().then(

(success: string) => console.log("Pin code active.");,(error: string) => console.log("The device does not havea pin code.");

);

5.4.2 Cryptography

• Use of cryptography. When dealing with cryptography, there is amyriad for things to consider and equally many things that can gowrong. A professor of mine once told us to "Never ever, [...], ever,ever implement our own cryptography for production". There arethree common mistakes when it comes to cryptography. The firstis to use inadequate encryption strength or, secondly, an IV that isnot random. The third is the use of broken or weak cryptographyalgorithms. In Section 3.2.5, I laid out the state of the art whenit comes to what cryptography algorithms to use. In the domainof hybrid application, we have two paths to choose from for theimplementation.

1. High-level implementation in JavaScript.

58

Implementation

2. Tapping into a low-level implementation, such as letting theSecure Enclave do the work.

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

The straightforward approach would be to bring in, e.g., the crypto-js package as it fits nicely in with the workflow and is a popularchoice for web applications as well. It is vital to keep in mind thatseveral factors should be taken into consideration. The strengthof the cryptographic algorithms is just one of them. Performancecan be critical in some scenarios. However, as a general rule, thelatter approach is the one considered the best in most scenarios.The encryption and decryption are carried-out natively on hardware,giving it unparalleled performance compared to JavaScript librariesinside the sandbox. All iOS devices have a dedicated crypto enginethat does AES-256, as shown in Figure 5.4. Where crypto.js woulddo calculations inside the App Sandbox on the software side, theCrypto Engine resides in the DMA path between the flash storageand the main system memory (Apple, 2019). With the recent year’sprocessors, this also happens on an isolated bus, thus making it moreprotected from, e.g., being red from memory.

• Cryptographic protocols. For the implementation of AES-256 onhardware level this project used the open-source project named

59

Chapter 5

AES2569. Even though iOS is used as an example, the underlyingprinciples work similarly on Android under different names. For theactual implementation in Ionic, these differences are abstracted away.Bellow is an example from the documentation showing how aes256-256 can be used in practice.

// Import the libraryimport { AES256 } from '@ionic-native/aes-256';

private secureKey: string;private secureIV: string;

constructor(private aes256: AES256) {this.generateSecureKeyAndIV();

}

async generateSecureKeyAndIV() {this.secureKey =await this.aes256.generateSecureKey('random string');this.secureIV =await this.aes256.generateSecureIV('random string');

}

this.aes256.encrypt(this.secureKey, this.secureIV, 'unsecuredData').then(res => console.log('Encrypted Data: ',data)).catch((error: any) => console.error(error));

5.4.3 Authentication and Session Management

• Authentication. The application supports two different ways ofauthenticating users; social providers and the traditional usernameand password approach. Both use-cases are commonly used, but thetechnical implementation and logic vary depending on the type used.

– ID tokens are created by the backend when a user signs in. Thistoken is a signed JSON Web Token (JWT), an industry-standardmethod for representing claims securely between two parties.This token is stored in the application and sent to the backend toidentify the user.

– Identity Provider (IdP) tokens are created by IdPs i.e., Googleor Facebook. They are also tokens, but in a different format thanthe previous. This token is granted after a user successfully

9Aviable from https://github.com/Ideas2IT/cordova-aes256.

60

Implementation

authenticates with such a provider, and then used by thebackend service.

• Sessions and tokens. To explain how session and tokens areimplemented, I find it necessary first to explain the differencebetween how stateful and stateless authentication is implementedand how the OAuth 2.0 protocol differs from traditional statefulprinciples. Both methods are used depending on the type of login.A simplified overview of the advantages and disadvantages can beseen in Table 5.2.

A stateful session is created by the backend, and a reference stringis passed on to the client. For each subsequent request the clientmakes to the server, the string is passed along and used to validate therequest. This makes it easy to invalidate a session but scales poorlysince it adds overhead for each user added to the server. It can also beproblematic since the state resides on that specific server if anythingwere to happen or extra servers are added.

Stateless authentication is used to overcome the shortcomings ofstateful, but it is not without its own hindrances. While this generalconcept is the same for protocols such as OpenID Connect, JWT wasthe chosen standard for this project. In contrast to the other, the usersession data is stored in the application. The data is signed by thebackend to ensure the integrity of the session data. This way, thebackend only needs to verify the validity by using a cryptographichash to see if the signatures match. This approach also makes theapplication scale better as there is no overhead added to the serverper user authenticated. Additionally it makes the process of addingmore servers less complicated, and a failure would not mean that theapplication loses all its user sessions. The downside is that we cannotinvalidate sessions at will.

To circumvent this shortcoming, the expiration timer is limited andthe application is provided with an unique refresh token. By doingso, the application can be denied a new token.

Now we have a basic understanding of the stateless JWT implement-ation and how it differs from its alternative. That leaves us withOAuth, which is not stateless by default since the backend has tomaintain the state of the users privileges. This does, however, notmean that it cannot be achieved. In the implementation, once theuser is authenticated by the IdP, we generate a token the application

61

Chapter 5

can pass along with each request.

Figure 5.5: Contents of the JWT used in the Master Bank implementation.

In that way, we can use much of the same logic regardless of the userprefers one way to sign in over the other. See Figure 5.5 for the actualJWT contents.

Type Advatages DisadvantagesStateful Session can be revoked More users means more server overhead

Easy implementation for single servers Scales badSessions can be changed Difficult for 3rd party to integrateSmal footprint on client Large footprint on backend

Stateless Scales well Session cannot be revokedEasy to integrate 3rd party Technical complex for backendSmal backend footprint Unchangeable until expiration

Table 5.2: Comparison between stateful and stateless authentication.

5.4.4 Network Communication

• Encrypted traffic. Just like with cryptography, there are two similardifferent approaches.

– A high level implementation using Angular’s HTTP-client.

– Making native calls using Cordova’s advanced-http-plugin.10

The benefit of the Angulars HTTP client is that is it well documentedand used throughout the community. Technically it is an extensionof the browsers XMLHttpRequest interface, with some additions like

10Available at https://github.com/silkimen/cordova-plugin-advanced-http.

62

Implementation

typed requests and responses as well as a more streamlined errorhandling the process. Since it is the default way to handle HTTPcalls in Angular, and Ionic historically has been a mobile supersetthat extends on that, almost every resource written will import anduse this module.

The latter approach comes with three huge advantages. It will allowthe application to enable SSL Pinning, which means that we cancombat man-in-the-middle attacks on the application side. This canbe done by verifying the certificate again after the TLS handshaketo check if it is trusted. Secondly, it will move the responsibility ofkeeping TLS setting up-to-date with the best practices to the platform,and in-line with other (native) applications on the device. Lastly, itwill enable background threading of all requests.

The the time of writing this, both platforms support TLS v1.0-1.3,AES-128/256, and a variety of cipher suites. Down the line, earlierversions of TLS will be deprecated, and using this approach it willfollow the lifecycle of the operating system (Apple, 2019, p. 39). As ofiOS 9, App Transfer Security forces every application to use HTTPSfor communication, while Android phones running 9 and above willprevent it in the same way, unless the application explicitly allows it.

• Certificate handling. Generating certificates for the Android plat-form is done through Andoid Keystore. To generate credentials weuse keytool with the following arguments in the console:

keytool -genkey -v -keystore prod-key.keystore -alias master_bank-keyalg RSA -keysize 2048 -validity 5000

In order to get certificates for the iOS platform, an active AppleDeveloper account is required, which is 99$ annually. Once theapplication is registered at the developer portal, we get a reverseaddress like com.mariusch.MasterBank. It is used to get the certificatesigning request generated, and the tool OpenSSL can be used togenerate the key. The signing request needs to be sent through thedeveloper portal so that we can get our .cer file back, which weconvert to a .pem file that we then can use to sign the application.

openssl req -new -key masterbank.key -out CertificateSigningRequest.certSigningRequest

openssl x509 -inform DER -outform PEM -in ionic_app.cer -outionic_app.cer.pem

63

Chapter 5

openssl pkcs12 -export -inkey masterbank.key -in ionic_app.cer.pem-out Certificates.p12

The entire process is slightly more complicated for the iOS platform,and it also comes with a cost. Luckily this only needs to be done once,and it is only required to do so for (native) push notifications to workin a developer environment.

5.4.5 Platform Interaction

• Permissions. As of Android 8.0 and API version 26, (released 2017),both platforms handle permissions at the time of use rather thanat runtime. This makes user experience better but is slightly morecomplicated to implement. Earlier it was common for applicationsto only do a check for necessary permissions at startup rather than ineach specific case. Android and iOS do not share the same permissionmodel in all cases. In order to not make this unnecessary complex fortesting purposes, the location API was chosen. Both platforms needpermission to access the device location, and it behaves in a similarmanner. Checking for permissions can be done through the activelymaintained repository cordova-diagnostic-plugin11.

Part of this code is written by Mohit over at https://www.devhybrid.com/ionic-4-requesting-user-permissions/, and were used andmodified to fit this project. In the example bellow we check if thepermission is granted on the device. If not, the user is shown theassociated reason.

import { Diagnostic } from '@ionic-native/diagnostic/ngx';

grantPermission() {

this.diagnostic.isLocationAuthorized().then(authorized => {

if (!authorized) {// location is not authorized

this.diagnostic.requestLocationAuthorization().then((status)=> {

switch (status) {case this.diagnostic.permissionStatus.NOT_REQUESTED:

11Available at https://github.com/dpa99c/cordova-diagnostic-plugin#islocationavailable.

64

Implementation

console.log('Permission not requested');break;

case this.diagnostic.permissionStatus.GRANTED:console.log('Permission granted');break;

case this.diagnostic.permissionStatus.DENIED:console.log('Permission denied');break;

case this.diagnostic.permissionStatus.DENIED_ALWAYS:console.log('Permission permanently denied');break;

}}).catch(error => {

console.log(error);});

}}).catch(err => {

console.log(err);});

}

• Sanitation and External sources. Sanitation is the process ofmodifying the input into safe values that can be inserted into adatabase or DOM. This implementation uses three different types ofdatabases. Both Firebase Cloud Firestore and the Realtime Database.Cloud Firestore is the next generation realtime database but iscurrently missing some functionality. Hence the need to use both fornow. On the surface, they look very similar, and both are NoSQLdatabases. The third is the locally encrypted SQLite running as atraditional structured relational database.

Since this application is running the Angular front-end framework, itcomes with the DomSanitizer class, to help prevent potentials XSSissues. The use of the functions provided by the class is straightforward; however, it can be enough to forget to sanitize a singleinput. It is, therefore, a good practice to set up automated Karmatests or make sure it is in the pipeline for all inputs. Componentsshipped with Ionic are sanitized by default, however for everycustom component made, it is recommended to use the sanitize-html12 plugin, to specify permitted and rejected tags.

• Libraries. The application should only depend on up-to-datepackages, and known vulnerabilities should be patched as soon as

12Avaiable at https://www.npmjs.com/package/sanitize-html.

65

Chapter 5

possible. If the code is under version control and the repositoryis hosted on, e.g., GitHub, they will send a warning for potentialvulnerabilities. It is recommended to receive automated pull requestsfor dependencies affected. It is worth mentioning that identifiedvulnerabilities will not be disclosed, but if it is hosted public, otherswill be able to see the generated PR.

Vulnerabilities and classification is further explained in Section 6.1.5,but the automated vulnerability alerts can come from several sources.

– The Common Vulnerabilities and Exposures (CVE) list with agiven Common Vulnerability Scoring System (CVSS) score.

– WhiteSource, an open source initiative that saw the light afterthe Equifax scandal.13

In combination with the automated methods above, developersshould also regularly check and update the dependencies of theproject. There are only a few commands needed. To not runinto trouble with compatibility, we distinguish between updatingpackages to the latest version and patching security fixes.

Check and fix vulnerabilities

– npm audit - Checks the projects package.json file for knownvulnerabilities.

– npm audit fix - Patch found vulnerabilities in the package.jsonfile.

Check and update used packages

– npm-check-updates -u - Get an overview of the installed and thecurrent version for all packages used in the project

– npm install [package name] - install all updates or only a selectedpackage.

This part might look like a platitude, but it is crucially important thatthe application use up-to-date third party libraries, as many attackvectors origin from dated dependencies.

5.4.6 Defense in depth

• Root / Jailbreak detection. Rooting or jailbreaking a device wasperhaps more common in the early smart-phone era, to allow for

13More information available at https://www.whitesourcesoftware.com/GitHubSecurityAlerts.

66

Implementation

more functions and customization. A rooted device opens up allkinds of security implications and attack vectors; we lose controlover root certificates, and on-device MITM attacks will be possible.iroot14 allows detection of such devices for both platforms in a simplemanner. It is worth noticing that the MASVS Guide recommends atleast three different methods for identifying rooted devices to be bestprotected. However, many counter-measurements are available inunofficial rooted stores, such as Cydia, making it a cat-and-mousegame.

• Code protection is commonly associated with either encryption onthe file level or that critical files inside the executable are concealed.Through much research on the topic, I have not found a good solutionthat adequately does file encryption. Also, the solution documentedby Ionic has not seen an update in four years and does not seem to beworking.

The OWASP MASVS Testing document describe protection againstreverse engineering with the following bullet points for the practicalassessment.

– Meaningful identifiers, such as class names, method names, andvariable names, have been discarded.

– String resources and strings in binaries are encrypted.

– Code and data related to the protected functionality are encryp-ted, packed, or otherwise concealed.

The first bullet point can be accomplished with obfuscation, whilewe can mitigate some of the other risk by removing sensitive datafrom the code, i.e., only receive keys from the backend and pass themon to the Secure Enclave. By not having a sufficient way to do fileencryption, we are left with obfuscation. It will only partially fulfillthe requirement by concealing the functionality.

• Obfuscation. Although obfuscation by itself does not providesecurity, it does make it harder for attackers to tamper with the codeand look for potential errors. There are several ways this can beachieved. Ionic will, by default, minify the code for production, butit exists tools to reverse that with varying results. A much-usedsolution is a tool called jscrambler. It comes with options to fine-tune all kinds of parameters while still being easy to use. Figure 5.6

14Available at https://github.com/WuglyakBolgoink/cordova-plugin-iroot.

67

Chapter 5

shows a partial result of the obfuscated file that is used to handleauthentication in the application.

Ionic, when being run with the prod flag, also does obfuscation andwill minify the code together with uglify.js. The JavaScript file is alsosplit into different files and loaded on-demand, depending on the useof the new Ivy render engine, lazy loading, and if the code is treeshakable.

Figure 5.6: A snippet from the obfuscated code from auth.service.ts.

5.5 Technical issues

While implementing this functionality, I ran into several issues. Someissues were caused by incompatibility or lack of documentation, whileothers were just lack of knowledge about the technologies or platforms.

• TypeScript, the superset of JavaScript used in Ionic, is not alwayscompatible if the latest versions are used. To not run into trouble aversion range can be specified, as such npm install typescript@">=3.4.0<3.6.0" –save-dev –save-exact.

• When trying to get location services to work, there are several factorsthat will cause it to error out in a developer environment. Dependingon the battery setting, it will either do network triangulation orcheck Wifi SSIDs. Methods that rely on hardware are, obviously, notavailable in such an environment.

• When enabling code obfuscation, it should be tied to an environmentvariable. So that it is easier to debug code during development andtesting.

• Getting certificates in, e.g., the right format can be hard withoutproper documentation for the plugins. Additionally, as the applic-ation starts to grow, we have to deal with a codebase with compon-ents that were not necessarily made to fit together or be compatible.Finding support or solutions in such cases can be hard.

68

Implementation

• The by far most frustrating experience is caused by the advanced-http-client used to enable native HTTP calls and certificate pinning.It is, of course, native. This completely breaks Ionics live-reloadingfunctionality and slows down the development process tremend-ously. The application will have to be launched in an emulator afterthis is implemented. A solution, depending on the circumstances,could be to use the Angular httpClient for fallback during develop-ment.

69

Chapter 6

Testing

"All parts should go together without forcing. You mustremember that the parts you are reassembling weredisassembled by you. Therefore, if you can’t get themtogether again, there must be a reason. By all means, donot use a hammer."

— IBM Manual, 1925

This chapter will first present some theories, tools, and resources that I findessential in the field of testing mobile applications. In case some of theseterms are unfamiliar, this can be used as a reference or an introduction totesting theory.

6.1 Resources

Listed below are the resources used as a testing framework in this thesis.It is a project from OWASP that consists of three different components andthe CVE for referencing known vulnerabilities.

6.1.1 OWASP MASVS

The Mobile Application Security Verification Standard (MASVS) is a,surprisingly, a newly started project, forked from the well known ASVSproject (an established testing standard for security of Web applications).The extensive resource covers everything from literature, considerations,tools, to test cases (‘OWASP’, 2019). The project has two main objectives:

1. Formalize best practices.

2. Be a mobile-specific, high-level and OS-agnostic.

71

Chapter 6

This makes the project a good fit as it is an industry establishedstandard with formalized best practices. It does not matter if it is anative application or hybrid, as the goals are language-agnostic and equallyrelevant. Examples of requirements and the corresponding level can beseen in Figure 6.2. Summarized MASVS is made up from of:

• 43 Security Requirements.

• 19 Defense-in-Depth Measures.

• 13 Anti-Reversing Controls.

• Covered across 8 different domains.

Version 1.1.4 of the OWASP MASVS project was used during the work ofthis thesis.

6.1.2 OWASP Mobile Security Testing Guide

The Mobile Security Testing Guide (MSTG) is an extensive handbook formobile app security development. As of writing this, it is estimated to beabout 75% complete and consists of approximately 700 pages.

6.1.3 Mobile App Security Checklist

The checklist is an open-source spreadsheet that allows mapping betweenthe OWASP MSTG and the OWASP MASVS, as seen in Figure 6.1. The fulldocument can be found on GitHub.1 Version 1.1.3 of the checklist was usedduring the work of this thesis.

6.1.4 OWASP Summary

The Mobile Application Verification Standard is a superset of rules evolvedfrom OWASP Top 10 Mobile. One hundred forty-six requirements havebeen derived from the list of top 10 vulnerabilities. The project consists ofthree parts that work in conjunction, as seen in Figure 6.1.

6.1.5 CVE

The CVE system provides a reference method for publicly known inform-ation security vulnerabilities and exposures. It can be seen as a database ofsoftware and firmware vulnerabilities. The initiative was launched back in

1The Mobile App Security Checklist is available at https://github.com/OWASP/owasp-mstg/tree/master/Checklists.

72

Testing

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

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

1999 by MITRE, a nonprofit organization that operates research and devel-opment centers sponsored by the US federal government. The aim is to sys-tematically archive vulnerabilities into a free dictionary for organizations.The main purpose is to standardize the way each known vulnerability orexposure is identified. Allowing the security community to have access totechnical information about a specific threat across multiple fields. By vul-nerability, we mean a mistake in software that can be used by a hacker togain access to a system or network. Exposure refers to a mistake in soft-ware that allows access to information or capabilities that can be used as achannel into a system or network.

Depending on the severity of the incident, the vulnerability is given aCVSS score, reflecting its severity. The numerical score can be translated

73

Chapter 6

into qualitative terms such as low, medium, high, or critical. Doing thatallows developers to dispose resources accordingly.

6.2 Tools

Both of these chosen tools have been used in the curriculum for variouscoursed taken here at the university, so I am somewhat familiar withthem. A technical limitation from Chapter 5, is that there is currently nojailbreak for the current version of the operating system. So tools such asSSL killswitch, keychaindumper among others, are unavailable. Anotherpopular tool for security testing not mentioned here is Frida, as I foundBurp to be a better fit with web technologies.

6.2.1 Wireshark

Wireshark is a well known and versatile packet analyzer. It is a tool thatmakes it easy to see captured data in detail and filter the results. Thetool is available for free so that it aligned with the goals set in Section4.6. Wireshark is looked at as an essential tool to determine what ishappening inside a network cable, just like an electrician uses a voltmeterfor examining an electric cable. In this case, the connection is not wired butwireless. It is a beneficial tool to analyze mobile traffic as it is by design noteasily done in the limited mobile environment.

6.2.2 Burp Suite

Wireshark is limited in the manner that it cannot manipulate networktraffic or requests found. This is why we need a tool such as Burp Suite. It isan integrated platform for performing security testing of web applications.It comes bundled with a proxy so that it can intercept traffic from theapplication emulator. It is also open-source and freely available.

6.3 Test results

This section covers the tests for the technical implementation. It is one ofthree parts that will be used in the final evaluation, together with factors ofease of use and risk rating. Some parts are evaluated based on a pass/failbasis in Chapter 5, that covered the implementation details. The approachtaken is based on the Mobile Security Checklist, and it is used as a reference.Since checklist is written with native applications in mind only parts of thetheory and approaches translate to the Ionic framework.

74

Testing

6.3.1 Data Storage and Privacy

• Sensitive data. There are several legitimate reasons an applicationlog behavior either to the console or files; however, this mightdisclose sensitive information. In the implementation, log statementsare implemented in such a way that they are never printed in aproduction environment. In addition, the following snippet can beused in automatic Karma tests to make sure no logging is happening.

describe("Check for logging", function () {beforeEach(function(){

spyOn(window.console, 'log');});

});

When it comes to password and pins, the content should be masked.We can use the same type of automatic checking e.g., the login form,to make sure the attribute type is correctly set to "password".

For sensitive information that should be removed when the ap-plication is backgrounded, I found this to be best tested manually.When viewing the application from the multitasking tray, the splashscreen from Figure 5.2a is correctly shown. This behaviour is presentthrough the entire application and not only for specifics views orpages.

• Device-access-security policy.

In order to test if the pin check tool from Ionic Native works, asimple alert has been set up if no PIN is detected. The applicationis first launched with a system PIN code enabled and then rerun withthe code disabled. When no PIN code is present, the applicationshows an alert, and additional logic can be implemented knowingthis information.

6.3.2 Authentication and Session Management

Since the application utilizes Firebase as a backend service, it handlesmuch of the authentication logic with reduced risk and effort. Duringthe implementation of the native HTTP handler, I found it necessary toinclude the JWT as part of the Authorization header in the Bearer format.This also solved an issue with Cross-Origin Resource Sharing (CORS)since it does not set any cookies. Firebase is a product built on top ofthe Google Cloud Platform and handles all sessions and storage of user

75

Chapter 6

credentials. Redirects and termination of a session seem to be workingas expected. The client is set up so that it is listening on the observableuser object from the backend, and the router guard reacts to changesand redirects away from the restricted pages if the session is terminated.The application stores information in the browsers local storage, as seenin Figure 6.3. This information seems to persistent between sessionsand even after termination. When a federated IdP is used, we have nocontrol over password policies, unlike when credentials are used. Firebasewas mainly chosen because the scope of this project did not include thebackend. However, after implementation and testing, it has proven to be areliable service that ensures all the requirements regarding authenticationare achieved sufficiently.

Figure 6.3: Firebase’s use of local storage.

6.3.3 Network Communication

The way this was implemented in Chapter 5 was that it uses the platformsnative functions and best practices for TLS protocols. At first, I thoughtit was strange that it did not use TLS version 1.3, but it seems to be inline with the current standard for iOS according to Apples documentation(2019). Figure 6.4 show encrypted traffic seen with Wireshark.

Figure 6.4: Encrypted TLS v1.2 traffic inspected with Wireshark.

The client performs two checks for the servers X.509 certificate whenSSL Pinning is enabled.

1. Look at the chain of trust back to the root certificate.

2. See that it matches the hostname.

76

Testing

It is done so that a bad actor cannot get a legitimate certificate and get theclients trust based solely on that. Certificates are easily obtainable and donot need to cost anything, as they are issued for free through a project likeLets Encrypt. However, with this control implemented, we will get an errorbecause, e.g., mafia.com does not have the correct fingerprint, as shown inFigure 6.5. Testing this functionality is not as straight forward since theapplication has to be run in an emulator to make it possible. Because thephone reveals limited information about such information. A solution wasto proxy the traffic from the emulator to a browser like Chrome.

Figure 6.5: Error shown (in Norwegian) due to SSL pinning.

6.3.4 Platform Interaction

Injection flaws, such as SQL injection, are possible although might notas viable as it is for web applications with server-side databases. Sincethe local (encrypted) SQLite database only contains content from the user.Assuming best practices are followed, it should contain no sensitive data.However, queries should not accept arbitrary user input, so that, e.g.,additional logic such as ’1’ = ’1’ can be appended to alter the logic.

As for the Realtime Database and Firestore, they are not vulnerable tosuch attacks. Since the query is not something that requires escaping to beexecuted. Rather, the data is managed by the API, where validation andsecurity rules are set server-side so that Firebase Rules in the cloud is theway that the application enforce authorization.

Since permissions are secure by default for both platforms, the applica-tion needs to request them. Thus the testing revolves around misuse of per-missions and if it is requested at the time of use, as stated by the guidelines.

77

Chapter 6

6.3.5 Code Quality and Build Settings

The automated Karma tests successfully test for unintended logging.Another manual way of doing this is with the console enabled whenrunning an emulator to look for logging artifacts.

• Libraries. To look for vulnerabilities in third-party libraries usedin the application, a manual audit was initiated. During thedevelopment process a Remote Code Execution (RCE) vulnerabilityhad been disclosed with the label severe (Figure 6.6). However, thiswas related to the testing environment and not something that wouldbe present in the final product, as it is a development dependency.A search for every package in package.json was done in the CVEdatabase provided by MITRE with no results.

Figure 6.6: Remote code execution vulnerability found during testing.

6.3.6 Defense in depth

• Root / Jailbreak detection. Jailbreak detection is based on require-ment MSTG-RESILIENCE-1. The methods used in Ionics detectionis not known or documented. As of writing this, the current versionof iOS is 12.3, which I also have installed on my test device. Thereare currently not any known methods for jailbreaking, thus making itimpossible to confirm the feature on the test device.

• Code protection and Obfuscation. During the implementationphase, the Ionic framework was found to be lacking the functionalityto encrypt the applications binary. To verify that the code isobfuscated, we inspect the .ipa file and its contents. This can be donethe following way on a computer running macOS.

1. Change the file extension from .ipa to .zip.

78

Testing

2. Extract all of the folders contents.

3. Navigate to /Payload/MasterBank.

4. Right-click and "Show Package Contents".

5. Locate the www folder to find the compiled source code for theapplication.

Note that the code is not structured in the same way as the source-code of the application. The structure is flattened, and the TypeScriptcode is converted into ES5 JavaScript code and minified. Sincethere is no documented procedure for this in the MSTG, a valuemimicking a key was hardcoded before the application was processedby jscrambler. I was not able to locate the key afterward.

79

Chapter 7

Findings & discussion

7.1 Results & discussion

In the introduction, I outlined three objectives that would help answer theresearch question. To recapitulate, the objectives are:

1. Investigate if there are specific challenges related to the cross-platform framework in general, and how the development andimplementation 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 vectorsfound in a secure manner.

3. Test and evaluate the process and its findings through an establishedtesting standard used in the industry as a means to identify potentialweaknesses that would fit into discovery to answer the researchquestion.

Chapter 6 presented the results of the seven different categories. Whilesome controls were covered in the implementation chapter, they arediscussed with regards to ease of use and risk ranking. The results fromeach of the different areas vary, but there was room for improvement.

Some general findings will be presented as they are span acrossmultiple measurements. Instead of talking about each test requirement,the last chapter showed results for; each domain is discussed as a whole,and recommendations for improvement are given. The limitations of theresearch are discussed and what kind of improvements could be done infuture experiments. Lastly, the problematic areas are given some contextconcerning the severity before the findings are summarised.

81

Chapter 7

7.2 Recommendations for Improvement

For each of the different domains, there where found some improvementsthat could improve Ionic applications.

• Data Storage and Privacy. Researched showed that approximately50% of mobile applications suffered from insecure data storage, andit is second on the OWASP top 10 list (Tokle, 2018). Insecure datastorage can happen in various ways, and it is also the case for hybridapplications, maybe even more than for native. Mechanisms on howto prevent insecure logging and secure application backgroundingwhere demonstrated. By nature, I believe these vulnerabilitieshappen not because of a lack of appropriate mechanisms, but ratherincorrect use and lack of knowledge about how to do this properly.

As proven, encrypted SQLite databases can be achieved for thecross-platform framework. There is no excuse to use HTML5 datastorage or cookies for e.g., tokens that should be stored on the SecureEnclave. The findings would seem to suggest that the best way forimprovement is to make the recommended security practices moreaccessible to developers as default. This could include a streamlinedframework to do debug logging in the console, and log files thatwould automatically excluded when a production application iscompiled. Similarly, a framework that covers both a secure SQLitedatabase and key/token storage would be beneficial. As of right now,they are separate projects, and it is up to each developer to correctlysecure, e.g., the database. It is a place for errors or potentially that itis not done at all, leaving the application vulnerable.

An Enterprise solution that covers, among other things, sessiontokens, is available directly from Ionic. I would like to come with acritique of this way of going about this. As I would argue it is wrongto leave developers on the free tier and their potential customers atrisk. They are even using it as a selling point, and I quote:

Without Ionic Identity Vault, Ionic developers have to re-sort to combining third-party Cordova plugins, often res-ulting in insecure setups due to the lack of correct imple-mentation of biometric and at-rest encryption strategies.

While they, as a company, of course, need paying customers, I findthe way they choose to compromise on security reprehensible.

82

Findings & discussion

• Cryptography. The use of hardware-level encryption was a surpris-ingly good experience from a developers point of view. While cryp-tography is a broad topic that spans across many areas and domainsin mobile security, it is essential the prevention of unauthorized re-trieval of sensitive information from the device. While the CryptoEngine has not been scrutinized, the demonstrated solution shouldprovide the application with adequate standards according to NISTguidelines. There is impossible to give a guarantee against improperuse, and as a general rule of thumb, storage of sensitive data shouldbe avoided. However, the proposed solution solved the two funda-mental ways of how broken cryptography is often manifested in mo-bile applications.

1. Use of a encryption/decryption process that is fundamentallyflawed.

2. Use of an encryption / decryption algorithm that is weak orflawed.

A critique for the framework found is that it is hard to implementcode encryption that prevents reverse engineering and variousanalysis. Instead, it has to rely on obfuscation that is inherently lesssecure.

• Authentication and Session Management. Authentication andsession management is an essential part of most systems, and it isessential to get right. It is the fourth most common thing to getwrong according to OWASP, and many applications are strugglingwith authentication mechanisms. Such as failure to maintain theusers integrity or leave unprotected surfaces within the application.The initial research also found this area to be a common point offailure, but rather than going in the footsteps of previous researchers;I tried to find a different way of doing this. Setting up and configuringa server running, e.g., node.js, express, and passport, to communicatewith the client would certainly be interesting. However, it was notchosen as the approach for several reasons. I did not want to riskto disclose anything I had seen from working with Sopra SteriasWorktime application, as well as to try something new and promisingthat could simplify the problems found in my initial research.

For this project, the Backend-as-a-Service (BaaS) product Firebasewas used. It proved to be easy to implement, and a flexiblesystem as much of the risk is mitigated on to the backend, and the

83

Chapter 7

documentation for implementation on the client-side is well written.According to the Norwegian consultancy firm Bekk, these kinds ofservices were moved to the category "Use this" in their technologyradar back in 2018. Indicating they deliver a satisfactory end result,as also seen in this project. There are some parts I would chooseto do differently in retrospect. Firebase Authentication was chosenbecause it provided seamless integration between authorized usersand CRUD operations to the cloud databases. However, options suchas Auth0, could in many scenarios, be a better fit. It is a much moreflexible solution that more easily fit business to employees identityinfrastructures, like SAML and Active Directory, while being ISO27001/27018 compliant. To get the extended flexibility from Auth0together with Firebase, it could be interesting to look at how to setit up with a custom Firebase token. It could potentially prove tobe a super flexible Enterprise-grade solution for authentication andauthorization running serverless in the cloud.

To conclude, I believe this approach is aligned with the secondresearch objective of prototyping a solution that solves commonpitfalls for the cross-platform framework within this area.

• Network Communication. The findings has shown that if SSLPinning is a requirement for the application, there is only one wayto achieve this. By resolving to a third-party integration that uses theplatforms native HTTP-handler. Although this has several benefits,as mentioned earlier, I found it odd that such a critical part isnot under more strict code reviews and pull request seems to beaccepted haphazardly. It is also a somewhat controversial approachas it misaligned with the general architectural philosophy of theframework. It causes problems down the line for almost every third-party application that assumes the default Angular HTTP-client isused, and breaks the natural development workflow by leaving live-reloading impractical. Although shown possible, it is a troublesomeprocess, and I can understand companies choose not to go with thisapproach and abandon hostname verification.

"Without SSL pinning enforced, an attacker couldman-in-the-middle the connection between the mobileapplications and backend web services. This would allowthe attacker to sniff user credentials, session identifiers,or other sensitive information."

— Ionic Security Inc.

84

Findings & discussion

Stone, Chothia, and Garcia presented a way to black-box test pinnedcertificates. They also stressed in the article the importance ofcertificate verification, as this is a crucial stage in the establishment ofa TLS connection (2017). Georgiev et al., (2012) calls middleware thatis responsible for handling such SSL/TLS traffic the most dangeroussoftware in the world, and the article was published before theHeartbleed vulnerability was known. Given the severity this couldhave, I believe the Ionic framework has a room for improvement ofhow these applications handle HTTP traffic.

• Platform Interaction. Permission management is secure by defaulton both platforms. Although it can be confusing that the platformsdo not share the same permission model in all cases. It should notcause a problem unless the implementation is flawed in the waythat it requests unnecessary permissions. This is mostly a privacyconcern, but I relate this to the CIA triad in Section 5.2, as privacy isroughly on par, or part of, the definition of confidentiality. Althoughprivacy can also be related to the entire CIA triad, where it is seenas an overall goal. To summarize, the framework handle permissionsas expected, even though it can be challenging when different third-party platform integrations handle this in a not-optimal manner.

Investigation showed that premade-components input fields aresanitized by default. Custom written components need to implementthis, and it was demonstrated with the DomSanitizer class. We alsolooked at the differences between the local SQLite statements versusFirebases API calls. Where the latter was favorable as it relied onsecurity controls at the backend, although it has to be addressed, it isnot right to compare them equally in this setting. Since the SQLitedatabase query data locally on the client where Firebase interactswith the backend. If a database with traditional SQL queries whereto be used on the backend, the queries would be performed by theserver, and the client would typically communicate with the datathrough a REST API.

• Defense in depth. Jailbreak/rooting and detection methods is a cat-and-mouse game. Tools to detect this exist for the Ionic platform,although there is no documentation on how this is done and howmany different ways of detection it relies on. MASVS recommends atleast three different approaches. I was unable to confirm this duringtesting, as there is currently no jailbreak available.

If we look at the application sandbox like a jail, the jailbreak term

85

Chapter 7

makes sense. It is essentially privilege escalation for the purposeof removing restrictions imposed by the operating system. Thesecurity community seems divided on how to deal with jailbrokendevices. The mobile banking app of Norway’s largest bank willjust force quit at launch without any notice if a jailbreak is detected.Although it is a terrible user experience, the bank takes the stance thatjailbroken devices are not allowed to access banking services. Mostother bank seems fine with it, including banks that have chosen thecross-platform approach. Another approach is the one chosen by thepassword manager, LastPass. It is a popular service that certainlycontains sensitive information. If a jailbroken device is detected, thefollowing prompt is shown to the user before they are allowed tocontinue.

"It looks like this is a jailbroken device. Please keep in mindthat jailbreaking weakens the security of all applications,including this one."

Code protection was found to be a problematic area for the frame-work. Ionic is lacking the functionality to encrypt the applicationsbinary properly and is vulnerable to injection attacks. While not per-fect, obfuscation and anti-tampering mechanisms can be done withjscrambler. If it were tied together with code locking, self-defendingtechniques, and JavaScript integrity checks, it would in all probabil-ity, be a real struggle to reverse engineer the application.

During the literature search, I found that Brucker & Herzberg tooka novel approach and used static analysis to examine the foreignlanguage calls of Cordova applications (2016). They found thatan attacker becomes more powerful as it introduces new securitychallenges with regards to, e.g., an XSS attack. In contrast, thisthesis looked at approaches for preventing such attacks on theabstraction layer that better facilitate interoperability and platformindependence. Bessey et al. concluded that tools for static analysisis more widely available and is on the rise (2010). This matchesmy discovery, and during the work of this thesis, it has becomeevident that tools, such as TSlint, is preferred to increase readability,maintainability, and reduce functionality errors by developers. WhileBessey et al. point out that too many tools might have a negativeeffect on technical development, a nice balancing empirical tautologyholds that bug-finding is worthwhile for anyone with an effective tool

86

Findings & discussion

(2010). For the criteria set for such tools, I refer to Section 4.6.

7.3 Risk rating

The test results create a picture of the state of security for applicationsdeveloped with the Ionic framework. However, some vulnerabilities aremore critical than others. Initially, a SQL injection attack might seem severe,but taken into consideration that the database is running locally, there isa difference in the type of sensitive information present compared to abackend database; thus the impact is different.

There are several possible approaches to risk analysis. Here we usethe OWASP risk rating mythology introduced in Chapter 4. Another thingto take into consideration is the threat agents. It is far more likely thatan attacker would want to target the backend services or try to accessother parts of the contents of the phone, rather than information storedwithin the application sandbox. However, this again depends on thingssuch as skill level, motive, opportunity, and the size of the agents. Thefull overview of the chain of risk hierarchy that are factors of severity wasintroduced in Section 4.4. Bellow are factors, with an example range, thatplay a role in determining the severity of a risk. Note that typically, therisk ranking framework would be customized, with factors affecting thebusiness weighted more heavily. However, only technical factors that affectimpact were considered here, since, e.g., reputation or financial damage isimpossible to predict in this case.

• Factors for Estimating Likelihood

– Threat Agent Factors

1. Skill level: ranging from no technical skills (1) to being aprofessional pen-tester (9).

2. Motive: low (1) to high (9).3. Opportunity: Once every leap year (1) to no special occasion

required (9).4. Size: A programmer (1) to unlimited anonymous Internet

users (9).

– Vulnerability Factors

1. Ease of discovery: Almost impossible (1) to automa-tion/search (9).

2. Ease of exploit: Theoretically possible (1) to script kiddie tool(9).

87

Chapter 7

3. Awareness: Unkown (1) to publicly disclosed (9).4. Intrusion detection: Guaranteed detection (1) to not possible

(9).

• (Technical) Factors for Estimating Impact

1. Loss of confidentiality: Minimal (1) to everything (9).

2. Loss of integrity: Minimal (1) to maximal (9) corruption.

3. Loss of availability: Unnoticeable (1) to all (9) services interrupted.

4. Loss of accountability: Fully traceable (1) to anonymous (9).

0 to <3 Low3 to <6 Medium6 to 9 High

Table 7.1: Likelihood and impact levels

Each requirement was assessed and given a rating according toTable 7.1. The severity correlates with how likely a threat agent canexploit the vulnerability (likelihood) and the potential damage impact,as given by Formula 4.1. For the full table see Appendix B.1. Themost important findings are summarised together with findings from thetechnical implementation in the next section.

7.4 Summary

This section will revisit the research question and answer it based on thefinding of this thesis. The research question is:

Which security challenges exist for a favored mobile cross-platformframework and what security concerns are relevant when developingfor it?

The most significant contribution and answer to this question wasthe PoC application. In the initial stage of the process, a comprehensiveliterature search was conducted. Taken together with the initial steps ofrisk assessment, several potential problematic domains were systematizedaccording to an established testing framework. Requirements of particularinterest were presented in Section 3.3. After implementation, testing,and further analysis, the most striking results to emerge from this isrecapitulated bellow.

88

Findings & discussion

• Secure Storage. With the currently available tools, developers haveto resort to combining third-party Cordova plugins. This can result ininsecure setups due to the lack of correct implementation guidelinesand documentation or incompatibility. Affecting everything fromsecure storage to authentication.

• Certificate verification. Perhaps the most surprising discovery is theabsence of a solution that does this and is secure by default. Theonly solution is to use third-party code. It lacks documentation,receives intermittent updates, is un-user-friendly, and contradicts thearchitectural principles.

• Code protection. This support previous findings in the literature thatapplications built with web technologies are harder to tamper-proofand are more easily modified or reverse engineered.

Given that the metrics in Table 7.2 and Figure 7.1 are based on a limitednumber of requirements, the results should consequently be treated withconsiderable caution.

Result from test deviceP F N/A %

V1: Architecture, Design and Threat Modelling 5 3 5 62,50%V2: Data Storage and Privacy 8 2 1 80%V3: Cryptography Verification 6 0 0 100%V4: Authentication and Session Management 6 1 3 85,71 %V5: Network Communication 4 1 0 80%V6: Environmental Interaction 4 2 4 66,67 %V7: Code Quality and Build Settings 6 0 3 100 %V8: Resiliency Against Reverse Engineering 2 0 13 100 %

Table 7.2: Test results from the eight different categories.

89

Chapter 7

Figure 7.1: Mobile Security Checklist compliance score for the test results.

90

Chapter 8

Conclusion

"The only truly secure system is one that is powered off,cast in a block of concrete and sealed in a lead-lined roomwith armed guards."

— Gene Spafford

This study has gone some way towards enhancing our understanding ofsecurity in the mobile landscape. The thesis presented an application as anapproach to investigate security controls for a cross-platform framework.It was an experiment to look at specific challenges related to the unificationof platforms and how these technologies differ from traditional mobilesecurity concerns. Different paths for future research were also addressed.

The most significant contribution to this project was the theoreticaland technical statement about the implementations, and the effort putinto finding problematic attack vectors for Ionic applications presented inSection 7.4. This paper has underlined the importance of three potentiallyproblematic areas for the framework and proposed solutions for variousother discoveries. While some topics did not fit the scope of this project,it has the potential to contribute to a better understanding of securityin cross-platform applications. The problem with a lot of the securitymeasurements shown - and security in general - is that we do not knowwhat we do not know. Relevant conference topics could be addressed,expert advice followed, and apparently have everything implementedcorrectly. However, there might be unforeseen factors affecting security,which we do not realize.

Developing webview applications certainly comes with its own set ofsecurity hindrances. Nevertheless, it remains a useful alternative if theclient-side is low on features with need for device-specific hardware, andthird-party integrations can be used to fill the gap. On the surface, someof the possible attacks discussed here were general concepts, while others

91

Chapter 8

are more technology-specific. While choosing between the current crop ofhybrid frameworks for cross-platform applications, one must understandthat these frameworks implement a web-to-native bridge for platformfeature access, which breaches the browser sandbox. This theoreticallyenables malicious code to access critical information residing on the device.In general, it is vital that developers have security in mind and that theapplication is built following best practices.

"Think of developers and security like business ownersand the law. You do not need to know everything aboutthe law in order to run a business, but you should have agood enough understanding that you are able to identifypotential issues and seek help where it is required."

— Josh Morony

8.1 Limitations

There were some limitations that must be taken into consideration wheninterpreting these results and the study in general.

During the time of writing this thesis, I only had an iPhone available asa test device. This means that the Android application might have behaveddifferently on a real device than through an emulator. The results andexperience might have been different if it were tested on a real device.

Initially, during the planning phase of this thesis, the idea was tocompare two cross-platform frameworks, such as Ionic and React-native. Imassively underestimated the time it would take to implement the features,and in the end, just a few requirements ended up taking an absurd amountof the development time.

The attack vectors and counter measurements are by no means acomprehensive list of everything essential to secure a hybrid application.For that, I refer to, e.g., the Mobile Security Testing Guide. Despite thefact that the scope of this work did not cover all concerns regardingcross-platform security, interesting discoveries were found. The attackvectors chosen were based on the scope, research during the initial phase,and how they fit together as a whole. I also tried to balance the setof functionality somewhat to include potential problematic areas, whereinteresting discoveries could be found.

92

Conclusion

8.2 Future work

Further work needs to be carried out to expand the coverage. This workonly covered a subset of security controls for one framework. I wish toemphasize the need to explore other frameworks and additional securitycontrols. While attack vectors get hardened continually, the securitylandscape is always changing, and new exploits are being developed allthe time. I hope that this research can serve as a base for future studies inthe field of secure cross-platform mobile application development.

93

Bibliography

Abrahamsson, R. & Berntsen, D. (2017). Comparing modifiability of react nat-ive and two native codebases (Master’s Thesis, Linköpings universitet).

Allen, M. (2006, January 20). A day in the life of mobile data. InMobile security, british computer society. The Chartered Institute for IT.Retrieved from http://www.bcs.org/server.php?show=conWebDoc.2774

Apple. (2019, May). iOS security guide: iOS 12.3 (12.3). Apple Inc. Retrievedfrom https://www.apple.com/business/docs/site/iOS_Security_Guide.pdf

Bessey, A., Block, K., Chelf, B., Chou, A., Fulton, B., Hallem, S., . . . Engler,D. (2010, February). A few billion lines of code later: Using staticanalysis to find bugs in the real world. Commun. ACM, 53(2), 66–75.doi:10.1145/1646353.1646374

Bhavani, A. B. (2013, April 28). Cross-site scripting attacks on androidWebView. arXiv:1304.7451 [cs]. arXiv: 1304.7451. Retrieved from http://arxiv.org/abs/1304.7451

Brucker, A. D. & Herzberg, M. (2016). On the static analysis of hybridmobile apps. In J. Caballero, E. Bodden & E. Athanasopoulos (Eds.),Engineering secure software and systems (pp. 72–88). Lecture Notes inComputer Science. Cham: Springer International Publishing. doi:10.1007/978-3-319-30806-7_5

Chen, E. Y., Pei, Y., Chen, S., Tian, Y., Kotcher, R. & Tague, P. (2014). Oauthdemystified for mobile application developers. In Proceedings of the2014 ACM SIGSAC conference on computer and communications security(pp. 892–903). ACM.

Chin, E. & Wagner, D. (2014). Bifocals: Analyzing WebView vulnerabilitiesin android applications. In Y. Kim, H. Lee & A. Perrig (Eds.), Inform-ation security applications (pp. 138–159). Lecture Notes in ComputerScience. Springer International Publishing.

Cross Platform Apps Development. (2019). Retrieved from http : / /infiniumtech.org/products/details/2/staccker-trading-simplified

95

Decan, A., Mens, T. & Constantinou, E. (2018, May). On the impact ofsecurity vulnerabilities in the npm package dependency network.In 2018 IEEE/ACM 15th international conference on mining softwarerepositories (MSR) (pp. 181–191). 2018 IEEE/ACM 15th internationalconference on mining software repositories (MSR).

Dodig-Crnkovic, G. (2002). Scientific methods in computer science. InProceedings of the conference for the promotion of research in IT at newuniversities and at university colleges in sweden, skövde, suecia (pp. 126–130).

Enge, E. (2018, April 27). Mobile vs desktop usage in 2018: Mobile widensthe gap [Stone temple]. Retrieved from https://www.stonetemple.com/mobile-vs-desktop-usage-study/

Eskola, R. (2018, June 18). React native performance evaluation (Master’sThesis, Aalto University). Retrieved from https://aaltodoc.aalto.fi:443/handle/123456789/32475

Facemire, M., Schadler, T., Gill, M. & Sellers, E. (2019, December 2). It’s timeto make every web application a progressive web app. In Forrester.Forrester. Retrieved from https://www.forrester.com/report/Its+Time+To+Make+Every+Web+Application+A+Progressive+Web+App/-/E-RES143551#

Feiman, J. & Zumerle, D. (2013, May 24). Avoiding mobile app develop-ment security pitfalls. In Gartner research. Retrieved from https : / /www.gartner.com/en/documents/2496315/avoiding-mobile-app-development-security-pitfalls

Freitas, R. (2009). Scientific research methods and computer science. InProceedings of the MAP-i seminars workshop.

Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D. & Shmatikov,V. (2012). The most dangerous code in the world: Validating SSLcertificates in non-browser software. In Proceedings of the 2012 ACMconference on computer and communications security (pp. 38–49). CCS’12. event-place: Raleigh, North Carolina, USA. New York, NY, USA:ACM. doi:10.1145/2382196.2382204

Gröger, C., Silcher, S., Westkämper, E. & Mitschang, B. (2013). Leveragingapps in manufacturing. a framework for app technology in theenterprise. Procedia CIRP, 7, 664–669.

Hale, M. L. & Hanson, S. (2015). A testbed and process for analyzing attackvectors and vulnerabilities in hybrid mobile apps connected to restfulweb services. (pp. 181–188). IEEE.

96

Huynh, M., Ghimire, P. & Truong, D. (2017). Hybrid app approach: Couldit mark the end of native app domination? Issues in Informing Science& Information Technology, 14, 49–66.

Introduction to cross-platform hybrid development for architects. (2018, January).Retrieved from https : / / ionicframework . com / books / hybrid - vs -native

Jaramillo, D., Newhook, R. & Smart, R. (2013). Cross-platform, securemessage delivery for mobile devices. In Southeastcon, 2013 proceedingsof IEEE (pp. 1–5). IEEE.

Kensington. (2011). Cost of stolen or lost laptops, tablets & smartphones.Luo, T., Hao, H., Du, W., Wang, Y. & Yin, H. (2011). Attacks on WebView in

the android system. In Proceedings of the 27th annual computer securityapplications conference (pp. 343–352). ACM.

Mobile App Security Testing. (2019, September 17). Retrieved from https://github.com/OWASP/owasp-mstg

Mujaj, A. (2017). A comparison of secure messaging protocols and implementa-tions (Master’s Thesis, University of Oslo, Oslo).

Neugschwandtner, M., Lindorfer, M. & Platzer, C. (2013). A view to a kill:WebView exploitation. In LEET.

NowSecure. (2019). Mobile security primer. NowSecure. Retrieved fromhttps://books.nowsecure.com/secure- mobile- development/en/primer/mobile-security.html

Olalere, M., Taufik Abdullah, M., Mahmod, R. & Abdullah, A. (2015, April10). A review of bring your own device on security issues - morufuolalere, mohd taufik abdullah, ramlan mahmod, azizol abdullah,2015. (Vol. 5). 2. SAGE journals. Retrieved from https : / / journals .sagepub.com/doi/full/10.1177/2158244015580372

OWASP. (2019, August 21). Retrieved from https : / / www. owasp . org /index.php/About_The_Open_Web_Application_Security_Project

OWASP.org. (2016). OWASP - improper platform usage [Mobile top 10 -improper platform usage]. Retrieved from https://www.owasp.org/index.php/Mobile_Top_10_2016-M1-Improper_Platform_Usage

OWASP.org. (2019a, September 17). Introduction to the mobile security testingguide. Retrieved from https://mobile- security.gitbook.io/mobile-security-testing-guide/overview/0x03-overview

OWASP.org. (2019b). Mobile top 10 2016 -extraneous functionality - OWASP.Retrieved from https://www.owasp.org/index.php/Mobile_Top_10_2016-M10-Extraneous_Functionality

97

OWASP.org. (2019c, June 27). OWASP risk rating methodology - OWASP.Retrieved from https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

Perrin, A. (2017, June 28). 10 facts about smartphones [Pew research center].Retrieved from https://www.pewresearch.org/fact-tank/2017/06/28/10-facts-about-smartphones/

Pfleeger, C. P., Pfleeger, S. L. & Margulies, J. (2015, February 5). Security incomputing (5 edition). Upper Saddle River, NJ: Prentice Hall.

Phung, P. H., Mohanty, A., Rachapalli, R. & Sridhar, M. (2017, May).HybridGuard: A principal-based permission and fine-grained policyenforcement framework for web-based mobile applications. In 2017IEEE security and privacy workshops (SPW) (pp. 147–156). 2017 IEEEsecurity and privacy workshops (SPW). doi:10.1109/SPW.2017.34

Rummel, J. F. & Ballaine, W. C. (1963). Research methodology in business.Harper & Row.

Schleier, S., Mueller, B., Willemsen, J. & OWASP. (2019). Mobile securitytesting guide (1.1.3). Retrieved from https://mobile-security.gitbook.io/mobile-security-testing-guide/

Schweber, A. (2013). Unprotected mobile devices at risk with growingmobile theft epidemic.

Security in a Multi-Device World: The Customer’s Point of View. (2013,September). Kaspersky Lab. Retrieved from https : / / media .kaspersky.com/pdf/Kaspersky_Lab_B2C_Summary_2013_final_EN.pdf

Shehab, M. & AlJarrah, A. (2014). Reducing attack surface on cordova-based hybrid mobile apps. In Proceedings of the 2nd internationalworkshop on mobile development lifecycle (pp. 1–8). MobileDeLi ’14.Portland, Oregon, USA: ACM. doi:10.1145/2688412.2688417

Søhoel, H. M. (2018). OWASP top ten - what is the state of practice amongstart-ups? (Master’s Thesis, Norwegian University of Science andTechnology, Trondheim).

Stack overflow developer survey. (2018). Retrieved from https : / / insights .stackoverflow.com/survey/2018/

Stone, C. M., Chothia, T. & Garcia, F. D. (2017). Spinner: Semi-automaticdetection of pinning without hostname verification. In Proceedings ofthe 33rd annual computer security applications conference (pp. 176–188).ACSAC 2017. event-place: Orlando, FL, USA. New York, NY, USA:ACM. doi:10.1145/3134600.3134628

Su, K.-W., Chen, C.-N., Kuo, N.-H. & Tseng, H.-H. (2014). Applying TAMmodel to evaluate the indoor parking guidance and information

98

system. In Proceedings of the international MultiConference of engineersand computer scientists (Vol. 1).

Tokle, M. (2018, November 14). Mobile hacking. Retrieved from https : / /www.uio.no/studier/emner/matnat/ifi/IN5290/h18/lectures/forelesning_mobilehacking_marittokle_revidert.pdf

Tu, Z., Turel, O., Yuan, Y. & Archer, N. (2015, June 1). Learning to copewith information security risks regarding mobile device loss or theft:An empirical examination. Information & Management, 52(4), 506–517.doi:10.1016/j.im.2015.03.002

99

Appendices

101

Appendix A

Mobile ApplicationVerification Standard testresults

103

Mobile Application Security Requirements - iOS

ID Detailed Verification Requirement Level 1 Level 2 StatusV1 Architecture, design and threat modelling1.1 Verify all application components are identified and are known to be needed. � � Pass1.2 Verify all third party components used by the mobile app, such as libraries and frameworks, are identified, and checked for known vulnerabilities. � � Pass1.3 Verify that security controls are never enforced only on the client side, but on the respective remote endpoints. � � Pass

1.4 Verify that a high-level architecture for the mobile app and all connected remote services has been defined and security has been addressed in that architecture. � � N/A

1.5 Verify that data considered sensitive in the context of the mobile app is clearly identified. � � Pass1.6 Verify all app components are defined in terms of the business functions and/or security functions they provide. � N/A1.7 Verify that a threat model for the mobile app and the associated remote services, which identifies potential threats and countermeasures, has been produced. � N/A

1.8 Verify all third party components have been assessed (associated risks) before being used or implemented. Additionally verify that a process is in place to ensure that each time a security update for a third party component is published, the change is inspected and the risk evaluated. � Fail

1.9 Verify that all security controls have a centralized implementation. � N/A

1.10 Verify that all components that are not part of the application but that the application relies on to operate, are clearly identified and the security implications of using those components are known. � N/A

1.11 Verify that there is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800-57. � Pass

1.12 Verify that remote endoints ensure that connecting clients use the current version of the mobile app. � Fail

1.13 Verify that security testing is performed as part of the development lifecycle. If some or all of the testing is automated, the configuration of the testing tools must be tailored to the specific app. � Fail

V2 Data Storage and Privacy2.1 Verify that system credential storage facilities are used appropriately to store sensitive data, such as user credentials or cryptographic keys. � � Pass2.2 Verify that no sensitive data is written to application logs. � � Pass2.3 Verify that no sensitive data is shared with third parties unless it is a necessary part of the architecture. � � Pass2.4 Verify that the keyboard cache is disabled on text inputs that process sensitive data. � � Fail2.5 Verify that the clipboard is deactivated on text fields that may contain sensitive data. � � Pass2.6 Verify that no sensitive data is exposed via IPC mechanisms. � � Pass2.7 Verify that no sensitive data, such as passwords and credit card numbers, is exposed through the user interface or leaks to screenshots. � � Pass2.8 Verify that no sensitive data is included in backups. � Pass2.9 Verify that the app removes sensitive data from views when backgrounded. � Pass

2.10 Verify that the app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use. � N/A2.11 Verify that the app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode. � Pass

2.12Verify that the app educates the user about the types of personally identifiable information processed, as well as security best practices the user should follow in using the app.

� Fail

V3 Cryptography 3.1 Verify that the app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption. � � Pass3.2 Verify that the app uses proven implementations of cryptographic primitives. � � Pass

3.3 Verify that the app uses cryptographic primitives that are appropriate for the particular use-case, configured with parameters that adhere to industry best practices.� � Pass

3.4 Verify that the app does not use cryptographic protocols or algorithms that are widely considered depreciated for security purposes. � � Pass3.5 Verify that the app doesn't re-use the same cryptographic key for multiple purposes. � � Pass3.6 Verify that all random values are generated using a sufficiently secure random number generator. � � PassV4 Authentication and Session Management

4.1Verify that if the app provides users with access to a remote service, an acceptable form of authentication such as username/password authentication is performed at the remote endpoint.

� � Pass

4.2 Verify that the remote endpoint uses randomly generated access tokens to authenticate client requests without sending the user's credentials. � � Pass4.3 Verify that the remote endpoint terminates the existing session when the user logs out. � � Pass4.4 Verify that a password policy exists and is enforced at the remote endpoint. � � Pass

4.5Verify that the remote endpoint implements an exponential back-off, or temporarily locks the user account, when incorrect authentication credentials are submitted an excessive number of times.

� � Pass

4.6Verify that biometric authentication, if any, is not event-bound (i.e. using an API that simply returns "true" or "false"). Instead, it is based on unlocking the keychain/keystore.

� Pass

4.7 Verify that sessions are terminated at the remote endpoint after a predefined period of inactivity. � Fail4.8 Verify that a second factor of authentication exists at the remote endpoint and the 2FA requirement is consistently enforced. � N/A4.9 Verify that step-up authentication is required to enable actions that deal with sensitive data or transactions. � N/A

4.10Verify that the app informs the user of all login activities with his or her account. Users are able view a list of devices used to access the account, and to block specific devices.

� N/A

V5 Network Communication5.1 Verify that data is encrypted on the network using TLS. The secure channel is used consistently throughout the app. � � Pass5.2 Verify that the TLS settings are in line with current best practices, as far as they are supported by the mobile operating system. � � Pass

5.3 Verify that the app verifies the X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a valid CA are accepted.� � Pass

5.4Verify that the app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if signed by a trusted CA.

� Pass

5.5 Verify that the app doesn't rely on a single insecure communication channel (email or SMS) for critical operations, such as enrollments and account recovery. � FailV6 Environmental Interaction6.1 Verify that the app only requires the minimum set of permissions necessary. � � Pass

6.2Verify that 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.

� � Pass

6.3 Verify that the app does not export sensitive functionality via custom URL schemes, unless these mechanisms are properly protected. � � N/A6.4 Verify that the app does not export sensitive functionality through IPC facilities, unless these mechanisms are properly protected. � � N/A6.5 Verify that JavaScript is disabled in WebViews unless explicitly required. � � Pass

6.6Verify that WebViews are configured to allow only the minimum set of protocol handlers required (ideally, only https). Potentially dangerous handlers, such as file, tel and app-id, are disabled.

� � Fail

6.7 Verify that the app does not load user-supplied local resources into WebViews. � � Fail6.8 Verify that if Java objects are exposed in a WebView, verify that the WebView only renders JavaScript contained within the app package. � � N/A6.9 Verify that object serialization, if any, is implemented using safe serialization APIs. � � N/A

6.10Verify that the app detects whether it is being executed on a rooted or jailbroken device. Depending on the business requirement, users are warned, or the app is terminated if the device is rooted or jailbroken.

� Pass

V7 Code Quality and Build Settings7.1 Verify that the app is signed and provisioned with valid certificate. � � Pass7.2 Verify that the app has been built in release mode, with settings appropriate for a release build (e.g. non-debuggable). � � Pass7.3 Verify that debugging symbols have been removed from native binaries. � � Pass7.4 Verify that debugging code has been removed, and the app does not log verbose errors or debugging messages. � � Pass7.5 Verify that the app catches and handles possible exceptions. � � Pass7.6 Verify that error handling logic in security controls denies access by default. � � Pass7.7 Verify that in unmanaged code, memory is allocated, freed and used securely. � � N/A7.8 Verify that security features offered by the compiler, such as stack protection, PIE support and automatic reference counting, are activated. � � N/A7.9 Verify that Java bytecode has been minified. � � N/A

LegendSymbol DefinitionPass Requirement is applicable to mobile App and implemented according to best practices.Fail Requirement is applicable to mobile App but not fulfilled. N/A Requirement is not applicable to mobile App.

Resiliency Against Reverse Engineering - iOS

Resiliency Against Reverse Engineering Requirem

entsR

StatusA

pp Isolation8.1

Verify that the app provides a custom keyboard w

henever sensitive data is entered.�

N/A8.2

Verify that custom UI com

ponents are used to display sensitive data. The UI components should not rely on im

mutable data structures.

�N/A

Impede D

ynamic A

nalysis and Tampering

8.3Verify that the app im

plements tw

o or more functionally independent m

ethods of root detection and responds to the presence of a rooted device either by alerting the user or term

inating the app.�

Pass

8.4Verify that the app im

plements m

ultiple functionally independent debugging defenses that, in context of the overall protection scheme, force adversaries to invest

significant manual effort to enable debugging. All available debugging protocols m

ust be covered (e.g. JDWP and native).

�N/A

8.5Verify that the app detects, and responds to, tam

pering with executable files and critical data.

�N/A

8.6Verify that the app detects the presence of w

idely used reverse engineering tools, such as code injection tools, hooking framew

orks and debugging servers.�

N/A8.7

Verify that the app detects, and response to, being run in an emulator using any m

ethod.�

N/A8.8

Verify that the app detects, and responds to, modifications of process m

emory, including relocation table patches and injected code.

�N/A

8.9Verify that the app im

plements m

ultiple different responses to tampering, debugging and em

ulation (requirements 9.2 - 9.6), including stealthy responses that

don't simply term

inate the app.�

N/A

8.10Verify all executable files and libraries belonging to the app are either encrypted on the file level and/or im

portant code and data segments inside the executables

are encrypted or packed. Trivial static analysis should not reveal important code or data.

�N/A

8.11Verify that obfuscating transform

ations and functional defenses are interdependent and well-integrated throughout the app.

�Pass

Device Binding

8.12Verify that the app im

plements a 'device binding' functionality w

hen a mobile device is treated as being trusted. Verify that the device fingerprint is derived from

m

ultiple device properties.�

N/A

Impede Com

prehension

8.13Verify that the app uses m

ultiple functionally independent means of em

ulator detection that, in context of the overall protection scheme, force adversaries to

invest significant manual effort to run the app in an em

ulator (supersedes requirement 9.5).

�N/A

8.14Verify that if the architecture requires sensitive inform

ation be stored on the device, the app only runs on operating system versions and devices that offer hardw

are-backed key storage. Alternatively, the inform

ation is protected using obfuscation. Considering current published research, the obfuscation type and parameters are

sufficient to cause significant manual effort to reverse engineers seeking to com

prehend or extract the sensitive data.�

N/A

8.15Verify that if the architecture requires sensitive com

putations be performed on the client-side, these com

putations are isolated from the operating system

by using a hardw

are-based SE or TEE. Alternatively, the information is protected using obfuscation. Considering current published research, the obfuscation type and

parameters are sufficient to cause significant m

anual effort to reverse engineers seeking to comprehend the sensitive portions of the code and/or data.

�N/A

LegendSym

bolD

efinitionPass

Requirement is applicable to m

obile App and implem

ented according to best practices.Fail

Requirement is applicable to m

obile App but not fulfilled. N/A

Requirement is not applicable to m

obile App.

Appendix B

Severity list rating forrequirements

Requirement Description Likelihood Impact SeverityData Storageand Privacy

V2.3No sensitive data iswritten to application logs.

High Low Low

V2.7

No sensitive data, such aspasswords or pins, isexposed through the userinterface.

Medium Medium Medium

V2.9The app removes sensitivedata from views whenbackgrounded.

Low Medium Medium

V2.11

The app enforces a minimumdevice-access-security policy,such as requiring the user toset a device passcode.

Low Medium Medium

Cryptography

V3.1

The app does not rely onsymmetric cryptographywith hardcoded keys as asole method of encryption.

Medium High High

V3.2The app uses provenimplementations ofcryptographic primitives.

Medium Medium High

107

Table B.1 continued from previous pageRequirement Description Likelihood Impact Severity

V3.3

The app uses cryptographicprimitives that are appropriatefor the particular use-case,configured with parametersthat adhere to industry bestpractices.

Medium High High

V3.4

The app does not usecryptographic protocols oralgorithmsthat are widelyconsidered depreciated forsecurity purposes

Medium High High

Authenticationand SessionManagement

V4.1

If the app provides usersaccess to a remote service,some form of authentication,such as username/passwordauthentication, is performedat the remote endpoint.

Low High Medium

V4.2

If stateful session managementis used, the remote endpointuses randomly generatedsession identifiers to authenticateclient requests without sendingthe user’s credentials. If statelesstoken-based authentication isused, the server provides atoken that has been signed usinga secure algorithm.

Medium Medium High

NetworkCommunication

108

Table B.1 continued from previous pageRequirement Description Likelihood Impact Severity

V5.2

The TLS settings are in line withcurrent best practices, or asclose as possible if the mobileoperating system does notsupport the recommendedstandards.

Medium High High

V5.3

The app verifies the X.509certificate of the remote endpointwhen the secure channel isestablished. Only certificatessigned by a trusted CA areaccepted.

Medium High High

V5.4

The app either uses its owncertificate store, or pins theendpoint certificate or publickey, and subsequently doesnot establish connections withendpoints that offer a differentcertificate or key, even if signedby a trusted CA.

High Medium Medium

V5.6The app only depends onup-to-date connectivity andsecurity libraries.

High Medium Medium

PlatformInteraction

V6.1The app only requests the minimumset of permissions necessary.

Medium Medium Medium

V6.2

All inputs from external sourcesand the user are validated and ifnecessary sanitized. This includesdata received via the UI, IPCmechanisms such as intents,custom URLs, and network sources.

Medium Medium Medium

Code Qualityand BuildSettings

109

Table B.1 continued from previous pageRequirement Description Likelihood Impact Severity

V7.2

The app has been built in releasemode, with settings appropriatefor a release build(e.g. non-debuggable).

Low High Medium

V7.4Debugging code has been removed,and the app does not log verboseerrors or debugging messages.

Medium Low Low

Defence in depth

V8.1

The app detects, and responds to, thepresence of a rooted or jailbrokendevice either by alerting the useror terminating the app.

High Medium Medium

V8.9

All executable files and librariesbelonging to the app are eitherencrypted on the file level and/orimportant code and datasegments inside the executablesare encrypted or packed. Trivialstatic analysis does not revealimportant code or data

Medium Medium Medium

V8.10

Obfuscation is applied toprogrammatic defenses, which inturn impede de-obfuscation viadynamic analysis.

Low Medium Low

Table B.1: Severity listed for each of the requirements.

110