With the market of mobile application development (the famous “mobile apps”) growing considerably, attacks on mobile applications have also started to receive more attention, as already explained in our article on the mobile security scenario in 2020.
As a result, many developers and security experts are increasingly looking to learn about security within mobile applications. However, they sometimes encounter difficulties, mainly related to the peculiarities of the mobile application universe.
The aim of this article is precisely to present these peculiarities by comparing security for web applications and security for mobile applications.
The code is already on the device
Possibly the biggest difference between web and mobile application security is that while in web applications only a small part is accessible to the user (the front-end code), in mobile applications, no matter how much of the business logic is in a back-end API, the application code is stored inside the device.
Therefore, anyone who downloads the application onto their mobile device is able to inspect their code as long as they have the appropriate knowledge and tools.
Therefore, you need to keep in mind that possible threatening agents will inevitably take advantage of this, since being able to inspect the code makes it much easier to understand how a particular system works.
Once this is clear to the development team, even more attention should be paid to what information will be stored on the device. After all, once again, your entire content will be on the mobile device, including any data that you choose to record into local storage. You should always think twice before you want to store any information locally, to avoid possible vulnerabilities such as item 2 of the OWASP list of top 10 vulnerabilities in mobile applications: Insecure Data Storage, or insecure data storage.
There is also the possibility of a threat agent changing the mobile application’s own code, for example using tools such as FRIDA or Apktool to provoke the most diverse behaviors within the application – possibly affecting the API in the back-end even.
Comparing Security Requirements (MASVS vs ASVS)
In another article, it was clarified in great detail what OWASP – Application Security Verification Standard (ASVS) is about and how it can be used as a basis for selecting the security requirements of an application.
But to refresh the memory, ASVS classifies the degree of risk of an application into 3 levels and according to the level, more requirements or less requirements will be needed. The detail is that the ASVS levels are all cumulative. That is: if an application is classified as level 2 risk level, it is understood that for it all requirements of level 1 are recommended as well. Similarly, in an application classified as level 3, the security controls of levels 3, 2 and 1 must be applied.
In the mobile version of this standard built by OWASP, this is not exactly how it works. In a way, there is also a classification in 3 levels, but it is not as simple as 1, 2 and 3. In MASVS, the risk rating is distributed in levels 1 and 2, with or without Resilience against reverse engineering. That is, between levels 1 and 2 of MASVS, the risk assessment and the selection of requirements takes place in a very similar way to ASVS. However, when there is an interest in protecting the application code itself, the requirements of MASVS category 8, which are the unique requirements for resiliency, should be implemented.
In other words, linking the security requirements with the fact that the application code is stored on the device itself, whenever there is an interest in protecting the code against possible tampering attacks, reverse engineering, or as a form of protection of the intellectual property of the application, the “R” level controls of the MASVS should be implemented.
According to MASVS:
“The app has state-of-the-art security, and is also resilient against specific, clearly defined client-side attacks, such as tampering, modding, or reverse engineering to extract sensitive code or data.”
Thus, taking MASVS as a basis, in the mobile application scenario the risk classification can be given by the degree of risk, taken from the characteristics of the application, plus the interest in protecting your own code, resilience requirements. In the case of MASVS, therefore, one can have 4 possibilities of level of security requirements to be worked:
- MASVS-L1
- MASVS-L1+R
- MASVS-L2
- MASVS-L2+R
Some of the resilience controls that should be observed involve the practice of code obfuscation (the process of modifying an executable so that it is no longer useful to a hacker but remains fully functional), detection and response to adulteration of executable files, and detection of “root” and “jailbreak” (which will be explained later).
Sandbox
Furthermore, taking into account the fact that in the mobile application scenario the application is stored and running inside the device itself, it is necessary to understand that each application inside a mobile device works inside its own sandbox, i.e. inside its own isolation and does not have access to resources from outside, unless explicitly allowed by another app. Or at least that’s how it should be.
That is precisely where the danger lies. There are some ways to break this isolation box, allowing a threat agent, in this case it could be a malicious person or even malware contained in the device, to perform actions within the application space, including manipulating events and stealing data, for example.
The breakage of this sandbox can happen if the device is Rooted or Jailbroken. That is, the owner of the device has tampered with the operating system permission conditions of the device in order to have unrestricted access to any such boxes contained in the device.
To prevent this from happening, it is highly recommended that some form of root or jailbreak detection be implemented in your application, so that it is automatically closed as soon as this type of behavior is detected, as recommended by MASVS requirement 8.1 of Resilience.
Another scenario where this isolation is broken is when the development team itself, intentionally or unintentionally, leaves some “door” open to some feature within your application. This will be best addressed in the following item.
Key configurations
When thinking about configurations in the web application scenario, configurations related mainly to the technologies used (cloud, frameworks, databases, etc.) are usually taken into account.
In mobile applications, it is necessary to understand that all entry points, services that run in the background, receivers, communication points between applications, among other items, have their configurations. And they must be carefully analyzed.
To facilitate the understanding of the necessary care, we will analyze the following fact. In order for an application to be able to use the device’s features such as camera, touchID, microphone, among others, it must temporarily “open a door out of its isolation box”. This is often not the problem, since the main operating systems of mobile devices today already have a number ofeguards to prevent attack scenarios when these features are requested.
The danger is when some of these sandbox ports are left open so that any other applications on the device can access these exposed features, such as possible malware that is present on the same device.
More specifically, in the case of Android, special attention should be given to the AndroidManifest.xml file, present in any application built for Android. Inside it are all the settings of these “ports”, which are often kept open by default, especially when the application is built using non-native languages. In IOS, possibly the closest item is info.plist.
Comparing equipment
Another analysis that can’t be left out is in relation to the characteristics of mobile devices related to computers.
In addition to issues such as average size, or the very fact that the mobile device can be easily manipulated anywhere, in the vast majority of cases mobile devices collect and store much more user information than computers do, such as location, images, videos, audios, etc. And a special highlight is registration information, which is often also stored inside the device.
If we remember that most attacks on applications (both web and mobile) aim at data theft, as mentioned in our article on the mobile security scenario in 2020, this feature becomes even more striking.
Another point to consider is that mobile devices are much more easily stolen. According to research conducted by CanalTech (portuguese content), about 63 smartphones are stolen per hour in major capitals. Of course many thieves just want to sell the devices and thus make a profit, but many exploit the device and take advantage of it to steal various information, such as access credentials to bank accounts, e-mails, social media, etc.
Since these differences are clear to those who develop the application security, it should be noted that data protection should consider these peculiarities of the mobile scenario.
Data protection
With regard to data protection recommendations, the same recommendations regarding the use of encryption techniques apply to both the web and mobile scenarios, but some recommendations become even more relevant in the mobile device scenario, such as storing data securely, which in the case of mobile applications must be taken into consideration if this data can be accessed by someone who has stolen the device or by malware contained in it.
This involves an analysis of what data actually needs to be stored on the device, what settings need to be made in the application code, with whom this data will be shared (inside and outside the device itself), among other points of attention.
Another point of attention is with regard to communication between the front and backend. In both cases, web and mobile, communication certificates should always be properly used to ensure that this data cannot be intercepted during transmission. But it is worth remembering that in the case of mobile devices, nowadays it is much easier for an unsuspecting person to connect to an insecure wi-fi network, for example, allowing a malicious agent, using proxy tools, to easily intercept packets, the famous man-in-the-middle (MitM) attacks.
Therefore, in mobile application scenarios, this care with communication becomes even more relevant, being highly recommended for the deployment of SSLPinning and Mutual TLS.
Comparing the secure development pipeline
In other articles in our blog, we have already clarified what the Secure Development Process should be like, but is it worth an understanding of what will change in my secure development process now with mobile development?
And the answer is nothing. The Secure Development Process will be the same whether it is a web application, mobile or API. That is, the same activities must still be performed, including design reviews, threat modeling, code review and static and dynamic analysis tools.
What will change are the tools that will be used, since a SAST tool for a web application developed in Java will not necessarily work correctly for an application developed for Android, for example.
But here is a brief quote of what tools will change in a secure mobile application development process compared to a web application.
As mentioned earlier, risk assessment will change as the characteristics of mobile applications are different from web applications. Using the same risk assessment method for both can make a certain scenario that is critical in a web application perhaps not so alarming in a mobile application and vice versa.
In addition, security requirements will be different. ASVS or other lists of security requirements should be exchanged for lists intended for the mobile application scenario, which contain specific requirements of the main mobile platforms and requirements of resilience against reverse engineering, such as MASVS for example.
As for the design steps, architecture review and threat modeling, little will change in the activities themselves. But it is worth mentioning that, for a mobile application threat modeling, it is especially interesting that both the members of the application development team and those working on the API development participate, in order to make it easier and more assertive to identify threat scenarios involving the relationship between these two components.
In the encoding and testing steps, what will change are the tools that will be used. Note that both static and dynamic tests must still be performed in the mobile scenario. However, the testing tools for the mobile scenario tend to vary a lot in the way they work.
The term MAST, or Mobile Application Security Testing, has been seen in the market. In other words, automated security analysis tools that work specifically in the mobile scenario. Many vendors in the market of application security tools have started to use this expression. However, some tools called “MAST” act closer to a static analysis (SAST), while others act closer than a dynamic analysis (DAST). Therefore, care should be taken when selecting the tool.
As we have already explained in our article on security testing applying it to the pipeline, it is ideal to perform both static and dynamic analyses, so if you select a MAST tool that acts as a SAST, try to integrate another resource, automated or not, to perform dynamic analysis and thus contemplate both types of test.
CONTACT US ABOUT OUR SERVICES
Final considerations
When it comes to the process of secure software development, little will change between web and mobile application development. What will differentiate the most will be the tools used for one and the other.
As for the security mentality, in the case of mobile developers, one must keep in mind that first big difference: the code of your application will be contained in your own device. With this in mind when developing an application for mobile devices, some practices are already becoming more relevant.
In addition, mobile devices tend to collect a lot of data and usually have a lot of features, plus the fact that they can be more easily stolen or can contain malware that will try to perform actions within your applications. Therefore, all these points should be taken into consideration when analyzing mobile application security.
Article by: Nicolas Schmaltz
