In the IoT space, mobile applications are similar to the web application models previously discussed. Although discussing specific details about security models for mobile device platforms is beyond the scope of this book, having a foundational knowledge of mobile application development models will help with testing when moving forward.
Mobile applications in IoT
Hybrid
Mobile applications installed on an Android, iOS, or Windows phone device can be hybrid or native. Although the terms hybrid and native have different meanings in the mobile application sense rather than web applications, the principals are similar. A hybrid application utilizes both web technologies, such as HTML/HTML 5, CSS, and JavaScript, as well as some native platform hardware, such as GPS or Bluetooth. Access to hardware resources is only through the use of plugins provided by the hybrid framework. Think of hybrid apps as web applications packaged up into a wrapper that the native platform can use. This means that a web developer can now code a mobile app without having the learning curve of a new language.
Hybrid applications use one code base for multiple platforms, such as Windows Phone, Android, and iOS, which is a huge plus when thinking of the first to market for IoT devices. Applications are called over the web using an embedded web browser known as WebView. There are many hybrid frameworks that the most popular apps use in the market today, such as Apache Cordova, Adobe PhoneGap, and Xamarin, to name a few.
Each of the mobile hybrid frameworks contains a third-market place which contains plugins for various features. Some frameworks such as Xamarin are written in one programming language (C#) and translated into a native language (Objective C and Java) for rapid development purposes. These mobile frameworks are known to have a number of security advisories ranging from critical remote code execution issues on the native platform to privacy concerns. If you happen to notice a certain mobile hybrid framework being utilized, it might be a good idea to have a look at a vulnerability database for easy wins.
To give you a better idea about the architecture it takes to run a hybrid application, the following diagram shows the different components between the application code, WebViews, plugins, and the mobile device itself. Keep in mind, most of the wrapper code and plugins are developed by the hybrid framework or third-party developers who contribute to the framework:
Hybrid application example
Native applications
Native applications are built for specific operating systems and written within the device platform's native language, such Java, Objective C, Swift, and even C# for Windows phones. Native applications use their respective platform SDKs, which gives the app access to hardware such as the camera, Bluetooth, and GPS. Performance and security are better with native apps but they are dependent on an experienced developer who knows a native language. This may be difficult, in some cases, for staffing developers as platform APIs often update and deprecate language classes or methods. More and more, platforms such as iOS and Android are developing native security APIs that developers can take advantage of without the need for utilizing third-party libraries. This is important for secure communication and secure data storage.
A native architecture is much simpler than hybrid application architectures. The following diagram shows a native application running native code directly on the device without the need for third-party components to access hardware resources:
Native application example
It's important to understand the pros and cons of each mobile application model for efficient testing. As device control is delegated to mobile apps, they are another attack entry point into a device that can sometimes be easier than another entry point. In Chapter 5, Exploitation of IoT Mobile Applications, we will delve into some of the most common vulnerabilities in IoT mobile apps as we dissect an IoT device.
