8 App Security Issues You Need to Know About
8 App Security Issues You Need to Know About
Securing your mobile app isn't an option anymore. In this post, we take a look at eight security issues you should know about--and be planning to avoid. Read on for the details.
Join the DZone community and get the full member experience.Join For Free
Over 1,000 apps are released every day, and hackers have taken notice. No matter what your role in your business’ app development strategy is, you need to know what the most common security issues are—and how to avoid them.
Mobile security entails many of the challenges that encompass rapid development, multiple integrations, and users that operate typically outside of traditional enterprise IT controls and boundaries.
1. Trusting Built-in Platform Security
There are dozens of app development platforms to choose from, but none of them are immune to security issues. On the mobile OS side, Apple's iOS platform has long been considered the most secure because all apps go through a tedious screening process before being approved for users and becoming available on iTunes. Unfortunately, this doesn’t guarantee all of Apple's apps are secure because the screening process can’t account for every threat and vulnerability.
Android takes a different approach to security by approving all new apps and letting users sort out the good ones from the bad ones with reviews and feedback from their devices. Both systems have their flaws, and it shows you can't trust any app platform to protect its users entirely. There are just too many variables for app platforms and operating systems to consider.
2. Using Code from Other Developers
It takes a lot of time to develop an app from the ground up, so a lot of developers leverage existing open-source code to speed up the process. Open-source makes up 90% of most modern applications and now represents the largest and weakest attack surface for hackers. Unfortunately, some hackers create malicious code in the hopes that app developers will pick it up to use in their apps, thus hackers are leveraging developer’s tendency to trust 3rd party code and solutions in order to have the developer do the dirty work for them.
There's nothing wrong with building upon the ideas of others, and open-source code can be a real time-saver, but you have to do perform your due diligence to ensure that 3rd party code is safe to use and continue to validate its security to ensure it remains safe to use over time. Leverage solutions that specialize in monitoring and identifying 3rd party vulnerabilities and augment this with your own tools, techniques, and processes. Build relationships with those vendors to facilitate open communication and open pathways to remediate flaws and bugs that are discovered. Use vetted solutions; trust but verify yourself (i.e. do not blindly trust a source): trusted sources for code.
3. Not Planning for Caching and Logging Vulnerabilities
Avoid caching app data. Proper technique is required to store data securely on a mobile device. The safest method is to simply not store or cache any data to mitigate compromise of the data on the device.
There is a multitude of ways data is captured in unintentional ways. Developers often overlook some of the ways data can be stored:
- Log and debug files
- Web cache and history
- Property lists and files
- SQLite databases
- KeyStore and Keychain
Debug logs are generally designed to be used to detect and correct flaws in an application. Similarly, when an app crashes valuable information becomes available to an attacker in the form of the resulting crash log. Both of these logs can leak sensitive information that may aid an attacker craft another attack. Limit the use of “Remember Me” like features. Example: If the user enables the “Save this User ID” feature, the username is cached within the CredentialsManager object on iOS.
Both iOS and Android store what users type in order to provide features such as customized auto-complete, autocorrect, and form completion. Sensitive data can also be stored as a result.
When these words are cached in the keyboard cache, the contents are beyond the administrative privileges of the application, and so the data cannot be removed from the cache by the application.
At runtime, the username is loaded into memory before any type of authentication occurs, allowing the potential for a malicious process to intercept the username. Similarly, encrypted data must be decrypted and can be scraped from memory on the device resulting in information leakage.
You may consider prevention techniques by programming the cache to automatically be wiped every time the mobile device reboots or when the app exits. You can also utilize technologies such as Single Sign On and Touch ID to avoid some types of credential exposure.
Image caching is also another potential point for an information leak. Apps that allow the user to take a picture of a document using the phone’s camera and upload it to the financial institution to deposit in an account or file an expense report, often leave the image of the check in the phone’s NAND memory even after it is deleted.
The application is a concern as well. iOS captures and store snapshots as images which are stored in the file system area of the device NAND flash. This occurs when an application suspends an app in the background when the home button is pressed, or another event temporarily suspends the application. To restore the app with a smooth visual transition, that cached application image is stored and retrieved. These images can often contain user and application data (depending what data the app was displaying at the time it was suspended).
Traditional approaches to overwriting a file generally do not work on mobile devices due to the aggressive management of the NAND Flash memory. As such files can remain in a file until overwritten even when they are deleted (e.g. file.delete()) and may be carved from memory.
These are just a few examples.
4. Thorough Security Testing
If you’re an app developer, you are the primary line of defense. If you do not ensure your app is secure, you put all of your app's users and their data at risk. That means you should never rush to release an app before you have properly tested it from a security and privacy perspective.
At a minimum, you should perform static and dynamic analysis of your applications.
With static application security testing (SAST), you are evaluating apps from the inside out to identify flaws and vulnerabilities in an app’s code that expose data. This includes 3rd party code.
Automated and manual mobile app security testing, a.k.a. dynamic application security testing (DAST), is necessary to assess apps as they execute on a physical device to detect vulnerabilities and risky behaviors during runtime. This includes assessing apps in a live network environment to monitor and find data transmission and network communication vulnerabilities.
Test code every time a build is pushed. Integrate mobile app security testing into the SDLC with automation. Once a build-test-deploy workflow is implemented, a security assessment I kickstarted every time a build is pushed. This allows developers to focus on coding while security teams can manage the identified security issues.
5. Using Weak Encryption (or Not Using Encryption at All)
Technology is constantly improving, and as a result, encryption algorithms become obsolete and easier to crack. Sensitive user information is at risk if you use weak encryption or decide not to use it at all in your app. Many apps require users to input sensitive data, such as credit card numbers or personal identification information. Without strong encryption, this information can be compromised. The more popular the app is then the more likely it is to be a target. Ensure that your implementation is up-to-date and configured properly. Other techniques can be used such as string encryption at the code level and a more advanced application of white box cryptography for protecting sensitive information both statically and at runtime.
6. Planning for App Reverse Engineering and Tampering
There is not much that app developers can do to prevent mobile devices from being stolen or lost, but implementing a local session timeout code does help. Basically, users must periodically enter a password to get into an app. Instead of happening daily, it could be something like entering a password once a week or every five times they use an app. Sometimes, mobile devices have software that remembers passwords, but the local session timeout prevents this.
Assume that a device will be lost, stolen, or have a malicious user at some point. Attackers often reverse engineer apps to gain valuable insight into how the app works. By increasing the runtime and code complexity it becomes more difficult for attackers to analyze and understand the application which may reduce their number of attack vectors and useful information. This includes security techniques like code obfuscation, control flow obfuscation, debug detection, and root/jailbreak detection.
Attackers are known to modify existing apps and insert malicious functionality before publishing these malicious apps to third-party sites and app stores. Apps can be tampered with or backdoored and then re-signed by an attacker. Code signing, resource verification, tamper detection, and integrity verification can mitigate tampering.
7. Not Implementing Secure Communication
Most apps that handle sensitive user information connect to a server. Therefore, you must make sure the transit is safe. You don't want anything intercepted on an insecure Wi-Fi connection. This type of security is mainly achieved through strong encryption protocols and ciphers, and TLS/SSL certificate pinning or Public Key Pinning. App keys and secrets along with other techniques also provide additional layers of protection. If you fail to use the proper SSL libraries, it can compromise user information.
8. Patching Your App Too Slowly
You're not done after you launch your app. Hackers work fast. They look for apps that don't release security updates often and then exploit those security holes. You need to revisit the app often to perform security updates. However, patches can regularly take some time to reach users. For instance, Apple's approval process can take as long as a week. Plus, all mobile device users have to accept and download the patch. If you don't stay on top of new security updates, patches will not reach users in a timely manner, putting them at risk.
There’s no margin for error when apps deal with information like customer payment information and personal information. The repercussions of a security breach are catastrophic to the application stakeholders. Don’t get caught unaware and unprepared. Make the necessary precautions to protect your app and its users.
It’s critically important to consider all of the various techniques for securing an app through intelligent development decisions. For enterprises developing and deploying apps internally to their employees, there are additional tools to consider. An enterprise mobility management (EMM) solution provides protections typically not addressed through direct app development. These protections start with the basic and most important—detection and remediation if an iOS device is jailbroken or an Android device is rooted. If all the built-in security of the mobile operating system has been removed, no app specific protections are going to keep the data safe for long, as many controls build upon the inherent mobile OS security features.
Beyond jailbreak and root security, an EMM solution can provide enterprise authentication requirements before launching an app and the ability to apply various security policies to prevent a data breach. For example, the app and the device may be secure, but what about the data transmissions? Can those apps communicate only over a secure channel such as VPN? These and many other vulnerabilities can be addressed by the inclusion of an EMM solution in the enterprise.
The combination of development strategies combined with EMM is the most comprehensive way to ensure that devices, apps, and the critical data they contain stay safe in an unsafe digital world.
Published at DZone with permission of Aaron Bryson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.