The apps market has grown a lot in several areas, mainly financial, such as banks and investment brokers. This scenario also brings a concern for the security of data and capital within smartphones. Developing secure code for mobile is paramount for risky applications and considerably reduces possible fraud and leaks. In addition to reassuring the user when installing the app and providing permissions.
There are generic recommendations and platform-independent particularities for developing secure code for mobile. Follow some options:
1- Sandboxing
Mobile operating systems have very different characteristics from traditional operating systems. When we talk specifically about mobile device (smartphone), the concept of multiuser is not necessary. Operating systems are relieved of resource management in this regard and can focus on more emerging security issues, such as controlling the application execution environment.
Application sandbox is the isolation of the entire app scope in a protected way, where another app cannot access the application data, such as database and others. Here the execution is done in a separate process, at kernel level. Unlike Windows desktop programs, for example, it creates different file directories in Program Files and other applications (viruses and malware) that allows access.
As the Sandbox is simple and auditable, for an application to break it would have to compromise kernel security. A bad programming practice that breaks Sandboxing is storing data in external memory, as it opens the scope of the application and it is vulnerable.
2- Database protection with encryption and code obfuscation
SQLite is the most used relational database management system on Android, as it integrates a module to access these databases. However, the API provided by this module is not user-friendly and is relatively simplified, not doing special character checks on parameters. SQL injection attack prevention should be implemented on the client side and encryption should use user-supplied key (such as PIN) for added security.
Obfuscated code makes your APK difficult to reverse engineer, which is especially valuable when the app uses security-sensitive features like licensing verification, for example. For code obfuscation on Android, ProGuard is great as it obfuscates, optimizes bytecode, removes unused code statements, and minifies remaining classes, fields, and methods with short names. For iOS there are commercial tools like Morpher, Metaforic, Arxan, LLVM Obfuscator and some third party libraries that propose this.
3- Permissions from third-party libraries
Misuse of authorized permissions is perhaps one of the most susceptible points of application attack. This is not a bug or vulnerability in the system, but rather the way the permissions mechanism was designed. Nothing prevents an application from requesting permissions or being approved by the user, however, nothing guarantees that the application will use them only for the advertised features.
For example, a written message management application can request permissions for reading, writing, sending messages and can also request phone calls if you want, for example, a button to call directly the sender of messages. Under these conditions, there is no way to guarantee that the application will send messages or make calls only when the user clicks on the associated control in the interface. This is also a limiting factor that will make the user install or not your application, since the OS makes the user responsible for the privilege that each application will have.
When following a How To Use of a third-party library you are using, you should be careful about the user permissions it asks for and check in the code that they are only being used for the intended purpose. A malicious library can lead users to be victims of toll fraud (attacks aimed at the use of telephone services).
4- Using Secure HTTPS Protocol
The vast majority of applications make requests to services on servers and encryption is also a security practice on this side. In the normal HTTP protocol, data is sent in plaintext within network packets and anyone using a sniffer, which is a program that captures packets, can see their contents. However, if the content of the data that travels on your connection is of important confidentiality, such as bank details or personal emails, the Secure Socket Layer (SSL) provides a strong encryption that is very difficult to be cracked. HTTPS is nothing more than HTTP over SSL.
This way, if someone inspects your data packets without knowing the cryptographic keys used, the content will only consist of an apparently random and meaningless sequence of bytes. Using HTTPS prevents attacks based mainly on intercepting data and altering packets exchanged between client and server.
5- Use secure authentication methods
Two-factor authentication (or “2FA”) is a form of identification of the user to the service provider, using a combination of two different authentication methods. These components can be something the user knows (such as a password or PIN), has (keyfob or cell phone), or something that is linked or inseparable from the user, such as a fingerprint.
For apps, we can use a simple four, six or eight character password combined with confirmation via SMS or push notification, or some of the famous authentication APIs from Facebook, Google or LinkedIn. There are also facial recognition methods, such as Smart Lock built into Android version 5.0, and biometric reading method, such as Android Fingerprint version 6.0. For banking and fintech systems, the recommendation is to kill sessions when the application is placed in the background and use electronic signature at runtime to perform risky operations, such as financial transactions and stock trading.
The electronic signature is volatile and gets lost from time to time. Credit card data, passwords, and access tokens are almost never saved when the user logs out and re-enters the screen.
6- Community Open Web Application Security Project (OWASP)
OWASP — Open Web Application Security Project is a global non-profit organization focused on improving software security, especially web-based software, but also extends to mobile. Its mission is to make application security visible so that people and organizations can make informed decisions about the true application security risks and help developers take precautions and build applications with a high level of security.
OWASP updated the Top 10 with the most critical mobile application security attacks. See the full 2016 list here.
Conclusion
These were some recommendations that can be applied when developing secure code for mobile. As they have different security architectures, the platforms need to be analyzed separately. When it comes to the Android world, it is recommended not to develop applications that run in root mode, in addition to not accessing sensitive data when there is another application running in root mode. Protecting “Intents”, “Activities”, “Content Providers”, “Broadcast” and “Services” and not allowing the app to be installed on devices with “BlackMarket” are also good practices. In the iOS context, it is strongly recommended to use the CFNetwork API to validate secure connections and the “KeyChain” technology for key storage, in addition to not allowing installations on devices with “JailBreak”.
Therefore, adopting good coding and architecture practices aimed at mobile application security, despite not guaranteeing 100% success against fraud and attacks, is essential in preventing threats. Making it difficult for intruders and malicious code to act in your application will reduce user resistance when installing an app that works with risky information.
*This post was written for the Cedro Tech blog in 2018.
