Introduction
Navigating the complex terrain of web penetration testing can be daunting. As an experienced penetration tester specialising in web application security, I can assure you that one of the most valuable steps you can take is a thorough and effective penetration test. If you’ve just invested in your first web penetration test, this guide will help you understand and make the most out of the process.
Planning for the Penetration Test
Define the Web Penetration Testing Goals
Before initiating a penetration test, having clearly defined goals is essential for focus and direction. Many businesses have been observed to falter due to the absence of clear objectives. Goals could range from meeting compliance requirements to protecting sensitive client data or safeguarding against specific threats. It is vital that the testers are aware of these objectives, as they often default to running standard checks against the target host. A mutual understanding of the goals between the tester and the company ensures that the penetration test is tailored to meet specific needs.
Identify the Penetration Testing Scope
Determining the scope is critical for effective management and targeting of the penetration test. By scope, one refers to the extent of the testing, which could include specific systems, departments, or types of data. While covering as much ground as possible may seem desirable, a more targeted test often yields more valuable and actionable results. Scopes can vary, from a simple login portal with limited functionality to a modern, sophisticated web app featuring multiple user roles, dozens of unique pages, and hundreds of parameters. Proper scoping generally requires the expertise of an experienced penetration tester or IT services sales agent who understands how to outline a web penetration test.
What environment should be tested?
The choice of testing environment will largely depend on what options are available. The vast majority of clients prefer—and are advised—to test on development or staging environments to avoid disrupting normal services. It is essential to take appropriate backups of any environment before initiating testing, as there is a known risk of services being temporarily brought down. This potential for disruption should be planned for from the beginning.
Should you tell your hosting provider about penetration testing?
The need to inform the hosting provider about the planned penetration test varies. Some providers, such as Google Cloud and many of Amazon’s services, permit testing without prior consent. Below is a list of common providers; one should consult the specific provider’s documentation for details. It is important to note that informing the hosting provider is generally the client’s responsibility, not that of the penetration testing company.
- Amazon Web Services (Mostly not required to submit a request)
- Digital Ocean (Raise a ticket):
- Google Cloud does not require authorisation:
- Heroku (Raise a ticket)
- Microsoft Azure (Not required since 2017, however, customers must comply with the Penetration Testing Rules of Engagement)
- Rackspace
How to choose a good Penetration Testing Team
The client’s choice of a penetration testing provider significantly influences the outcome of the test. It is crucial to ascertain that the chosen team, whether internal or outsourced, possesses the requisite qualifications, certifications, and experience. Employing an external team offers several advantages, including an unbiased perspective and the potential to uncover vulnerabilities that an internal team might miss. Things to look out for are:
- Experience Level of Testers: One should inquire whether the testers have an ample amount of prior experience needed to adequately assess the application. Experience with similar projects is often a good indicator.
- Specialisation in Web Application Security: Not all companies specialise in the specific area of web application security. It is important to select a company with the required expertise. For example, a company specialising in Internet of Things (IOT) security may not be the best fit for testing a complex enterprise web application.
- Methodology: Check if the tester are following a specific web penetration testing methodology (Such as OWASP)
- Certifications: Are the penetration testers properly qualified, with certifications such as CREST, OSCP and OSWE. A good list of qualifications to look out for is available here.
- Understanding of Scope: It is beneficial to hold a briefing with the selected testers to confirm their understanding of the scope they have been assigned. This ensures alignment and prevents potential disconnects between what was initially proposed by sales, what was communicated to the scheduling team, and what finally reaches the tester.
What to do during Web Penetration Testing
Communication with Your Penetration Testers
Maintaining an open and consistent line of communication with the testing team throughout the duration of the test is crucial. Regular updates on progress, findings, and potential delays serve as invaluable tools for clients to keep track of the test’s status. A reputable testing team should willingly offer these updates in a clear, non-technical language that the client can comprehend.
- Progress and Findings: Experienced testers typically keep their updates generic and avoid disclosing sensitive information through insecure channels like emails.
- Timely Reporting of High/Critical Risks: Should high or critical risk findings emerge, these should be promptly communicated to the client, provided there is sufficient justification for the risk.
- Immediate Action on Critical Vulnerabilities: In rare cases should a critical, easily exploitable vulnerability be left unaddressed until the final report is delivered. Immediate communication is imperative in such instances to allow for quick remedial action.
Understanding and Interpreting Preliminary Web Penetration Testing Results
Comprehending the initial findings of the penetration test is crucial for the client. Testers should present these results in a format that is easy to understand. A typical penetration testing report will likely include the following components:
- Clearly Defined Scope: This section outlines the boundaries and focus areas of the test.
- Risk Rating Tables and Appropriate Graphs: These offer a visual representation of the vulnerabilities found, categorised by their risk levels. (Usually displaying the critical findings at the top, and the less significant findings at the bottom)
- Higher-Level Summary: This part provides an overview of the main findings, ideally in a language that non-technical stakeholders can understand. (Such as C-level execs)
- Technical Summary: A more detailed account that dives into the specifics of the vulnerabilities discovered, usually intended for a technically savvy audience.
- Technical Findings: This segment presents the vulnerabilities in detail, including how they were discovered and potential ways to mitigate them.
- Appendix: Information which is either, not suitable for the findings section or not relevant to the findings may be listed here.
What do after Web Penetration Testing
Reviewing the Penetration Test Report
After the test concludes, the testing team usually presents the client with a report detailing the findings. This report should clearly outline each vulnerability, its potential impact, and recommended remediation steps. The client should prioritise fixes based on risk levels, addressing high-risk vulnerabilities immediately. Any unclear elements within the report should be highlighted and clarified by the chosen provider. A reputable penetration testing company should be willing and able to make such clarifications.
Remediation
Prompt remediation of discovered vulnerabilities is essential. There have been instances where organisations received detailed reports but delayed taking action. Such delays can leave the web application vulnerable. It’s advised that the client works with their IT department or an external provider to address each vulnerability, beginning with the highest-risk ones.
For efficiency, it may be useful to tackle similar types of vulnerabilities together during the remediation phase. For instance, adding HTTP Security Headers to a web application can coincide with the removal of headers that disclose information, such as a “Server:nginx” header. However, caution is advised when adding a content-security-policy header, as implementing a robust CSP policy can be complex and may require the expertise of a well-rounded developer.
Retesting and Ongoing Security
After the remediation phase, a retest is advisable to ensure that the vulnerabilities have been adequately addressed. Ideally, the same team that conducted the initial test should perform the re-test for consistency. It’s unusual for another provider to conduct the re-test unless there were significant issues with the initial provider. Some providers offer free retesting, while others may charge. It is prudent to inquire about retesting options before committing to a provider; this should ideally be part of the initial project proposal to limit additional administrative overheads.
Ongoing security efforts should not end with a single test. Regular penetration tests and security assessments should be part of the client’s continuous security strategy.
Conclusion
Embarking on an initial web penetration test may seem daunting for the client, but with careful planning and execution, it serves as an invaluable step towards robust security. This guide serves as a roadmap for those navigating the complexities of web application security. In the field of cybersecurity, vigilance and proactive efforts are crucial. The benefits of a well-executed penetration test are manifold, safeguarding not just data and users, but also the reputation of the organisation.