LabEx
Log InJoin Free

Fuzz for GET Parameters in Gobuster

Beginner
Practice Now

Introduction

In web application security, discovering hidden or undocumented GET parameters is crucial for identifying potential vulnerabilities. These parameters can sometimes lead to information disclosure, SQL injection, or other security flaws if not properly handled by the application. Gobuster, a popular directory and file brute-forcing tool, also offers a "fuzz" mode that can be leveraged to discover GET parameters.

This lab will guide you through the process of using Gobuster's fuzz mode to identify GET parameters. You will learn how to construct a URL with a FUZZ keyword, use a wordlist of common parameter names, execute the scan, and analyze the results to find interesting parameters. By the end of this lab, you will have a practical understanding of how to perform GET parameter fuzzing with Gobuster, a valuable skill for any cybersecurity enthusiast or professional.

Identify a URL Endpoint to Test

In this step, you will identify a target URL endpoint that you want to test for hidden GET parameters. For this lab, we will use a simple web server that simulates a vulnerable application. We will start a Python HTTP server to serve a basic HTML file.

First, navigate to your project directory:

cd ~/project

Next, create a simple HTML file named index.html that we will use as our target. This file will simulate a web page that might accept GET parameters.

nano index.html

Add the following content to index.html:

<!DOCTYPE html>
<html>
  <head>
    <title>Test Page</title>
  </head>
  <body>
    <h1>Welcome to the Test Page!</h1>
    <p>This page is for testing GET parameters.</p>
  </body>
</html>

Save the file by pressing Ctrl+X, then Y, and Enter.

Now, start a simple Python HTTP server to serve this file. This server will run on port 8000.

python3 -m http.server 8000 &

The & at the end runs the server in the background, allowing you to continue using the terminal. You should see output similar to this:

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

The target URL endpoint for our fuzzing will be http://127.0.0.1:8000/index.html.

Construct a URL with a FUZZ Keyword as a Parameter Name

In this step, you will learn how to construct the URL that Gobuster will use for fuzzing. Gobuster's fuzz mode requires a FUZZ keyword in the URL to indicate where the wordlist entries should be inserted. When fuzzing for GET parameters, the FUZZ keyword replaces the parameter name.

The basic format for a GET request with a parameter is http://example.com/path?parameter=value. To fuzz the parameter name, we will replace parameter with FUZZ. The value can be anything, as we are only interested in discovering the parameter name itself. A common practice is to use a simple value like 1 or test.

For our lab, the target URL is http://127.0.0.1:8000/index.html. To fuzz for GET parameter names, the URL will be constructed as follows:

http://127.0.0.1:8000/index.html?FUZZ=test

Here:

  • http://127.0.0.1:8000/index.html is our base URL.
  • ? indicates the start of the query string.
  • FUZZ is the placeholder where Gobuster will insert words from our wordlist.
  • =test is a static value for the parameter. The specific value doesn't matter for discovering the parameter name, but it's required for a valid parameter format.

You don't need to execute any command in this step, but understanding this URL construction is crucial for the next steps.

Use a Wordlist of Common Parameter Names

In this step, you will prepare a wordlist containing common GET parameter names. Gobuster will iterate through this wordlist, replacing the FUZZ keyword in the URL with each word from the list.

While Gobuster often comes with default wordlists, it's good practice to know how to create or specify your own. For this lab, we will create a small custom wordlist with some common parameter names.

First, ensure you are in the ~/project directory:

cd ~/project

Now, create a new file named params.txt which will serve as our wordlist:

nano params.txt

Add the following common parameter names to params.txt, each on a new line:

id
name
user
page
search
query
file
data
token

Save the file by pressing Ctrl+X, then Y, and Enter.

This params.txt file will be used by Gobuster in the next step to fuzz the GET parameters.

Execute the gobuster fuzz Scan

In this step, you will execute the Gobuster fuzz scan using the constructed URL and the wordlist.

The command for Gobuster's fuzz mode is gobuster fuzz. We need to specify the URL with the FUZZ keyword using the -u flag and the wordlist using the -w flag.

Open your terminal and run the following command:

gobuster fuzz -u http://127.0.0.1:8000/index.html?FUZZ=test -w ~/project/params.txt

