Mobile Application Security Improvement

Mobile App security issue

With the increasing popularity of Mobile Devices, almost everybody uses mobile applications, but hardly anyone thinks of their data security while using them! At the same time, when developing system applications, there’s a tendency to focus on Site security rather than on the Application. Security is taken for granted, relying on the backend, where there may also be vulnerabilities.
A poorly protected mobile application can be a serious threat to an entire system. Mobile devices are where we store and work on critical data such as in payments, access, for medical and banking information, almost certainly for personal data, etc.

The problem of mobile application security is, especially concerning in various Android systems. Mainly because as it’s an open system, it is more vulnerable to data breaches at the operational level than Apple iOS (which is a closed system). Android is very fragmented, new versions of the system are deployed to customers’ devices very slowly, which directly impacts the improvement of the entire system’s security. It does not mean your Apple iOS system is completely safe – there are threats related to storing data or web server communication (a Man in the Middle attack) which may make your application vulnerable.

To add perspective to the problem, let’s consider the following examples;

Data and device interception

A Mobile App security breach can be related to several issues, from storing users’ data without encryption in the localised database (which was the case of a popular communication app in 2011) to session token change (a problem for a well-known marketplace application in 2016). The mobile app switched sessions to a different user’s token, most probably collected from deep links. This, through a fake marketplace site, made way for the potential theft of other users’ account data, such as user ID, profile photo, phone numbers, date of birth, access logs, and much other private information.

There are also several examples where an entire device has been compromised through a system vulnerability. Back in 2017, there was a significant security loophole discovered in a Bluetooth driver called BlueBorn; this allowed attackers to obtain complete control of a mobile phone by remotely executing code. In 2018, another issue was discovered; in order to control device modems, an Android firmware used AT commands (dating back to the 1980s). Manipulating these commands allowed hackers to gain control of the entire mobile device. Luckily, you don’t have to worry about BlueBorn issues anymore – it is already fixed on the majority of Android devices running 6.0 or greater and in iOS 10 and greater.

Such vulnerabilities can be used for a variety of reasons, for example, to create false certificates to obtain the data streaming out of your mobile app or install malware to obtain user data. These issues were rather quickly fixed at the operational level, but the question remains as to the extent of the breach. Normally, system loopholes unfortunately result in users waiting for an upgrade and ensuring app security personally.

Ensuring Mobile Application Protection

Ensuring mobile protection is an ongoing process, A most common methodology is to follow a standard security practice; more are now being adapted;.

Standard security practices may include:

The encryption of sensitive personal data, including encryption of the local database, cache, or API communication
The correct cryptographic key management and user session authorisation (tokens)
Token validations – the assigning of one to each consecutive device separately and with different session expiration times
Implementation of safe communication standards, e.g. certificate pinning in the case of HTTPs

Mobile-specific security methodology may include:

The protection against malicious apps
- blocking screenshots or masking
- Masking the mobile app view in the app switcher – preventing any preview of the mobile app’s content when switching to a different app
- securing the clipboard – so a copied password is not visible in other mobile apps
- IPC protection (Inter-Process Communication) – a security measure applied to system components to enable communication between mobile apps and the system, such as Activities, Services, Broadcast Receivers, Content Providers
UI security analysis, specifically in terms of data leaks (e.g. password masking or data validation)
Anti-tampering
Android-specific:
- Code Obfuscation – these limit reverse engineering
- Proper handling of mobile app signatures
- Blocking access to overlapping active mobile apps – protection against content scraping done through different apps layered on top of the active mobile app
- managing permissions in Android apps
iOS-specific
- Using App Transport Security (ATS) for all internet connections
- Enable the File Data Protection
  All the stated methods cover just some of the risks but be aware of them! Secondly, implementation or verification may require particular expertise.

How does SPG Controls ensure the security of Mobile Applications?

Mobile security is our priority. SPG Controls will ensure our Mobile Applications adhere to industry standards and are robust and resilient to attack.

Security Review

The security review can be done in five steps:
1. SPG Controls review the project to better understand the source code, structure, and purpose of the application.
2. SPG Controls make a list of the application’s various elements responsible for introducing risk to the project.
3. SPG Controls prepare a list of the application security features that should be implemented for all elements, and then verify if all the required security features are in place.
4. After a thorough analysis, if needed, a rescue plan will be created – SPG Controls prepares the list of security protocols which should be implemented.
5. Finally, SPG Controls will maintain the security level of the Mobile Application and ensure it is in the future updates.

Secure Authorisation

Specific permissions dictate the features available to the end user. Permissions are based on asset of assigned roles (or access groups). There are also “Access Policies” defined, which are additional rules needed to access a resource, such as what times an operator is allowed to access a specific resource. An operator who is logged in to the system with more than one role, for example as an Administrator, an Engineer and as a Guard, will be able to select a role and this will define which objects can be viewed with what permissions.

API Integration

The ARCO Platform provides the ability to interface to many 3rd party systems using an Open API. The API is based on the latest Web-based Restful Architecture. All data contained within the ARCO Platform is securely exposed to the 3rd party systems. All commands, events and configuration changes are logged by ARCO including the property changes made, so there is a full Audit trail.