Mobile apps such as social networking, banking, and entertainment apps contain a lot of functionality that requires Internet communication, and so most of the mobile apps today have typical client-server architecture as shown in the diagram below. When understanding the attack surface for these kinds of apps, it is required to consider all the possibilities of the application, which includes the client application, API backend, server related vulnerabilities, and the database. An entry point at any of these places may cause a threat to the whole application/its data. For illustration, assume that we have an Android app connecting to its server using the backend API, which in turn interacts with its database:
It is recommended to follow the Secure SDLC process while developing software. Many organizations embrace this method of SDLC to implement security at each phase of the software development life cycle process.
Secure Software Development Life Cycle (SDLC) is a methodology to help organizations build security into their products right from the beginning of the SDLC process and not as an afterthought. Embracing SDLC increases the profits by reducing the efforts involved in fixing issues during maintenance cycles.
As we can see in the following diagram taken from the Microsoft SDL process document, each stage of SDLC involves at least one security activity which will help in securing the application. Every organization is different in embedding security in SDLC and their maturity differs, however, the following could be a good start for organizations who are thinking of embracing this methodology:
• Threat Modeling: Identify the threats to your applications by defining the assets, value it provides, and perspective threat actors who might be interested to attack the assets. Threat modeling ideally needs to be done during the Design phase of the application.
• Static Analysis: During the Implementation phase, it's recommended to do static analysis on the source code at least once per release cycle. This gives stakeholders an overview of the risks and they can either accept the risks or they can ask dev teams to fix issues before the application goes to production.
• Dynamic Analysis: Dynamic analysis is done during the Verification phase of the SDLC process. Dynamic analysis is a technique to find issues while the application is running. It can help organizations in knowing the security posture of their applications before deployment. We will cover more of what Dynamic analysis entails and how it can be done in the next few chapters.
Let's explore some common threats to mobile apps that have to be addressed during the design phase of a mobile app. The assumption is that the attacker can get physical access to the device as well as the app binary.
[ 111 ]
Threats at the client side
• Application data at rest: With the introduction of mobile applications, the concept of storing data at the client side has been drastically adopted. Many mobile applications store sensitive data on the device without any encryption. This is one of the major problems of mobile applications. This data can be sensitive, confidential, and private. Data that rests on the device can be exploited in many different ways. An attacker who has got physical access to the device can gain access to this data almost without doing anything. A malicious application may gain access to this data if the device is rooted/jailbroken. It is important to make sure that apps do not store sensitive data such as usernames, passwords, authentication tokens, credit card numbers, and so on, on the device. If it cannot be avoided, it is required to encrypt it and keep it away from an attacker's control. We will explore more details about insecure data storage vulnerabilities in Chapter 5, Data Storage and Its Security.
• Application data in transit: Mobile applications that communicate with the backend are highly exposed to attacks that target the data in transit. It is quite common for end users to join publicly available networks at coffee shops and airports where an attacker may sit in and eavesdrop on the data using tools like burp proxy, MITM proxy, SSL MitM (short for Man in the
Middle attack) proxy, and so on. With the introduction of smart phone
apps, exploitability of such attacks became very easy as mobiles follow us wherever we go.
• Vulnerabilities in code: Mobile applications when developed with no security controls in mind can become vulnerable to various attacks. These coding mistakes in the app can lead to a serious vulnerability in the app, which in turn impacts the user/app data. Examples of such mistakes include, exported content providers, exported activities, client side injection, and so on. Attack scenarios include, an attacker who has physical access to the device may gain access to another user's session. A malicious app sitting on the same device can read the content of the other apps when they expose data due to coding mistakes. An attacker who has access to the binary may decompile the application and view the hardcoded credentials in the source code.
• Data leaks in the app: This is another issue in mobile applications in almost all the platforms. It is possible that an app may unintentionally leak sensitive data to an attacker. This requires extra attention from the developer. The code he uses for logging during the development phase must be removed and he must make sure that no data is prone to leaks. The main reason behind focusing on this is that application sandboxing will not be applicable to some of the attacks in this class. If a user copies some sensitive data such as a security answer from an application, this will be placed on the device clipboard, which is out of the application sandbox. Any other app sitting on the same device can read this data copied without the knowledge of the first app.
• Platform specific issues: When designing a threat model for mobile applications, it is important to consider the threats associated with the platform that this app is going to run on. Let us consider an example with Android, native apps that are developed for the android platform can be easily reverse engineered and the Java source code can be easily viewed. It allows an attacker to view the source code as well as any sensitive data that is hard coded in the code. It is also possible to modify the code in the application and re-compile it and then distribute the apps in third party markets.
Performing integrity checks is something that has to be considered if the app is sensitive in nature or if it is a paid app. Though the above-mentioned issues are relatively less effective in a platform like iOS, it has got its own platform specific issues if the device is jail-broken.