How do you scope and plan a web app pentest project?

In my experience when doing a web app pentest, it's necessary to follow a well-defined methodology and testing technique. This ensures that all portions of the application are tested and no important vulnerabilities are missed. Maintaining open communication and engagement with the client or stakeholder throughout the project ensures they are aware of any potential risks or weaknesses and can reduce them. Documenting the testing process, findings, and recommendations helps clients and stakeholders understand the results and improve the application's security. Finally, web app pentesting requires a constant improvement mindset. To keep the application secure against new threats, it must be retested and reassessed.

Two key elements of defining objective scope for web app pentests are which domains will be tested and which user roles will be tested. For domains, applications often link to or interact with other domains and subdomains for functionality or data, such as an auth.example.com for authentication or api.example.com for data. For user roles, modern applications often define many different roles, often with nearly infinite permutations when roles are defined by granular permissions instead of overall definitions. In theory, every role would be tested for access control issues but doing so can easily be prohibitively expensive.

Defining objectives is important because it sets the direction and purpose of the web app pentest project. It clarifies what needs to be achieved, such as identifying vulnerabilities, assessing security controls, or validating compliance requirements. Clear objectives help focus the testing efforts, ensuring that resources are allocated efficiently and that the desired outcomes are achieved. Additionally, well-defined objectives provide a basis for measuring the success of the pentest and communicating its value to stakeholders.

Before diving in, clarify what you aim to achieve with the pentest. Align your objectives with the business goals, risk appetite, and compliance requirements of your client or stakeholder. For instance, you might want to identify critical vulnerabilities, assess security controls, or simulate a real-world attack. Also, ensure to agree on the scope, timeline, budget, and deliverables to set clear expectations.

In my experience, a penetration test should be treated as a normal IT project in order to not fall into the common pitfall of scope creep which I'm sure we've all faced due to our love to hack thoroughly. This means that there should be an experienced leader in the team who has set out the teams objectives, priorities, and KPI's for the year so they can manage the yearly requests sent to pentest team. Having an intake request form can help both parties have clear expectations on: -Request priority -Date requesting team needs the pentest report by -Type of pentest: Web App, Cloud, Network, Endpoint Control Testing, API Focused, or CI/CD(Few examples) -Key POC's -Assets in scope -Times to test -Update expectations -Credentials required

My best recommendation on gathering information is for the penetration tester to create their own methodology. There are plenty of checklists on GitHub yet learning and building one from what you've done will help you build confidence in teaching others. Looking at the entire external or internal attack surface is the best way to gather information from a webapp. Personally I like to use plugins on Firefox such as Shodan, Wappalyzer, and BuiltWith so I can enumerate what ports are open, JS libraries, CDNs, 3rd party Plugins, and tech stack. For public enumeration the two tools that can be used by defenders and offsec professionals are urlscan.io, dnsdumpster.com, and using Google dorks on the site.

In my experience, by gathering as much information as possible about the target web application and its environment, the penetration tester can gain a better understanding of potential vulnerabilities and attack vectors that could be exploited.

Collect as much information as possible about the web application. This includes understanding its architecture, functionality, and the technologies used. This phase, often referred to as reconnaissance, helps in planning the test effectively.

Next, collect comprehensive information about the target web application and its environment. This should include details like the domain name, IP address, hosting provider, web server, technology stack, and user roles. Utilize tools and techniques for passive and active reconnaissance, such as DNS queries, web searches, network scans, and directory enumeration. The insights gained will help you map the attack surface and refine your testing strategy.

An excellent example of the value of information gathering is performing reverse DNS lookups on the target IP address or enumerating other domains that resolve to the same IP address. These additional domains are additional ways to access the same host and environment and might even provide higher levels of access, such as an admin portal that manages the application but the code for which is hosted at a different domain. Information like this may not directly tie to active testing, depending on the defined scope, but will provide valuable context for any identified issues and can be eye opening for clients who didn’t expect you to find it.

I agree with the tools mentioned above yet something I learned after several months of pentesting is that it's better to know how these tools work under the hood. For example learning the default scan types and enumerations kicked off will allow you to understand how much traffic you're generating on the network or against the load balancer. After understanding the manual way of how these great tools work, it will allow you to determine if there are limitations or payloads to be mindful of. Automation is great once a foundation has been built.

Choosing the right tools and methods for a web app pentest is pivotal. From my experience, blending both manual insights and automated tools like Burp Suite and OWASP ZAP yields the most comprehensive understanding of vulnerabilities. It's not just about identifying common vulnerabilities like SQL injection or XSS but understanding the unique context of the application. Automated tools can quickly cover ground, but manual testing is crucial for nuanced threats. Equally important is the documentation and reporting phase, where findings must be communicated effectively to drive remediation. This approach not only uncovers critical vulnerabilities but also fosters a culture of continuous security improvement within the development lifecycle.

An example we can take is that Automated testing tools can help increase efficiency by automating repetitive tasks and performing scans on a large scale. However, manual testing can provide a more thorough and nuanced examination of the target system, and can uncover vulnerabilities that automated tools might miss. Therefore, it is often recommended to use a combination of both automated and manual testing. Finally, it is important to properly document and report the findings of the penetration test. This includes detailing the testing methodology, identifying vulnerabilities, and providing recommendations for remediation.

