Foued Dridi

This is an article I wrote for a hacking magazine back in 2020 about one of the most powerful features of Burp Suite :

Web and mobile applications are gaining a huge reputation among other Human Machine Interfaces (HMI). Today’s applications are so huge. One application may cover many business units, like online shopping and payment, chatting, etc.

Despite its complexity, an app is still an interaction between methods and functions; built-in and custom functions. Independently of the programming language and in order to perform a very specific task, some functions require parameters. For example, in object-oriented programming, to modify the value of an object’s attribute, the setter method needs a parameter to affect its value to the object’s attribute.

In some cases, the constructor of a particular class may depend on parameters, and because of the nature of the object oriented programming concept, the same class may use a second constructor with more parameters than the first one. If the second constructor requires three parameters and these are retrieved from the user input, this constructor will be used when we send the specific request with three parameters, even though the developer intended to use the other constructor.

On the other hand, when dealing with complex applications, to use a specific functionality, we need to follow multiple steps. For example, let us imagine we are using a web application that contains a “profile” button that when clicked on, our personal information is displayed to us. To reach the profile’s button, we first need to log in, then once in the home page, we scroll down until we find the profile button. We click on it and we have our personal data. If we follow the HTTP traffic using Burp proxy, after entering our login and password, we will find that the authentication request contains a parameter called « loginid » (this name depends on how a developer has chosen to name parameters). We forward our request. In the following requests, we notice the addition of the cookie header but also the absence of the parameter “loginid”.

We conclude that the remaining requests do not need this parameter anymore, but what will happen if we add the “loginid” parameter to the remaining requests? What will happen if we change its value?

Well, this is the purpose of this article. Parameters enumeration is a pentest technique that may be fruitful. It has different approaches. Previously, we talked about one approach of this technique, which consists of using the same parameter in a previous HTTP request in other requests. The second approach is to add a parameter, independently of the previous HTTP requests, and forward the request using Burp proxy.

For example, when trying to access the application we are pentesting, we intercept the first HTTP request with Burp proxy, add the parameter « debug » with the value « true » and forward the request.

When I used this approach while pentesting a web application, I noticed that the application added a download button at the top of the authentication interface. When I clicked it, I was awarded with the server log file. This is considered a jackpot for a pentester or a hacker. After delivering my report, I was told that the “debug=true” option is used by developers to investigate problems related to some modules and they forgot to delete it in the production website.

For better efficiency, when enumerating parameters, try to switch between POST and GET methods, which means add parameters in the URL and in the body of the HTTP request and also try as many parameters as you can. Example, add admin=true, id=1, etc.

Also, try to access a post authentication URL without logging in and add parameters such as « logged » with “1” as value and verify if the application treated the request as if you are legally authenticated.

Burp Suite can help us when dealing with parameters enumeration. It comes with an extension called “Param Miner”. It is available in the Burp Community version and can be found in the BApp Store of the Extender window:

Figure 1 : Param Miner extension

In order to show an example of how Param Miner works, we will install another Burp extension called “Flow”:

Figure 2 : Flow extension

Flow will show us the items and requests “Param Miner” is sending. We install “Param Miner”, intercept an HTTP request and choose “Guess GET parameters” as shown below:

Figure 3 : Parameters enumeration

We receive the configuration interface as shown below:

Figure 4 : Configuration interface of parameters enumeration

In this example, we will use the basic wordlist of Param Miner, but we can use our custom wordlist. We click the OK button and we switch to Flow window.

Figure 5 : Flow window showing GET parameters brute force process

We can see that Param Miner is perfectly conducting a brute force on GET parameters. In fact, it starts by saving the response of the original HTTP request. If this response changes for further requests when brute forcing GET parameters, Param Miner will report it. In Burp Pro, the result will be shown in the “Issues” section of the “Target” window.

In the next part, we will talk about another technique that is not so different from the first one. This technique is called HTTP headers enumeration.

As its name perfectly describes it, HTTP headers enumeration consists of injecting HTTP headers into HTTP requests. For example, we add the header X-Forward-For with a specific value. We will come back to this later, but now I want to talk about another header, which is max-forwards.

In fact, when pentesting web applications, one of the vulnerabilities I try to identify is the authorization of dangerous HTTP methods like TRACE. Sometimes when I switch a GET or a POST method to TRACE, I receive either nothing or an error message not related to TRACE being allowed, but when I use TRACE and inject the header “max-forwards: 0”, I find that TRACE is beautifully authorized.

The principle is the same with other headers, but the question here is how to really know whether an HTTP header is used or not. In this case, we can refer to two techniques: the first is to inject a header and give it an XSS payload as value, and the second one is to inject an HTTP header and give it the IP address of a web server we control as a value. In this case, Burp Suite comes handy with its Burp Collaborator. For example, if we want to inject the header X-Forwarded-For and see if it is used by the web application we are targeting, we start by launching Burp Collaborator client, then we copy its value and give it to the header X-Forwarded-For. We forward our request and verify within Burp Collaborator if there is traffic coming to our Burp Collaborator client. If so, we receive something like this:

Figure 6 : Burp Collaborator client

Burp Suite can help us automate the task of enumerating HTTP headers. In fact, Param Miner offers this functionality that is similar to the “Guess GET parameters” option, but the only difference is that the second one deals with parameters and the first one deals with headers.

To enumerate HTTP headers, we intercept our HTTP request and choose “Guess headers!” as shown below:

Figure 7 : Guess headers Option

Similar to “Guess GET parameters”, we are asked to configure the headers enumeration attack:

Figure 8 : Configuration interface of HTTP headers enumeration

There are some options to configure the attack task, but the most obvious one is the wordlist. Here, we will use the basic wordlist used by Param Miner for headers enumeration. We launch our attack and verify the HTTP requests sent with Flow:

Figure 9 : Flow window showing HTTP headers brute force process

When using Burp Pro, if Param Miner identifies the usage of an HTTP header, it will report it in the “Issues” section of the “Target” window.

Other than parameters and headers enumeration, Param Miner provides us with another test option, which is cookies enumeration. In fact, the name of a cookie can distinguish a server from another. For example, if we find that our target web application is using a cookie called “jsessionid”, we are 90 percent sure the application server being used is Tomcat. This way, identifying all cookies may help us gather information about the technologies in place (web server, WAF, load balancer, etc).

On the other hand, the cookie is another attack vector: it may be vulnerable to SQL injection and Cross-Site Scripting attacks. A cookie may also be a way to exploit a broken access control flaw.

For example, if we add a cookie called “is_admin” and we give it “1” as value, we can find ourselves authenticated with an administrative role. This way, by identifying what cookies are used, we literally extend our attack surface.

To use this test technique, we intercept the target HTTP request and choose the option “Guess cookie parameters”:

Figure 10 : Guess cookie parameters option

We receive the configuration interface as shown below:

Figure 11 : Configuration interface of cookies enumeration

We keep the default configuration and launch the attack. Then, we refer to the “Flow” window:

Figure 12: Flow window showing cookie parameters brute force process

As shown in the above picture, we can notice that Param Miner is running a brute force attack on the cookie parameters of our HTTP request. Similarly, the result will be reported in the Issue section of the Target window in case of Burp Pro.

In conclusion, GET / POST parameters, cookie parameters and headers enumeration may allow us to go beyond developer’s intentions and exploit functionalities that are not even exposed to user interactions. Mastering these techniques can make a difference during web/mobile applications pentests. As always, Burp Suite comes in handy with its rich extensions’ capabilities. It is preferable to start identifying the programming language used to develop the target application and use a wordlist of items related to this programming language.