LiveOverflow published an interesting video on Mobile Application Security where he tackled the Attack Surface of mobile applications and a case of a security 'researcher' who oversells the results of his work.

Mobile Applications are built on top of an environment that has attack surface reduction in mind, through the use of sandboxing, explicit permission model, automated updates and the offering of an API that tries to be secure by default.

However, some Mobile Applications do however expose a critical attack surface that requires special attention, either due to the technology stack they are based on, the kind of usages the application offers or the interaction that the application has with other components. Another key factor to take into account is the need for these environments to add more features and functionalities. These features offers room for developers to be creative in finding new ways to use our phones, but at the same time increases the attack surface. Take for instance iOS App Extension, this functionality similar to Android intents was added later on to the iOS ecosystem.

These are few examples that we have seen in the past as security critical vulnerabilities but are very specific to the Mobile environment:

Remotely exploitable JavaScript injection in JavaScript-based applications:

Applications developed using JavaScript Framework, like Cordova, Ionic, might be vulnerable to JavaScript or HTML injection. These vulnerabilities can be leveraged into remote code injection due to the nature of the API exposed through these Frameworks.

For such a vulnerability to be considered critical, the attacker must have the capacity to send the malicious input to other users without any special interaction.

For instance, a sport's app that allows users to share their progress through a personal wall. If that wall is vulnerable to JavaScript injection (XSS), then any user who views the wall of the attacker will be compromised.

Even HTML injection vulnerabilities might be transformed into JavaScript injection via JavaScript Gadget attack.

Memory corruption in native code through untrusted input:

Several applications handles the parsing of binary formats like Audio, Video and Images using native libraries. A memory corruption vulnerability in these libraries using an untrusted input will result in a remote code execution.

For instance, if a chat application that allows sending voice recording in MP4 format, suffers from a memory corruption vulnerability, this will result in remote code execution in the context of the application.

Java, Kotlin, Objective C and Swift are all memory safe languages unless unsafe APIs are used, however linking against libraries in C and C++ opens the door for these kind of vulnerabilities.

Intent injection in browsable Activities exploited using drive-by attacks in Chrome:

Chrome allows sending intent with extra parameters to activities with the Browsable category. An application vulnerable to injection through the intent extra parameters is vulnerable to driveby exploitation.

The attacker may either entice the victim into visiting his malicious page, or serve the attack using Ads for instance. Firefox browser requires extra user interaction to trigger intent sending, while most other browsers on mobile devices do not support this feature.

Communication over clear-text traffic or using insecure TLS/SSL server certificate validation:

The impact of this vulnerability depends on the nature of the exchanged data. For instance if either the authentication phase or any session enabled action is performed over insecure channels, this will result in the compromise of the users' session.

If the application is developed in JavaScript Frameworks, the retrieval of remote JavaScript or HTML will result in a remote code execution. If the application downloads a shared library (.so, .dex, .jar) over insecure channels, this will also result in remote code execution.

An example of this vulnerability is the use of ALLOW_ALL_HOSTNAME_VERIFIER:

ALLOW_ALL_HOSTNAME_VERIFIER implementation don't perform any validation:

Session management shared between Mobile and Web application and the lack of Web related protection on the Mobile Backend:

Web Applications share the same browser with other web applications, which creates opportunities for a set of attacks that are not applicable to mobile applications, like CRSF, session hijacking through all sorts of XSS and even Clickjacking.

In general, these attack vectors are absent for Mobile Applications, therefore developers don't need to implement any security protection against these attacks.

Some Mobile Application backends do however share the session management system between the web and the mobile backend, which creates the opportunity for an attacker to link against the mobile backend from the browser and exploit these vulnerabilities.