Mobile application development has been on the rise lately because of the convenience mobile apps have to offer. Despite the occurrence of security breaches performed on mobile devices recently, security testing is not as emphasized as other forms of quality testing measures such as user acceptance or functional testing. Just last year, hackers in China managed to create a malicious version of Xcode, XcodeGhost, which was made available for public use. Many unsuspecting developers downloaded XcodeGhost from untrusted servers because it was faster than downloading from Apple. About 50 mobile applications that were built using this program were accepted by the official App store. Hackers chose this approach because they knew it would be easier than trying to get a malicious application approved by Apple. By tricking developers into using their version of the software, they took advantage of legitimate applications to sneak in malware.
An application can consist of the greatest features but will be considered unusable if hackers can exploit it. The exponential rise in the use of mobile applications for different purposes puts the mobile devices in significant danger of being hacked or compromised. In today’s world, mobile applications are used for various purposes and store Personally Identifiable Information (PII) and financial information. Due to the sensitivity of the customer data, mobile applications should be built and tested with security in mind.
Using source code from other developers can be great rather than starting from scratch. However, the developer should be sure that the code that is being incorporated into the codebase is fully secure. Before adding such code, a developer should be sure to address the following questions. Does this library or SDK contain any security vulnerabilities? Has the code been thoroughly tested in real-world settings? Have problems been reported from other developers? Third-party libraries can save time, but developers should make sure that they stay accountable for their app. Some hackers are known to write code in the hope that the malicious code gets picked up and used in apps. The hacker’s code can leave a backdoor open, meaning they can gain unauthorized access to your site and the admin capabilities without having to authenticate through the front-end login page. The hacker’s intention behind this is to gain access to the application following its release. In order to ensure that only good code is being incorporated into the codebase, it’s important to look out for SDKs and code hosted on untrusted servers. SDKs and code should only be retrieved from credible sources. If you plan to use code from a third-party library, make sure it is not going to lead to any security vulnerabilities. Products such as the Nexus IQ server by Sonatype, which has the ability to scan libraries being used in the codebase for vulnerabilities, could be of help.
Improper session handling is another major security concern for mobile application developers and users. Recall a time when you were in the middle of checking your account details online, and you had to step away. You return to your computer to see a message like, “Session Timed Out – Please Log in Again.” This is a good practice in regards to session handling. If a user is away for a predetermined amount of time, the system should log them out to protect them from threats like someone sitting down at the user’s computer and seeing the user’s account information. Unfortunately, many consumer and enterprise applications ignore this practice.
Consumer applications are often designed to provide users with fast access to purchasing and checkout so that sales can be performed quickly. On the enterprise side, mobile application developers are concerned with pleasing users by speeding up the application and making it simpler to use. If a mobile device gets stolen while a user is logged into a mobile application without the proper security measures, all of the app data can potentially be exposed as data can be accessed by anyone who takes possession of the device. To properly deal with this common security vulnerability, mobile app developers should end sessions in a timely manner and require users to re-authenticate for privileged functions.
Due to the constant improvement of technology, encryption schemes become outdated and easier to crack over time. If weak encryption or no encryption is being utilized, sensitive user information is at the risk of being compromised. The more popular the mobile application, the bigger the target it is for hackers. Therefore, all good mobile developers should invest in an industry standard encryption algorithm such as SHA-256. Transit encryption should be used anytime a mobile app transmits sensitive pieces of data such as usernames, passwords, API keys, or other critical data. Mobile devices are often connected to unsecured Wi-Fi access points in public areas which make it easy for troublemakers to snoop and intercept connections. The time invested in incorporating a strong encryption algorithm will give the developers the assurance that the data is transmitted safely.
Just like data during transmission, data at rest needs to be secured as well. Data is considered at rest when it is stored on the hard drive of the local device. Mobile applications should minimize storing critical pieces of data such as credit card numbers and passwords on the local device as much as possible. However, there are cases where storing data locally is absolutely necessary for the application to function. The chances of sensitive data stored locally being compromised can be significantly lowered if such data is stored in the appropriate storage locations. Android apps should store data in shared preferences and iOS apps should take full advantage of the iOS keychain as these storage options are considered safe. However, developers should develop under the assumption that there isn’t a secure location to store data locally because operating systems can have bugs. Using the iOS and Android encryption libraries are encouraged whenever sensitive pieces of data need to be stored locally.
A mobile application should not be rushed to release until it is thoroughly tested to ensure that it is secure. A comprehensive mobile application security testing strategy should be in place; otherwise, your mobile application can be at risk. The first step to secure a mobile app is to identify the environment in which it will operate. Figure out what platform your application will be available on, then understand the potential threats. For instance, the attack vectors for iOS and Android are different. Next, a checklist for the most common and riskiest vulnerabilities should be created. To help find these, visit Open Web Application Security Project (OWASP) Top 10 for Mobile Apps. Ultimately, the weaknesses identified in the previous step should be addressed with a range of security tools. Static code analysis should be used throughout the SDLC, a dynamic analysis tool should be used to investigate how the application performs during runtime, and penetration testing should be performed before release. Each of these tools has a place in a comprehensive mobile application security testing plan to help identify nearly all vulnerabilities.
