Web Application Penetration Testing Checklist 

Most of the web applications are public-facing websites of businesses, and they are a lucrative target for attackers. Hence, it becomes imperative for companies to ensure that their web applications are adequately protected and are not prone to cyber-attacks. Our penetration testing experts have compiled a checklist to be utilized while performing a penetration test for web applications. We will look at this checklist’s items one by one.

Contact form

Contact forms available on a web application act as entry points for spammers. If adequate security mechanisms are not implemented, there are chances that the associated email account is flooded with spamming emails. Hence, the contact form should be able to identify and prevent such attacks. CAPTCHA is one such way to prevent spamming.

Proxy server

Proxy servers play a significant role in directing traffic to your web application and filtering out malicious activities. The penetration testers must check whether the proxy servers within an organization’s network are functioning as desired. Tools like OWASP ZAP and Burp can help the penetration testing team.

Spam Email Filter

Spam filters must be enabled to ensure that email policies are being enforced as expected. The penetration testers verify whether the spam filter.

Network Firewall

Just like proxy servers, network firewalls prevent undesirable traffic from entering your web application. The penetration testers not only check the efficiency of a network firewall but also explore the possibilities of bypassing the firewalls.

Security Vulnerabilities

The penetration testers here simulate various modus operandi used by the attackers to simulate a real-life attack. Vulnerabilities can exist in network devices, servers, databases, web applications, etc.

Credential Encryption

The penetration testers look out for the possibilities of conducting a man-in-the-middle attack. An organization must encrypt login credentials, and they should be only transferred over a secure HTTPS connection. When a web application is to be secured, encryption plays a vital role. 

Cookies

Cookies store data related to a user’s session on your web application. This is a sensitive piece of information, and with increasing privacy and protection laws across the globe, it is not a favorable position for a business to allow this confidential information to get exposed to attackers. 

Login Page

The penetration testers test a web application’s login page from multiple angles. One such angle is to ensure that only a limited number of login attempts are made for a corresponding user. This ensures that dictionary attacks are prevented.

Error Message

Error messages on your web application should not reveal more than required information about the problem. The error messages shown must be generic in nature. A detailed error message is similar to inviting the attackers to attack your web application.

Usernames & Passwords

The penetration testers test all the usernames and passwords which are used on your web application. A password must be fairly complex, and the username must not be easily guessable.

File Scanning

Before files are uploaded either to your web application or server, they must be scanned to ensure that they do not contain harmful content.

SQL Injection

This is one of the most common methods used by attackers while exploiting web applications. The penetration testers perform SQL injection attacks on all the components of your web application.

XSS

Just like SQL injection, cross-site scripting, or XSS, is another common method employed by attackers to launch attacks on an organization’s web application. The penetration testers check whether security mechanisms implemented to prevent an XSS attack are working correctly or not.

Session Hijacking

Once a user logs out of your web application, his user session must be terminated. Moreover, a user must be allocated the minimum user access privilege possible – nothing less, nothing more. Valid sessions may be hijacked by the attackers, which allows them to view all the information that a user is allowed to.

Brute Force

The penetration testers analyze whether your web application is safe against brute force attacks or not. A brute force attack is a trial and error method that is used by the attackers to break through your encryption method or find the correct credentials to your web application. 

DoS Attack

By launching DoS attacks on your web application, the attackers send a large number of requests to your web application. A DoS attack not only prevents genuine users from accessing your web application but also leads to downtime. However, using appropriate mitigation tools can significantly minimize the threat.

Directory Traversal

An organization must disable directory traversal on the server where a web application is hosted. If directory traversal is not prevented, the attackers get easy access to your organization’s confidential information.

Open Ports

Unnecessarily open ports on your web application act as an invite for the attackers to exploit your web application. Only posts which are required for your web application to perform must be kept open.

HTTP Method

The penetration testers review the HTTP methods used by your web application. As a mandatory step, PUT and DELETE methods shall not be enabled.

Access Permissions

An audit of access permissions given to various users for your web application must be conducted. As stated, a user should only be given the minimum access level privilege possible.

Information Gathering

There’s an old saying that holds value in this scenario regarding Web Application Penetration Testing – “Begin with the End in Mind.” One of the biggest components of ensuring that your organization gets the most value out of a Web Application Penetration Test is proper planning, which cannot be overlooked. Once you can articulate what exactly it is that you are looking to gain from a Web Application Penetration Test, it is easier to develop an action plan that caters to your organization’s objectives. Businesses often call this approach an ‘Outcome-Based Approach.’

Whatever your organization’s reason is for planning a Web Application Penetration Testing, following this checklist of questions that need to be answered before you start can help relieve some of the intricacies involved in the process. 

What is your organization’s objective of getting a PenTest done?

a. Gain customer’s trust by demonstrating proactiveness in security measures with an assessment of the current security posture
b. Regulatory or industry-level compliance/standards
c. Security Posture Assessment/Management
d. Attack Surface Management
e. DevSecOps 

What Is the Scope?

a. What environment should you be conducting the PenTest in, staging or production?
b. Do you need BlackBox or GreyBox or Whitebox testing? 

What is the best tool or vendor for the job?

a. Traditional consultant-based approach
b. Automated Testing approach
c. Modern Penetration Testing approach that uses A.I. and Human PenTesters both 

What is the best time to schedule your Penetration Test?

a. How often should I be conducting Penetration Testing?
b. What are the triggers for a PenTesting activity? 

What is your plan for remediation?

a. What is the guideline around the time you will take to fix a High, Medium or a Low vulnerability?
b. What is the process to deploy and test your patch for each vulnerability? 

