June 30th 2020
By Aid Hodžič, Quality Assurance Engineer at Klika
What are the responsibilities of a QA? Is it testing the application and the APIs using those already defined test cases? Or is it chasing and finding bugs based on acceptance criteria? Description of a QA engineer job will look like this if we do not understand QA's job in the development of the application. QA is important from the beginning of the development process to the very end. In addition to “just” finding bugs, there is also automation of test cases, suggestions for improvement of user interface and user experience and a lot of other useful things.
However, could a QA be even more useful during the development process? What if a QA would test the security of the mobile application? At the very beginning of my QA career I thought that my job description is to test application and find as many bugs as possible to improve application quality, user experience etc. After gaining experience, learning and research, I realized that QA could contribute to the security of the application like all other team members. Below we will go through what is mobile security from the aspect of QA and how it can be improved with its help.
What is mobile application security in general?
Mobile application security involves examining the structure of mobile applications and studying how they work, as well as looking at major threat areas and what hackers or other attackers want to accomplish. Security experts develop assessments based on issues like theft of financial data or personal identifiers, or unauthorized access to devices. Areas covered by mobile application security include threat modeling, source code review and risk analysis. Developers may look at areas like a database, cache or configuration files, or at the underlying platform to understand how to better protect mobile applications and devices from vulnerabilities.
This is the definition of mobile application security, but what is mobile security for QA, developer or end user? In a security sense the main task of developers and QA is to prevent unwanted actions and consequences for the user. When we pay attention to security of the applications, we avoid problems such as theft of user data, credentials, disabling the application and at the end big financial losses for us or the client. From this we conclude that security is the responsibility of both the developer and QA, and finally the user who, if he notices vulnerability, should report an error in order to improve security for each user.
For the security of the application it is very important that security tests are properly and thoroughly tested. We already know that we have white-box, grey-box and black-box testing. In this case these three terms are used to test the security of the application if we know the source code or not (or if we can examine parts of the source code from the .apk or .ipa file). In addition to this, we distinguish between two types of testing (the same depending on whether we have an application code) and that is dynamic and static testing of the application.
The main objective of dynamic analysis is finding security vulnerabilities or weak spots in a program while it is running. Dynamic analysis is conducted both at the mobile platform layer and against the back-end services and APIs, where the mobile app's request and response patterns can be analyzed.
Dynamic analysis is usually used to check for security mechanisms that provide sufficient protection against the most prevalent types of attack, such as disclosure of data in transit, authentication and authorization issues, and server configuration errors.
For this type of testing QA can be helpful. In many situations a QA tests these parts of the application but not for the security reasons but to check if it works like defined or not. If QA adds checks for security, testing will be longer or maybe more difficult but at the end, we will have secure application ready for use.
During static analysis, the mobile app's source code is reviewed to ensure appropriate implementation of security controls. In most cases, a hybrid automatic/manual approach is used. Automatic scans catch the low-hanging fruit, and the human tester can explore the code base with specific usage contexts in mind.
For static testing help of the QA may not be helpful and these tasks are for the developer but in some cases QA's help is not negligible.
Also, there are tools (SAST- Static application security testing; DAST-Dynamic application security testing) that are used for security testing. However, testing should always be performed in another way to avoid false positive or false negative results. These tools check only for already defined vulnerabilities and can miss for some serious security vulnerabilities.
When security testing the application, it is important to follow the steps that will facilitate further work:
As we stated above a QA can take on any task she or he wants, but we have to be careful to take on only those that suit us. Mostly a QA can be helpful in every phase depending on its skills. It can be preparation phase, mapping the application or reporting phase. Who writes better reports than QA?
Everyone's goal is to make their data as secure as possible when using one of the applications. Also, the teams that develop applications do not want a security failure to occur and lead to a disaster. Can this be prevented? Yes, in a large number of cases. There are two ways. One is security and penetration testing of the application after development process and the second is to monitor application security and to fix vulnerabilities during each step of development lifecycle.
How QA can contribute to security of the mobile application? We will focus primarily on security implementation during development. We already went through security testing of the finished application. Also, when we have security tested application by the third side QA can only check if vulnerabilities are fixed.
Let's base ourselves on the implementation of security during application development. The role of QA should be in addition to testing the functionality of the application to pay attention to its security. This is a new skill that he needs to learn however with the help of the guideline available it should not be a problem. Also, most things QA already knows it just has to look at it at the testing of the application. In this way, vulnerabilities are addressed before they appear in production. Also, the role of the QA may be to implement security requirements when defining tasks. These things should be defined even before the QA intervention, but it can contribute that way.
In order to better understand how to pay attention to the security of the application during development, we need to pay attention to the following steps:
Perform a risk assessment for the application and its components to identify their risk profiles. These risk profiles typically depend on the organization's risk appetite and applicable regulatory requirements. The risk assessment is also based on factors, including whether the application is accessible via the Internet and the kind of data the application processes and stores. All kinds of risks must be taken into account: financial, marketing, industrial, etc. Data classification policies specify which data is sensitive and how it must be secured.
This could be perfect fit for QA because she or he always takes into account all possibilities.
Security Requirements are determined at the beginning of a project or development cycle, when functional requirements are being gathered. Abuse Cases are added as use cases are created. Teams (including development teams) may be given security training (such as Secure Coding) if they need it. You can use the OWASP MASVS to determine the security requirements of mobile applications on the basis of the risk assessment phase. Iteratively reviewing requirements when features and data classes are added is common, especially with Agile projects.
Threat Modeling, which is basically the identification, enumeration, prioritization, and initial handling of threats, is a foundational artifact that must be performed as architecture development and design progress. Security Architecture, a Threat Model factor, can be refined (for both software and hardware aspects) after the Threat Modeling phase. Secure Coding rules are established and the list of Security tools that will be used is created. The strategy for Security testing is clarified.
All security requirements and design considerations should be stored in the Application Life Cycle Management (ALM) system (also known as the issue tracker) that the development/ops team uses to ensure tight integration of security requirements into the development workflow. The security requirements should contain relevant source code snippets so that developers can quickly reference the snippets. Creating a dedicated repository that's under version control and contains only these code snippets is a secure coding strategy that's more beneficial than the traditional approach (storing the guidelines in word documents or PDFs).
Securely develop the software. To increase code security, you must complete activities such as Security Code Reviews, Static Application Security Testing, and Security Unit Testing. Although quality analogues of these security activities exist, the same logic must be applied to security, e.g., reviewing, analyzing, and testing code for security defects (for example, missing input validation, failing to free all resources, etc.).
Next comes the long-awaited release candidate testing: both manual and automated Penetration Testing ("Pentests"). Dynamic Application Security Testing is usually performed during this phase as well. On this step QA help can be useful too.
After the software has been Accredited during Acceptance by all stakeholders, it can be safely transitioned to Operation teams and put in Production.
The last phase, too often neglected, is the safe Decommissioning of software after its end of use.
Here, QA can contribute to risk assessment, risk profile definition and defining user sensitive data. It can also contribute to the application requirements to ensure that they follow the best security recommendations, that operating systems are well defined (e.g. if we use iOS or Android version which has well known vulnerability QA can ensure that that vulnerability is well known to every team member), and during threat modeling. In QA development itself, there is no impact on developers, but when tested, it's impact is great. The best thing for applications security is to follow the OWASP guideline for security when developing or testing the application.
The risks of unsafe application are enormous. We have described how security applications can be tested, but also how security can be considered in parallel with development. Either way, it’s important to check the security of the app and fix things that are not secure. We all play an important role in this from the client to the developer and QA. The task of QA can be to learn to test security and not to neglect it during development or during application testing. Some things that seem unimportant can affect the security of the application (e.g. disable screenshots while using the application). Also, a recommendation for developers is to take a look and try to adhere to the security guidelines for development.
Security can always be improved and we can always work on it. No one is safe!