When we talk about software, we must also talk about security. But, who is ultimately in charge of security in an organization? The correct answer is everyone. Developers, testers, every person who works in software is responsible for applying security measures to ensure that the product is not going to be vulnerable to any attack. 

In this article, we are going to focus on security tasks that involve the practice of QA. Tasks that are executed by testers. In other words, we are going to talk about pen testing or penetration testing. 

What is Pen Testing?

Penetration testing is essentially a kind of hacking. It’s the practice of testing an application, network or system to find any security vulnerabilities that a potential attacker could exploit. As cyber attacks continue to rise, it is more important than ever conduct regular vulnerability scans and penetration testing

There are different types of pentesting: 

1. Network pen testing
2. Application pen testing
3. Web application pen testing
4. Infrastructure pen testing
5. Physical pen testing 

In this article, we will focus on web application pen testing.

How is pentesting executed? When is pentesting executed? Why is pentesting executed? First of all, it is important to know that as QA testers we need to consider that because our application is going to be exposed to an external public, performance and security are the two most important factors that we need to validate before delivering our production. We will talk about performance in another article.

Now, as testers what are the tasks that we need to cover to ensure the quality of our product? And what tools can we use? Let’s cover the following checklist.

1. First engagement
2. Information gathering
3. Automated pen testing
4. Manual pen testing
5. Reports
6. Remediation followup
7. Fix verification

First Engagement

Before starting with the execution of this kind of test, it’s important to specify in a document the conditions about how it will be executed. This documentation is to ensure that all the executions are permitted and to identify what is not permitted. The document must also specify the schedule of when the tests are going to be executed. This document must be authorized by the stakeholders.  

Information Gathering

Information about the application to be tested includes:

1. Hostnames of any backend
2. Main URL or entry point to the application
3. Version to be tested
4. Executables of the application
5. Types of user accounts and permissions
6. User accounts of each kind of the security team
7. Documentation about the usage or functions of the application

Automated Pen Testing

There are tools that we can leverage to execute this kind of test. The most recommended is the Burp suite, which the user must pay to use, and, OWASP, which is open source. Basically what this kind of tool does is scan the application and generate a report that we will use in the next phase: manual testing.

Manual Pen Testing

There’s not really a formula for this phase. Pentesters follow the OWASP testing guide but, these are some examples of this kind of tests:

1. Misconfigurations. Insecure default settings, insecure headers, etc.
2. Input validation
3. User management
4. Authentication
5. Authorization
6. Data confidentiality 
7. Integrity
8. Session management
9. Transport security
10. Legislative and standards compliance 

Reports

We always need to report our test results. If a vulnerability is found during the test execution, a bug report is necessary for visibility on how vulnerable the application is in that instance. The report must contain all the information necessary because this helps the developer reproduce the bug and fix it as soon as possible. With the reports, we can also extract some metrics that can be helpful to see the evolution of the quality of our product.

Remediation Follow-up

After our report has the detailed description and necessary information to be reproduced (data inputs, versions, execution steps, etc.) the developer can work on the proper fix to protect and make the application more secure for the end-users.

Fix Verification

After the fix is reviewed by two or more developers and is installed properly in the QA environment, our responsibility is to execute the proper regression tests to make sure that the vulnerability is gone and the application is more secure against any kind of attack. Also, we need to provide the proper resolution information into our report to document the root cause and analysis of the bug.

Thanks for reading and stay tuned for more lessons from the QA team.

Check out these other blogs by our QA team:

The Unsung Heroes of Software Development

Have You Heard About Shift Left?

How to Choose an Automation Framework