What Happens During a Web Application Penetration Test?

The world of information security is ever-evolving as further innovation and development continue to drive the market forward. Web applications are no exception, but as they grow more complex with the addition of new features and supporting technology, so do their attack surfaces.

Sometimes, it can feel like the latest risk to your web application is seemingly around the corner, and really, that might be true—it’s become more important than ever to maintain a good security posture.

As highly experienced penetration testers, we know that an application security penetration test is a key component of that. Though you may have your own internal security teams, having a third-party pen test performed allows you to gain an outside perspective, often identifying critical issues that have been overlooked.

But with so many options to choose from in evaluating your cybersecurity, why choose this one? What would it entail?

In this article, we’ll provide information that will clarify both with some Schellman specificity. We’re going to overview, at a high level, our methodology for web application penetration testing and provide some insight into what happens during one of these engagements.

(We’ve written before about our process more generally, but this will be specific to web applications.)

That way, you’ll know what to expect should you choose to go this route with your web application. Of course, we can only really speak for ourselves, but even if you don’t choose us for your penetration testing needs, you’ll still glean a vague understanding of the process.

Schellman’s Web Application Penetration Testing Approach and Tools

At Schellman, we’re constantly expanding our skill set. Our team retains some of the most renowned application security certifications, such as the Offensive Security Web Expert (OSWE) and Burp Suite Certified Practitioner. Additionally, we stay on top of the latest web application threats by keeping up to date with new attacks as research is published, including those debuted at hacking conferences such as Black Hat and DEFCON.

Leveraging experience from training, past engagements, and research, our web application methodology blends industry-standard automated tooling with the latest manual techniques. This unique blend works well for our clients, as the automated check tools ensure adequate coverage, while manual testing allows us to both precisely identify which issues are valid as well as test for more complex issues often missed by automated scans (such as flaws in an application’s business logic).

Testing—both automated and manual—is primarily performed with Burp Suite Professional. We’ve installed both public Burp extensions as well as some we’ve developed in-house that:

• Enable additional automated checks not available by default; and
• Create more efficient manual testing through specialized features.

We also use the latest Open Web Application Security Project® (OWASP) flagship projects like the Web Security Testing Guide (WSTG) at the core of our testing, as they provide established checks for the type of issues that should be flagged during a penetration test.

What is Our Web Application Penetration Test Process?

But what actually happens when you engage our Penetration Testers? How do we apply this approach and tools to your actual application?

Here are the four phases of our process.

1. Preliminary Analysis

Prior to performing active testing, we’ll perform what we call preliminary analysis, which will include:

• Reviewing documentation and videos for the application and supporting APIs
• Confirming access to the application through provided credentials or self-registration
• Identifying technology used to support the application, such as protocols used during the authentication process
• Walking through and mapping the application and functionality

All that will help us understand your application and its general use case by end-users, allowing us to gain valuable perspective on how certain functionality works and what areas are of important focus. 

2. Active Testing – Identification

When our team has an understanding of how the application works and what features are available, active testing begins. Leveraging that knowledge gained from the preliminary analysis, we’ll first focus on identifying vulnerabilities within the features that pose the greatest risk to the environment before moving to other areas.

We’ll configure Burp Suite to intercept all requests made within the web browser being used for testing the application. Each intercepted request will then undergo a manual assessment before any automated scans:

1. Manual Testing: We’ll first send a base set of payloads and review how the application responds for indications of exploitability. Depending on how the application responds, the issue being tested, and other factors that may be unique per application, updates will then be made.
   • Performing manual testing first ensures our understanding of how the requests affect the application before any automated scanning is done.
2. Automated Checks: With manual testing done, we will next configure automated scanning to scan specific areas within a request, some of which include parameter values and HTTP headers.
   • Performing automated scanning leverages a large database of frequently updated payloads and wordlists from various sources, covering a great deal of ground in a short timeframe. 

Some common issues found during this phase include:

• Authentication vulnerabilities (OAuth, SAML, and JSON Web Tokens (JWT) attacks)
• SQL Injection
• Insecure-direct Object Reference (IDOR)
• Authorization Bypass
• Stored, Reflected, and DOM-based Cross-site Scripting (XSS)
• Server-side Template Injection (SSTI)
• Server-side Request Forgery (SSRF)
• Business Logic Flaws
• Disclosure of Sensitive Information 

Findings identified via automated checks—such as the above, or others—are then manually verified. 

3. Active Testing – Exploitation

Once a vulnerability has been identified and verified, we’ll take additional steps to demonstrate the risk it poses to your application by exploiting the issue though we will also first consider the potential impact exploitation could have on your overall environment before proceeding. (E.g., exploits with the potential to cause Denial-of-Service (DoS) conditions will never be intentionally performed.)

Some scenarios of common exploits include:

• Exploiting weaknesses in authentication, such as account takeover via flaws in password reset processes and the use of weak JWT signing keys
• Abusing lack of access-control rules from the perspective of a low-privileged account to obtain access to administrative areas of an application
• Developing XSS payloads that demonstrate the worst-case scenario for your application, such as the exfiltration of sensitive data, session cookies, or performing CSRF-esque attacks from a low-privileged user to obtain additional access
• Exploiting SSRF to obtain data from internal sources such as metadata services used in cloud computing environments which commonly expose access and secret keys
• Demonstrating how open redirects can be used to direct users to malicious third-party sites designed to capture their credentials
• Leveraging sensitive information obtained from verbose stack trace errors to perform chained exploits, such as identifying and then performing exploits against leaked outdated software versions and disclosed file paths used in conjunction with local file inclusions attacks 

4. Documentation and Reporting

Any findings will be confirmed and their impact determined. Throughout our engagement, we will provide weekly status reports with the latest findings. Any high-risk issues will be sent to you within 24 hours of being identified and fully documented so that your developers have the information they need to fix the issue before the final report is issued. 

Any identified findings will also be documented with clear and concise descriptions and replication steps, including screenshots that will walk you through the tester’s perspective on how both an issue was identified as well as the steps we took in exploiting the issue to demonstrate impact. 

This approach works well for our clients, as it allows their developers to have the information they need to fix the issue before the final report is even issued. Once we deliver you the final report, you’ll have an opportunity to validate your remediation efforts with us once identified findings have been fixed.

Next Steps for Your Web Application Penetration Test

For a more detailed look at Schellman’s general penetration test engagement process, you can check this article here. But the above information provides a more drilled-down, specific look at our web application testing methodology that will help you set clearer expectations for your own, should you decide this is the path for you.

To simplify your experience even further, check out our other content that will both answer big questions and provide further valuable insight for your next steps:

• How Long Does a Penetration Test Take?
• The Intricacies in Pen Test Timing
• How to Prepare for Your Web Application Penetration Test