Let's break down the command:

  • gobuster fuzz: Invokes Gobuster in fuzzing mode.
  • -u http://127.0.0.1:8000/index.html?FUZZ=test: Specifies the target URL with the FUZZ placeholder.
  • -w ~/project/params.txt: Specifies the path to our wordlist containing parameter names.

Gobuster will now send requests to the web server, replacing FUZZ with each word from params.txt. Since our index.html doesn't actually process these parameters, Gobuster will likely report the same status code and content length for all requests. However, in a real-world scenario, a change in status code or content length would indicate that a parameter might be recognized.

The output will show each attempt and the corresponding status code and content length. It will look similar to this:

===============================================================
Gobuster vX.X.X
===============================================================
[+] Url: http://127.0.0.1:8000/index.html?FUZZ=test
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /home/labex/project/params.txt
[+] Status codes: 200,204,301,302,307,401,403,405
[+] User Agent: gobuster/X.X.X
[+] Timeout: 10s
===============================================================
200 (290)    - http://127.0.0.1:8000/index.html?id=test
200 (290)    - http://127.0.0.1:8000/index.html?name=test
200 (290)    - http://127.0.0.1:8000/index.html?user=test
200 (290)    - http://127.0.0.1:8000/index.html?page=test
200 (290)    - http://127.0.0.1:8000/index.html?search=test
200 (290)    - http://127.0.0.1:8000/index.html?query=test
200 (290)    - http://127.0.0.1:8000/index.html?file=test
200 (290)    - http://127.0.0.1:8000/index.html?data=test
200 (290)    - http://127.0.0.1:8000/index.html?token=test
===============================================================

Analyze the Results for Changes in Response Length or Status

In this step, you will learn how to interpret the output from the Gobuster fuzz scan. The key to identifying potentially valid or interesting GET parameters lies in observing changes in the HTTP response.

When Gobuster runs, it displays the HTTP status code and the content length (in bytes) for each request it makes.

For example, the output from the previous step showed:

200 (290)    - http://127.0.0.1:8000/index.html?id=test
200 (290)    - http://127.0.0.1:8000/index.html?name=test
...

Here, 200 is the HTTP status code (OK), and 290 is the content length of the response.

What to look for:

  1. Different Status Codes: If a request with a specific parameter name returns a different HTTP status code (e.g., 200 for valid, 404 for not found, 500 for server error, 302 for redirect), it might indicate that the application processed or reacted to that parameter. For instance, a 200 OK for a parameter that usually returns 404 Not Found could be significant.
  2. Different Content Lengths: Even if the status code remains 200 OK, a change in the content length can be a strong indicator. This often means the application's response body changed, perhaps by including specific data related to the parameter, an error message, or a different page layout.
  3. Error Messages: Sometimes, a parameter might trigger an error message (e.g., SQL error, application error) that is reflected in the response body, leading to a different content length or even a 500 status code. This is a strong sign of a potential vulnerability.

In our current lab setup, since index.html is a static file and the Python server doesn't process GET parameters, you will observe that all requests return a 200 status code and the same content length (290 bytes). This is expected behavior for our simple test case.

In a real-world scenario, if you were to fuzz a live web application and saw an entry like:

200 (512)    - http://example.com/search?query=test

while other parameters returned 200 (290), the query parameter would be worth investigating further due to the different content length.

This step concludes the lab. You have successfully learned how to use Gobuster to fuzz for GET parameters and how to analyze the results.

To stop the Python HTTP server, you can find its process ID (PID) and kill it. First, list running Python processes:

ps aux | grep "python3 -m http.server 8000"

You will see output similar to:

labex     1234  0.0  0.0  12345  6789 ?        S    HH:MM   0:00 python3 -m http.server 8000

Note the PID (e.g., 1234 in this example) and then kill the process:

kill 1234

Replace 1234 with the actual PID you found.

Summary

In this lab, you have successfully learned how to perform GET parameter fuzzing using Gobuster. You started by setting up a local web server and creating a target HTML file. You then constructed a URL with the FUZZ keyword, prepared a custom wordlist of common parameter names, and executed the Gobuster fuzz scan. Finally, you learned how to analyze the scan results, focusing on changes in HTTP status codes and content lengths, which are key indicators of recognized parameters.

This technique is a fundamental part of web application reconnaissance and can help uncover hidden functionalities or potential vulnerabilities. By mastering this skill, you are better equipped to identify and investigate web application attack surfaces.