Home References What’s Threatening Your Mobile Applications?

The last few years have witnessed an upswing in the number of mobile application downloads. To illustrate, as per data released by Statista, in 2009, the number of mobile applications downloaded globally stood at approximately 2.52 billion. This number is expected to reach 268.69 billion in 2017.

Nevertheless, this uptake has given rise to a number of challenges-security being the most crucial. According to DataTheorem, the security threats landscape facing mobile applications vastly differs from that of web or client/server applications. This difference is owing to the multi-dimensional nature of mobile applications and the fact that these applications can access certain types of data, which web applications cannot. Broadly, these include call history, SMS logs, contact lists, geo-location, etc.

Categories of mobile application threats

DataTheorem has segregated mobile application threats into five categories:

  • Data loss from security vulnerabilities
  • Unauthorized/private data collection
  • Data exposure to other applications
  • Data exposures at-rest (on the device)
  • Data exposures in-transit (over the network)

Threats to mobile apps

Security vulnerabilities

Security vulnerabilities largely arise from code level issues and/or run-time flaws in the application. Security issues at the code-level in operating platforms such as Objective-C (iOS), Java (Android), and C# (Windows Phone) can harm the application, the customer, and the data itself. In addition, application logic attacks are equally vulnerable. This refers to where attackers abuse the application using existing (or the lack thereof) security controls. Common runtime attacks include, but are not limited to, escalation of privilege, authentication bypass, and session manipulation.

Examples of this kind of threat include Objective-C/Java (Code level) security issues, local or remote injection and application logic issues.

Unauthorized/private data collection

Mobile applications often gather data from a device or a customer without explicit permission. This often includes sensitive data as well, which ideally ought never to be used by a third-party entity. Examples include retrieval of UDID or IMEI, bundled geo-location, IDFA, and UserID and collection of contact list/pictures/SMS logs.

Data exposure to other applications

Mobile applications are at risk of data exposure to any other application running on the system. The iOS, Android, and the Windows Phone operating systems have deployed a sandbox model to prevent data sharing between one application and another. In a nutshell, this is designed to not only keep the customer’s data safe but to ensure each application functions independently of one another as well. While the implementation of the respective sandboxes differs on each operating system, all of them are designed to create silos for each application. The threat arises when the sandboxes do not isolate one application from another, either by design or an implementation flaw.

Examples include passwords shared via UIPasteboard, data stored in SD cards or temporary directories and data caching to public locations.

Data exposures-at rest

According to DataTheorem, as online activity continues to migrate from traditional web applications to mobile-based ones, the possibility of a user’s data being exposed increases multi-fold. Therefore, a customer must be aware of the kind of data they can store on a device that will eventually be in the control of unauthorized parties. Examples of this kind of threat include password on file systems, browsing history stored in temporary directories and PII or financial data stored on the device.

Data exposures-in transit

Due to the high likelihood of mobile devices joining non-trusted networks, third-party malicious entities can target the communication layer much faster than before (as compared to desktops or laptops). Examples of this kind of threat include a customer’s geo-location being leaked to a third party source, an invalidated SSL and credit card numbers transferred in the clear.

You may also like

Leave a Comment