Data security has always been on the to-do list for mobile app development, especially for those who place an emphasis on user privacy. With Snowden still hitting news headlines, data security remains a hot topic in the press and a pressing concern for mobile app developers. We decided to write an article on the topic to shed some light on mobile app safety locks.
Data security is crucial for sensitive data
In practice, there’s no need to lock up most data in the majority of mobile apps. And to be honest, no digital service can ever offer 100 percent data security. However, this doesn’t mean that we should ignore data security mechanisms altogether.
There are various ways to make a user trust your product or service, and not all of them involve building sophisticated locks and implementing encryption. If you have some doubts about whether or not to build high-tech security features into your mobile product, you can always give it a sober mathematical look by calculating the value of the data stored on your server and the amount of money you would need to spend to lock it up safely.
In case the rupture is pretty wide, it doesn’t make much sense to give it a shot. If you don’t have a server or you wouldn’t prefer to take responsibility for any important information that can be submitted, it is necessary to make it clear for a user. Google forms, for example, put a note: "Never submit passwords through Google Forms."
If it would cost a whole lot more to lock up and encrypt your data than your data is worth, then if may not make business sense to do so. If you don’t have your own servers — or if you would prefer not to take responsibility for the security of your user’s data — then clearly let your users know. Google Forms, for example, includes a reminder to “Never submit passwords through Google Forms.” Do they expect their data to be hacked? No. But they’re reminding us that it’s better to be safe than sorry.
Also, remember that data security is never complete without a backup solution. If all else fails, a reliable backup will allow you to restore your data instead of starting over from scratch.
Thankfully, the data stored on your server is at lower risk of attack if it’s properly protected. For secure data storage, always use the HTTPS protocol.
NOTE: It is important to prevent HTTPS caching by configuring iOS properly. In addition, HTTPS caching headers should be configure to avoid caching of URL history and page data for any Web process such as registration. The HTTPS protocol supports a “no-store” directive in a response header that instructs the browser that it must not store any part of either the response or the request that elicited it. Additional information on caching headers may be found here.
A mobile attack can be directed at almost everything that the app is built on — the device, the network, the data center (including web server and database) or even all of these components at once.
Attacks targeting the device
Mobile device attackers can enter through a browser, mail app, or any other pre-loaded applications, as well as through the operating system and SMS and wireless communication channels such as Bluetooth and NFC.
Browser-based attacks work largely by tricking users to reveal confidential information. These attacks include phishing, clickjacking, framing, drive-by downloading, man-in-the-mobile, etc. For users, the best defence is to check URLs and not open any suspicious messages or requests. Research has shown that mobile users are three times more likely than desktop users to submit personal information to phishing websites.
Many apps do not properly validate SSL certificates, leaving them susceptible to man-in-the-middle attacks. In addition to ensuring the SSL session is valid, the URLs being accessed should not be stored in an easily modifiable format in the binary itself. By simply modifying the URL in the binary, an attacker could change the domain in the URL to their own, for which they may possess a valid SSL certificate.
To prevent OS-based attacks a developer should consider a better programming paradigm and avoid simple logic.
Example: if sessionIsTrusted == 1
In the same vein, simple logic variables stored in an object can be easily manipulated by an attacker.
Example: session.trusted = TRUE
When a session is not trusted, privileges should be enforced by the server, or certain data must be prevented from being decrypted or available until the app determines that the session is trusted again by challenge/response, OTP, or some other method.
Reverse engineering an Android app (.apk file) is rather easy, which means that the internal mechanisms of an application can be fully examined. What can we as developers do about it? For starters, we can complicate and obfuscate the code as described in this Android developer reference.
iOS applications are also susceptible to reverse engineering attacks due to the way they are designed. An app’s classes and protocols are stored within the object file, allowing an attacker to fully map out the application’s design. If the application handles highly sensitive data, consider implementing anti-debug techniques.
Among possible targets of a phone or SMS-based attack is a phone’s GSM/3GPP baseband processor, responsible for receiving and sending radio signals with cell towers. In a network attack of this sort, the attacker operates a rogue Base Transceiver Station (BTS) in the vicinity of the targeted Mobile Station (MS). The rogue BTS sends out system information messages announcing the availability of a network that the targeted mobile station wants to connect to.
The attacker may force the MS to connect to its rogue base station by simply transmitting with a stronger signal than the legitimate base station. The process can be sped up by using the GSM jammer to selectively jam the frequency of the legitimate BTS. Here’s a description of how this kind of attack can be fought.
Another SMS-based attack is SMiShing — which sounds related to “phishing” and in fact implements does intend to deceive users by sending messages prompting them to visit phishing sites and enter usernames, passwords and credit card numbers.
The most interesting attacks are RF Attacks, such as Bluejacking (you can read about it in one of our Bluetooth articles) and NFC attacks.
Let’s take a look at the following attack points:
Even if your app doesn’t process or store confidential user information, people’s habits of reusing usernames and passwords can lead them to inadvertently share sensitive information. In a worst case scenario, leaked social media login credentials could be the same as online banking credentials, meaning that a data breach for a seemingly insignificant mobile app could be a real financial and identity risk.
No Encryption/weak encryption — Algorithms can contort data into unintelligible text that can only be deciphered with the proper key. But 10 percent of applications, according to viaForensics’s study, fail to encrypt your password. Apps that transmit unencrypted or weakly encrypted data are vulnerable to attacks.
Improper SSL validation — SSL is an app’s secure socket layer, whose certificates are very important to fully validate. SSL certificates should be properly installed and configured for the highest levels of encryption (enable only strong ciphers —128-bit and up — and SSLv3/TLS). At present, the TLSv1.2 protocol offers the latest technology and strongest encryption ciphers available.
Config manipulation — Config manipulation is when an attacker manipulates files or settings external to a target application that nonetheless affect the behavior of that application. This includes gaining unauthorized access to administrative interfaces, configuration stores, and retrieving clear text configuration data.
For example, many applications use external configuration files and libraries — and modification of these entities or affecting the application’s access to them would constitute a configuration/environment manipulation attack. This is more applicable to backend protection solutions aimed at plugging holes in this vulnerable part of the client-server bundle.
However, even SSL certificate centers that seem to be trustworthy may actually be responsible for issuing fraudulent certificates. As a negative example, you can read about how Comodo had problems with security.
Dynamic runtime injection — Attackers can manipulate and abuse an app’s runtime to bypass security locks and logic checks to access privileged parts of an application and even steal data stored in memory.
We need to check user-entered data to make sure it doesn’t include malicious scripts that, when added to the database, may disrupt its integrity and a provide a malicious user access to data.
To minimize the risk of such an attack, active sessions should be terminated any time an app is not actively utilized for more than 5 minutes. To resume use after a session is terminated, a user should be required to re-enter credentials. When an app’s session has timed out, the application should also discard and clear all memory associated with user data, as well as any master keys used to decrypt data.
NOTE: In order to provide visual transitions within the interface, iOS has been proven to capture and store snapshots (screenshots or captures) as images, stored in the file system portion of a device’s NAND flash.
For an iOS device, this means that either the home button is pressed or a phone call or other event temporarily draws the user out of the application. Temporary images saved by iOS often contain user and application data. To protect sensitive data, we can block caching of application snapshots using API configuration or code.
Also, when an iOS app is about to be sent to the background, we should ensure it isn’t displaying any sensitive information. We can ensure this using the willEnterBackground API and creating a splash screen to display as the app moves into the background.
Unintended permissions — Misconfigured apps can sometimes open the door to attackers by granting unintended permissions. A user can avoid these attacks by carefully examining the permissions that an app requests upon installation and refusing to install if the permissions requested have no relation to the app’s functions.
Strong User Authentication
The point of user authentication is to make data accessible for only one user. To access data, a user must have credentials that are difficult to impersonate. Ideally, a user authentication mechanism should satisfy the goals of security, efficiency, usability and universality (or deployment on a wide range of devices and servers).
Passwords are universal and relatively efficient, though sometimes weak.. Security experts recommend using letters and numbers in all passwords, avoiding passwords that have an actual meaning, never using the same passwords or usernames for multiple applications, and avoiding writing your passwords down, especially online where they could be discovered by an outsider.
If a mobile app handles sensitive data or transactions, at times you cannot fully rely on usernames and passwords alone for sufficient security. To increase security, implement two-factor authentication.
The second factor in two-factor authentication may be:
An additional secret word
A code provided by SMS or email
An additional user-known value (e.g. last four digits of SSN)
A Security question/answer, set by the user in advance (e.g. What is your mother’s maiden name?))
NOTE: For the highest level of security it’s possible to use one-time passwords that require a user to possess a physical token that generates time-sensitive single-use passwords.
We can increase the security of user names by storing masked usernames and by replacing username values with has values. A hash value can be created using a unique device token stored at registration. In this case, if a value is simply copied to another device or used on the web, it will not be valid, because the actual username is obscured by a device-specific hash value.