Solely automated testing isn’t a penetration test. It is a vulnerability scan at best. Generally, tools and scripts serve a specific purpose within a larger testing process. So, you might use Burp Suite for most of your testing but use Nikto for information gathering and sql map for exploiting any sql injection found.

With a clear understanding of the target application, select the tools and methods that best align with your objectives. Options include Nmap, Burp Suite, OWASP ZAP, Metasploit, and more. Familiarize yourself with common web vulnerabilities, particularly those listed in the OWASP Top 10. Decide on your approach—whether automated, manual, or a combination—and plan how you will document and report your findings.

Proxy tools such as Burp Suite are in every pentester's toolset. In my opinion, Tor should not be used. Since a penetration test is a planned and transparent engagement, avoidance of detection is not necessary (unless specified). Using Tor browser could potentially cause confusion in identifying the authorized penetration testers and real malicious users. In other words, it would be very hard to verify if the traffic is coming from legitimate sources or malicious sources such as black-hat hackers trying to break into the web app.

I agree, but. It is important to follow a systematic and ethical approach during the testing phase, which includes respecting the scope, rules of engagement, and legal boundaries of the project. This means staying within the agreed-upon scope of the penetration test, adhering to the rules and guidelines provided by the client or organization, and following all applicable laws and regulations. Using a proxy tool to intercept and manipulate web requests and responses can help penetration testers to identify potential vulnerabilities and attack vectors. Similarly, using a VPN or Tor to hide the identity and location of the penetration tester can help to protect their anonymity and avoid detection.

In this phase, you’ll actively attempt to exploit identified vulnerabilities. Maintain a systematic and ethical approach, adhering to the agreed-upon scope and legal boundaries. Utilize a proxy tool to intercept web requests, and consider using a VPN or Tor for anonymity. Always verify your findings while ensuring no harm comes to the web application or its users.

A proxy tool (Burp Suite has a built-in proxy) is crucial for identifying back-end requests that aren't obvious from within the browser. Often these are handled entirely through JavaScript (Ajax, jQuery, etc.) and it is common for developers to skip securing them as well as they should because they don't expect standard users to know how to access them. It is rare, however, for a pentester to use a VPN or Tor to hide their location. Unless testing is specifically trying to avoid detection, pentesters usually share their source IP's so the monitoring team can differentiate between actual threats and testing activity. Security analysts can also perform correlations between attack traffic and security alerts after the engagement is over.

Execute the planned tests. This could involve various techniques like SQL injection, Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF) among others. Remember to conduct these tests ethically and responsibly.

Finally, analyze your findings and compile a professional report. Organize your results by severity and impact, providing evidence and screenshots to back your claims. Suggest remediation steps and best practices for addressing the vulnerabilities identified. Communicate your report promptly and respectfully to the client or stakeholder, ensuring clarity and professionalism.

An effective report must serve to both technical experts and non-technical stakeholders. It should start with an Executive Summary, outlining the tests conducted, methodologies used, and their real-world impact, emphasizing actionable insights over raw data. Vulnerabilities must be presented in straightforward steps, understandable without technical expertise, and include practical examples of potential risks to the business. This approach ensures that the report is not only informative but also compels all readers to recognize and act on the identified vulnerabilities.

A good report will also have a step by step guide to recreate any issues found. The guide should be written for somebody technical but not necessarily an expert in security concepts. So, screenshots and exact commands run are always great. In addition, severity ratings should be contextualized for the particular client/environment. So, for example, if the testing team was whitelisted at the firewall to allow testing activity, that is a particular context that must be incorporated into the "likelihood of the vulnerabilities" identified.

I always remember an old IT teacher shouting "write it so your grandmother can follow it!" Analysing and Reporting is arguably the most crucial step in a penetration test as it provides most value to the business. The report should include a summary overview including risks findings with a severity rating that non technical decision makers can follow. Following this, a detailed section of the report should include descriptions of the vulnerabilities with screenshots and provide remediation advice that a technical employee can follow. Finally for successful exploitation, I like to include a walkthrough section demonstrating how this was achieved.

After the tests, analyze the results to identify vulnerabilities. Prepare a detailed report outlining the findings, the potential impact of the vulnerabilities, and recommended remediation steps. The report should be understandable to both technical and non-technical stakeholders.

In my experience, organizing and prioritizing the findings based on the severity, impact, and likelihood of the vulnerabilities can help the client to understand the potential risks and prioritize their remediation efforts accordingly. Providing evidence and screenshots to support the claims can also help to reinforce the severity and impact of the vulnerabilities. When suggesting remediation steps and best practices, it is important to provide clear and actionable recommendations that the client can implement to address the identified vulnerabilities. The recommendations should also take into account the specific needs and requirements of the client, and any constraints or limitations they may have.

Generally speaking, do not test your applications when running WAFs or Load balancers. The app needs to be able to stand on it's own. Research into WAF bypasses is ongoing, and load balancers can hide issues you might not be aware of. Certainly use both of these technologies in your production environment as needed, but don't test with it. Are you testing the application, or the effectiveness of your WAF?

After successfully concluding the project, seize the opportunity to acknowledge your team's perseverance and diligence. Your team has expertly navigated the complex realm of pentesting and emerged as triumphant victors! 🙌🏾 Reflect on your accomplishments, learn from the experience, and let the shared sense of achievement to fuel your passion for even greater successes in the future.