The Minimum Viable Web-App Pen Test Methodology

Written by

Web application penetration testing is arguably one of the most important disciplines within IT Security. Web applications are the primary way that online services are accessed today, whether it is via Software as a Service (SaaS), a piece of network equipment or heating and ventilation systems.

Necessary Tools

Burp Suite (https://portswigger.net/burp) has quickly become the defacto testing utility for penetration testers. It does have a free version; however, the professional and paid version contains some useful features, including:

  • Vulnerability scanning, called Active Scanning in the product.
  • No limitations on the fuzzing engine, whereas the free version has a throttle on it.
  • Content discovery module for finding additional content on the target system.
  • More advanced and useful features, e.g. finding HTML comments, searching and more.
  • Saving sessions and project management utilities.

Other proxies may also be useful, e.g. OWASP Zap, however in this post we’re going to be utilizing Burp Suite. Most techniques here should nevertheless be transparent enough to be applied in other brands of software, not just Burp Suite.

Useful Extensions for Burp Suite

Most of these extensions are made by James Kettle (Twitter: @Albinowax), Head of Research at Portswigger Web Security, aka Burp Suite.  This section will only contain a brief overview of the most useful plugins which we, at Netsecurity, have found to be the most valuable in a Minimum Viable Testing process.

Active Scan ++

A nice little addition to the Burp Suite active scanner. Allows for some checks against interesting results from the application and is primarily a resource for follow-up research concerning a script which may or may not be vulnerable.        

Additional Scanner Checks

This extension allows you some easy and automated ways to check against e.g. missing security headers from the server. Also contains some decent ways to find DOM based XSS vulnerabilities.

Backslash Powered Scanner

This extension is power to every advanced penetration tester. It essentially allows you to identify weird and unsuspecting behavior in a way which allows the tester to explore potentially interesting flaws in the application, otherwise unbeknown to an ordinary scanner. Beware of false positives, but a sufficiently good tester should be able to deal with those, nevertheless.

Collaborator Everywhere

A beautiful extension which will add references to Burp Collaborator in many different headers across the target in scope. I recommend enabling this while browsing the full attack surface of the application once, then disabling it.

Param Miner

Allows you to identify attack surface through guessable GET, POST and Header values, which otherwise could go undiscovered. Prides itself on great speed!

Honorable Mentions

CSP Auditor allows you find potential weak CSP configurations and provides a clearer understanding of the CSP rules at the target system.

J2EE scan allows you to find a huge range of potential vulnerabilities in Java Enterprise deployments. You don’t want to miss the findings this extension allows you to find.

Retire.js pinpoints Javascript libraries with known vulnerabilities, so you can better identify if any of the vulnerable functions are in use, and you can create working proof-of-concepts and also advise your client on how to include Javascript in their patch management program.

The Methodology

The first goal of the minimum viable methodology is to allow yourself to fully map the attack surface of the application. I recommend looking into the Web Applications Hacker Handbook, Second Edition’s methodology for full coverage on how this is done.

Map the Browsable Attack Surface

As a minimum, the pen tester must make sure the entire application is carefully browsed, to ensure that all linked content can be discovered. This means that the tester can explore, click through all functionality, see and understand how the entire application behaves before receiving any attack traffic. If you can click it, you should map it and fully understand the indented functionality before hacking it.

Map Unlinked Attack Surface

The application may still pose an attack surface, even if you can’t see it, e.g. your current user doesn’t have privileges to view it. It’s very important to discover this functionality, even if you have to resort to guessing. Ideally, the target organisation will give you all the transparency you need to attack every bit of attack surface, however this is not always attainable.

Utilise the sitemap feature of your tool and understand where functionality resides, and potentially where verbs might be fuzzed to discover more functionality, i.e. with Burp Intruder. These are places where you might have a script such as /viewUser. The verb is “view” and therefore we must expect there to be other functions such as /addUser, /removeUser, /updateUser and the likes.

The content discovery module of Burp Suite needs work, however it serves as a decent starting point. Allow the algorithm to discover more content by guessing scripts, something which wordlists, targeted and custom wordlists allow you to map out. Other tools like DirBuster from OWASP also allow you to try to find unlinked content. All folders and scripts should be enumerated, considering they might expose other extensions as well, such as .bak, .backup, .gzip and more.

Utilise Your Penetration Testing Knowledge to Find Vulnerabilities

It’s time to attack and map out vulnerabilities present in the application. Modern web applications normally consist of multiple layers of middleware before even touching the application- or web-server where the functionality is present, each one important to attack.

For each attack point, make sure you have at least taken the following steps.

Run the Scripts through Repeater

The Repeater is a tool in Burp Suite which allows you great control of the requests you make towards a script. It allows you to manually test and understand the target script, so you can better attack it. Remember, automation won’t help you uncover the more advanced vulnerabilities, so it will require you to properly understand each script in the most utmost detail.

Allow the Fuzzing engine, Intruder, and the Corresponding Extensions to do its Work

The fuzzing engine allows you to test out the individual parameters that the script accepts. Ensure you try with different wordlists containing classes of attacks, such as a great number of different types of attacks versus e.g. SQL injection and more.

The Intruder in Burp Suite also allows you to send individual parameters to the Active Scanning engine, giving you greater comfort in knowing that most classes of vulnerabilities are being tested for. This also enables the extensions to do their work against the individual input parameters.

Finally, it takes manual labour to identify any discrepancies and anomalies to be further investigated.

This step is a crucial one; we must manually explore and understand how the application performs under any type of input. This is where we test the application, and the underlying layers, for any types of interesting behaviour. For this step I recommend to you fuzz the script with inputs ranging from through ? and record the responses. Any anomalies should be investigated. Try with and without URL encoding for all possible hex values, and most likely you will see interesting behaviour allowing you to manually test further.

What’s hot on Infosecurity Magazine?