How to Secure Mobile Payment Applications

As the general trend suggests use of mobile apps are on the rise day by day. More than half of all time spent of digital media is spent on mobile apps. The average time spent on mobile apps is increased by 21% over the past year. With the growing usage of mobile payment applications by users for all purposes such as banking, payments; the focus of the malicious users has shifted towards the mobile apps too.

Source: https://www.arxan.com/resources/state-of-application-security/

Mobile apps provide ease of use and access. In order to stay competitive in the market and in a hurry to launch applications, often businesses do not pay attention to the security of the application. The infographic ^[2] below shows the amount budgeted for security by organizations.

It becomes imperative for organizations and companies to secure mobile payment apps in 2024 to ensure their users are protected and their security posture is held high for brand trust.

In addition, the Information Security Community is also trying to spread awareness for the same to make businesses realize the need to secure mobile payment apps. This blog is one such effort to spread the awareness and to guide on how to secure the mobile applications at the development level.
Source: https://www.arxan.com/resources/state-of-application-security/

On a broader level mobile payment apps are affected by following Top 10 Vulnerability classifications formulated by OWASP.

The different controls which need to be taken into account to secure mobile payment apps are discussed below. These help is ensuring that security is implemented during development itself and is not left as an added testing effort after the development.

Step-1: Increase Code Complexity and Use Obfuscation

As seen in the infographic above, Lack of Binary Protection is the major vulnerability that is not addressed in majority of the mobile apps. This has many implications. It is very easy to reverse engineer the original java code (for Android) and repackage the same for malicious purposes or to gain competitive advantage. iOS applications can also be reverse engineered as the application classes and protocols are stored within the object file. Reverse engineering of apps can provide valuable insight into how the app works.

By making them more complex internally, it will be more difficult for attackers to see the clear operation of the app, which may reduce the number of attack vectors. It is recommended that the code be obfuscated to increase the difficulty of examination by malicious users. Obfuscate all sensitive application code where feasible by running a code obfuscation program using either third party commercial software or open source solutions.

Step-2: Exercise caution while using borrowed code

For the reason of meeting project timelines and making work load easier, many developers tend to use existing free code available in the web and customize it to build the application around it. Appropriate are must be taken to ensure there is no malicious code plugged into the code. Use codes from a trusted third party. Care should be taken to do a full secure code review of the code before use.

Step-3: Lock-down mobile payment applications’ permissions

For securing applications we should follow the principle of least privilege assignment of permissions. At the architecture level, the application should be assigned only the minimum required permissions. The permissions may include numerous hidden paths to personal data stored on devices like contact lists, device memory, SMS folders, GPS locations, etc. All such permission need to be provided only if needed. For instance, read-write (rw-) permissions should not be granted when only read (r–) permissions are required.

Step-4: Restricting debuggers and tracers

By incorporating a system call, an application can instruct the operating system to not allow a debugger to attach to a process. By preventing a debugger from attaching, an attacker will not be able to interfere or analyze with the low-level runtime variables and system info. An attacker must first work around the debugging restrictions in order to attack an application at the base level. This adds further complexity to an attack.

An application can be coded to determine whether it is being tracked by a debugger or other debugging tool. If it is being traced, the application can be programmed to respond with actions for possible attack scenarios, such as notifying a server administrator, discard or disallow access to encryption/decryption keys or other such response actions to defend itself.

Step-5: Insecure storage in mobile payment applications

Data is stored by the application in /data/data/<application name> or in /sdcard. The data in /data/data/<application name> cannot be accessed by another application unless the application explicitly provides permissions for access or if the device is rooted. Data that is stored in /sdcard can be accessed by any application without any special permission or rooting. Hence, it is common for malicious applications to access data stored in external memory i.e. /sdcard.

When evaluating an application’s storage, ensure that both online and offline storage is evaluated. The focus should be on the code that allows storage of the data locally and ensure that no sensitive data is stored on the client side. Minimize the sensitive data that needs to be stored on the device. If any data needs to be stored, then it should be protected in storage by encrypting it using a strong algorithm prior to storage.

Step-6: Insecure storage in process memory

Data processed by the application may be stored within memory longer than necessary, which makes it more susceptible to attack. When using sensitive data such as encryption keys, do not keep them in RAM longer than required. An attacker with access to the phone may be able to dump the memory of the process to gain access to sensitive information.

Step-7: Secure communications to server by the mobile payment applications

Ensure the communication between the application and the servers is always secure and that data transmitted cannot be intercepted or exploited by MITM attacks. Make use of encryption and SSL certificates (TLS 1.2) to ensure data is not intercepted during transmission. In fact HTTPS is often neglected and HTTP is preferred. And even if developers use HTTPS technologies they may still overlook numerous aspects of certificate verification so, once again, this field required extra attention.

Step-8: Sensitive Data Disclosure

If the application logs data at the client-side it can be easily retrieved by an attacker if he is able to gain access to the device. Sensitive data such as passwords, card number should never be logged. Another control to ensure is to prevent caching. Developers can configure iOS and Android applications to not cache web data, particularly secure (HTTPS) traffic, as this may contain sensitive or private information. The server headers should be set appropriately to instruct the browser/app not to cache data. Given the widespread use of mobile apps in public places, it is beneficial to store and display partial phone number on the device to protect privacy.

Ensure apps do not display system info in warnings and error pages and are tested thoroughly to avoid crashes. Consider disabling NSAssert for iOS, as this setting will cause an app to crash if an assertion fails. From a security perspective, handling a failed assertion can be performed in more graceful manner than to crash the application and generate logs. Also, the mobile payment applications crash logs should not be sent in plaintext over an unencrypted network.

Step-9: Use strong passwords and not PINs

Android applications usually require a PIN for authentication instead of a password, the reason being ease of use, as it is cumbersome to enter a long password from a mobile device. However, it is important to point out that PINs are easier to brute force. For stronger security passwords should be used instead of PINs. Also if security is of utmost importance such as for banking applications it is recommended to have a session timeout and not to keep the user logged in.

Step-10: Perform data validation

Data validation issues in apps are not considered seriously during performing a code review after development. However, this is a primary point of entry for attackers. All data validation issues like buffer overflow, format string issues, can become applicable for mobile applications as well. When using native code, special care needs to be taken when data is read from an untrusted source.

Step-11: Release regular patches for the mobile payment applications

Responsibility towards keeping the app secure does not end with the release of the app. Hackers use new ways to launch attacks and exploit the potential vulnerabilities. Periodic security updates ensure your app addresses all security loopholes which may exist or come up.

Source:http://www.mcafee.com/in/resources/white-papers/foundstone/wp-secure-coding-android-applications.pdf

Though the adage “prevention is better than cure” is widely understood, many companies often overlook crucial security measures in their quest to expedite development cycles. By implementing these 11 steps, your organization can effectively secure mobile payment apps in 2024 and fortify against future threats and vulnerabilities.

Learn more about PCI DSS Compliance service provided by SISA Infosec