10 January, 2020

What tools are used when penetration testing a Web Application?

What tools are used when penetration testing a Web Application?
Mic Whitehorn
Author: Mic Whitehorn
Share:

Whether you are hiring a penetration testing company or building your own application security team, you may be interested in understanding what tools are necessary to perform the task of a web application penetration test. Before diving into tools, it is important to realize that proper testing of a web application involves a thorough understanding of the application and precise use of the correct tools for the circumstances (i.e. not every tool is a hammer). Automated tools can only find the specific flaws they are designed to detect, which may work well for some testing in a development pipeline but are not suitable on their own for a thorough penetration test of an application.

The tools used for a given penetration test will vary depending on the type of test and the composition of the target. They can be divided into the following categories:

  1. Web Client Tools
  2. Web Proxy Tools
  3. Source Code Tools
  4. Custom Tools and Scripts

Web Client Tools

Since we need to analyze our target in order to understand it, we will need a web client tool. The most common tool in this category is, of course, our web browser. Be it Chrome, Firefox, Safari, or Internet Explorer, it will be used to interact with a website. All modern browsers also include developer tools and support for various plugins which can be very helpful in understanding and even manipulating the client side content and code that make up a web application.

When the test is focused on Web Services or APIs (or micro-services), other web client tools may be more suitable than a browser. For example, Postman and Insomnia are excellent tools for managing and scripting API tests. Though they are designed for development and QA, they function just as well for security testing.

Web Proxy Tools

For most application penetration tests, the majority of the effort is best described as a tool-assisted manual effort. What this means is that the tester will open the application in the browser, and play with it, to understand how it is intended to work. In this common scenario, the web penetration tester's main tool is the man-in-the-middle or interception proxy. Two of the best-known proxies are Portswigger's Burp Suite and OWASP® ZAP (open source). These proxy tools keep a history of the tester's browsing activity, and allow replaying and tampering with web traffic. They also include fuzzing tools, which allow the tester to highlight input points and try many different values in a semi-automated fashion. Both Burp Suite (Pro and Enterprise) and ZAP also include limited automated vulnerability scanners and have extension APIs so that additional functionality can be easily plugged into the proxy tool.

Testing of Source Code

For tests performed with access to source code, such as those done by an internal application security team, or those integrated into the Software Development Lifecycle (SDLC), more automated tooling makes sense - either on its own or in addition to penetration testing efforts. This can consist of broader static-analysis and dynamic analysis tools, or more purpose-specific tooling such as dependency checkers like OWASP® Dependency Check, Snyk, or Retire.js. This is not limited to security-focused tooling either. A security defect in software is just a software defect with a security impact. Therefore, tools and practices that are geared towards improving code quality in general will also provide an inherent security benefit. This includes many practices that are relatively common today, such as mandatory code-reviews before merging, and writing unit and integration tests.

Custom Tools and Scripts

In some circumstances the built-in tools found in web proxies or in the browser are insufficient to test, discover, and exploit certain vulnerabilities. Some examples include the use of specialized attack payloads such as Serialized Java Objects or the exploitation of the Shellshock vulnerability. In these cases the tester may opt to use a more specialized tool or script. In many cases, such tools and scripts are packaged up to function as plugins for Burp or ZAP.

In rare circumstances, a tester will encounter a condition that cannot be tested with any of the available tools and will need to make one. A common programming language for doing so is Python, due to its short learning curve and abundance of available libraries. Other languages that are often used for custom testing tools and scripts are JavaScript, Ruby, GoLang, and PowerShell.

The Most Important Tool

You may have noticed that we did not list dozens of hacker tools, nor did we dive into a lot of detail about each one. That is because the main thing that makes good application security testers stand out is their knowledge and experience, not the toolset they choose. A great application security professional can find most vulnerabilities with little more than a web browser and some scripts (Python, JS, PS, etc...). Other tools are just used to speed up the process and to help manage the huge amount of information that is often involved in analyzing an application for vulnerabilities. Other than a web browser and a knowledgeable tester, the most useful tool is the web proxy (either Burp Suite or ZAP).

Join the professionally evil newsletter