What is your organization’s reason for getting a Web Application PenTest?

There are cases in which businesses are simply considering Web Application Penetration Testing as a proactive security posture procedure and there are cases when it’s required for compliances, vendor assessments, and client requests. Some of these compliances include:

• PCI DSS 
• HIPAA 
• SOC2 
• NYDFS 500 
• ISO 27001 
• CCPA 
• GDPR 

Having an in-depth understanding of what is required by a vendor or client out of a PenTest will set you on the right path to move deeper into the planning phase.  

What is the scope of the Web Application PenTest?

When planning to begin a PenTest on your organization’s Web Application, providing your selected vendor with the scope of what needs to be tested is especially important. The Rules of Engagement should also be agreed upon at the beginning. Businesses often struggle with identifying the scope of PenTests, as there are multiple variables involved. However, the scope of the engagement should be derived from the objective of the PenTest, reaffirming the idea of the ‘Outcome-Based Approach.’ For example, for PCI DSS compliance testing, all the applications and systems coming in the Card DataHolder Environment (CDE) should be included and it should also include a plan to test the isolation of CDE to non-CDE environment. 

Another example: if you have made significant changes to an application, it’s best that the organization test the recent changes/additions to see if the changes made caused any vulnerabilities to arise. 

There is also the decision between a White Box, Grey Box, or Black Box Penetration Test to consider. It is extremely important that your vendor has the correct information to ensure that the results of the PenTest live up to its requirements and objective. For example, if an organization requesting a blackbox test for a web application that only has a Form-Login page, and the entire application and interfaces are behind the login, the BlackBox PenTest results will not be helpful.
 

It is equally important to understand the environment in which you want the Web Application to be tested. Most organizations, due to fear of a disruption in business, get the staging environment of the application PenTested.
 

What is the best tool or vendor for the job?

The key to finding the right tool or vendor should also stem from the objective of testing. Organizations often use a traditional Penetration Testing approach for compliance-based testing and rely on consultant-based model entirely. The traditional model has proven to be effective in the past, but it is not scalable in the current digital era.
 

Similarly, organizations looking at assessing the current security posture take a tool-based approach which gives them scalability and comprehensiveness, but it often misses the business context and testing of business controls. 

Additionally, credibility of the vendor is an especially important factor that determines the admissibility of the reports by auditors.
 

For example, organizations in Financial Services and Healthcare Technology require their PenTesting vendors to be ISO 27001 certified due to the rigorous nature of the certification process.
 

ISO 27001 requires vendors to go through a meticulous 6–12-month process to earn their certifications. An ISO 27001 Global Report done by IT Governance found from a survey of vendors in over 53 countries that 71% of them reported receiving requests from clients for proof of ISO 27001 certification, proving that ISO 27001 is a widely recognized industry standard across the globe. Additionally, industry recognitions, certifications, and compliances such as CREST and SOC II are equally important.
 

Some other considerations to make when choosing the right Penetration Testing vendor are whether or not they employ in-house or outsource/crowdsource their Penetration Testers, what kind of tools they use internally, and whether or not they use third-party services to share details about PenTest results. Having a third party in the mix for reporting purposes can pose an entirely new set of privacy risks, especially before remediation efforts have been completed. Any of these concerns can easily be put to rest by doing your due diligence to source the best partner for the job.
 

When is the best time to schedule a PenTest for your Web Application?

In any organization, there are always going to be peak business hours that drive traffic on its Web Application. It goes without saying that those peak business hours are not an ideal time of the day to plan a PenTest. The best way to work around this is to monitor trends in traffic over time to ensure that you can work with your Penetration Testing vendor to schedule the PenTest at the least disruptive time in case its activities had any temporary adverse effects on the performance of the application. When working with a skilled Penetration Tester, it’s unlikely that any issues would arise, but it is best to er on the side of caution.
 

Another thing to keep in mind when planning to schedule your PenTest is any major updates to your WebApp or any industry-wide announcements of a new vulnerability. Any changes to the code or structure of a Web Application could be a place for a new vulnerability to make way.
 

In order to receive the maximum value out of PenTest engagement and investment, organizations should take a periodic assessment approach with on-demand testing on an ad hoc basis. For example, the compliance may suggest getting a PenTest every quarter, but the organization should be cognizant of requesting an ad hoc PenTest if there are significant changes made to the system/application or if the threat landscape has changed significantly.  

What is your plan for remediation? 

Directly after receiving Web Application Penetration Test results, you’re going to want to get right to work with understanding the vulnerabilities detected, especially any critical, high, and medium ones. More often than not, vendors don’t offer a channel to speak with the PenTesters to get context and clarity on reported findings. However, it is a crucial step towards an effective remediation via prioritization.
 

 It’d serve your organization well to have a solid plan for remediation efforts as far as delegating remediation efforts to your developer team and having a timeline goes to prepare for a retest. Traditional models also don’t offer workflow integration to assign the findings to the concerned team and because of manual management of spreadsheets and word documents, quite a lot of valuable information falls between the cracks. Rest assured – there are vendors out there who are receptive to this pain-point in the Penetration Testing process and have implemented innovative ways around it.
 

Depending on the goal of the PenTest, it may be best to focus on specific types of vulnerabilities that are most closely related to specific functions or bits of information stored in the Web Application. Having the appropriate business context before remediation efforts begin can make a positive difference in your team’s ability to prioritize remediation efforts on exploitable vulnerabilities that have the greatest effect on your business.  Schedule a call to learn more about breachlock penetration testing as a service.