Add Custom Headers to Nikto Scans

Introduction

Nikto is a popular open-source web server scanner that performs comprehensive tests against web servers for multiple items, including over 6700 potentially dangerous files/programs, checks for outdated versions of over 1250 servers, and version-specific problems on over 270 servers.

Sometimes, a web application requires a specific HTTP header to be present in requests. This could be for authentication (like an API key or a session token), for routing to a specific version of an application, or to enable a debug mode. Standard Nikto scans would fail or be incomplete in these scenarios because they would lack the required header.

In this lab, you will learn how to use Nikto's -addheaders option to include custom headers in your scans. This allows you to test applications that have specific header requirements, ensuring a more thorough and accurate security assessment.

Identify a custom HTTP header required by an application

In this step, you will interact with a simple web application to understand why a custom header might be necessary. We have a web server running on port 8000 that requires a specific header, X-LabEx-Auth, for access.

First, let's try to access the web application without the custom header using the curl command.

curl http://127.0.0.1:8000

You will receive an "Access Denied" message, as the required header is missing.

Access Denied

Now, let's send the request again, but this time we will include the required custom header using the -H option in curl. The header is X-LabEx-Auth with the value SecretToken.

curl -H "X-LabEx-Auth: SecretToken" http://127.0.0.1:8000

This time, the server grants access and returns a welcome message. This confirms that the application checks for this specific header.

Welcome, authorized user! The server is Apache/2.4.1 (Unix).

This process demonstrates how to identify and confirm the need for a custom header before running a security scan.

Use the -addheaders option to specify the header and value

In this step, you will learn about the Nikto option used to add custom headers to its scans.

Now that we know a custom header is required, we need to tell Nikto to include it in all of its HTTP requests. Nikto provides the -addheaders option for this purpose.

The syntax is straightforward:

-addheaders "HeaderName:HeaderValue"

You replace HeaderName with the name of the header (e.g., X-LabEx-Auth) and HeaderValue with its corresponding value (e.g., SecretToken).

If you need to add multiple custom headers, you can separate them with a newline character (\n). For example:

-addheaders "Header1:Value1\nHeader2:Value2"

For our current scenario, the complete Nikto command structure to scan the target application would look like this. Note that we are not running the command in this step; we are just constructing it to understand the syntax.

nikto -h http://127.0.0.1:8000 -addheaders "X-LabEx-Auth: SecretToken"

This command instructs Nikto to target the host at http://127.0.0.1:8000 and to add the X-LabEx-Auth: SecretToken header to every request it sends during the scan.

Run a scan with the custom header included

In this step, you will execute a Nikto scan using the -addheaders option you just learned about.

With the correct command constructed, it's time to run the scan. This will allow Nikto to interact with the application as an authorized user, potentially uncovering vulnerabilities that are not visible to unauthenticated users.

Execute the following command in your terminal:

nikto -h http://127.0.0.1:8000 -addheaders "X-LabEx-Auth: SecretToken"

Nikto will now start the scan. Because every request includes the X-LabEx-Auth: SecretToken header, the web application will process them successfully. Observe the output from Nikto. It will identify the server and begin testing for various vulnerabilities.

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: Werkzeug/2.0.1 Python/3.10.6
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI directories found (use '-C all' to force check all possible dirs)
+ "Allowed HTTP Methods: HEAD, OPTIONS, GET"
+ OSVDB-3233: /: Found a default page.
...
+ 15 requests: 0 error(s) and 5 item(s) reported on remote host
+ End Time:           ...
---------------------------------------------------------------------------
+ 1 host(s) tested

The key takeaway is that the scan runs successfully, whereas a scan without the header would be blocked by the application.

Verify the header is being sent using a proxy tool

In this step, you will verify that Nikto is actually sending the custom header with its requests. While professional tools like Burp Suite or OWASP ZAP are typically used for this, we can simulate a proxy with a simple netcat (nc) listener.

First, you need to open a second terminal. You can do this by clicking the "+" icon in the terminal panel's tab bar.

In the new terminal tab, start a netcat listener on a port, for example, 8888. This listener will simply print any data it receives.

nc -l -p 8888

Now, switch back to your original terminal tab. Run the Nikto scan again, but this time, point it to your netcat listener instead of the actual web server. This will cause Nikto to send its HTTP request to netcat, allowing us to inspect it.

nikto -h http://127.0.0.1:8888 -addheaders "X-LabEx-Auth: SecretToken"

After running the command, quickly switch back to the second terminal tab where netcat is running. You will see the raw HTTP request sent by Nikto. Look for the X-LabEx-Auth: SecretToken header in the output.

GET / HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.00 (Nikto/2.5.0) (Evasions:None) (Test:000001)
X-LabEx-Auth: SecretToken
Accept-Encoding: gzip,deflate
Connection: close

As you can see, the custom header is included in the request. This confirms that the -addheaders option is working as expected.

You can now stop the netcat listener by pressing Ctrl+C in the second terminal tab and then close the tab.

Test for vulnerabilities that require specific headers

In this step, you will understand the practical security implication of using custom headers by comparing scans with and without the header.

Many vulnerabilities, such as insecure direct object references (IDOR) or privilege escalation flaws, only exist in authenticated sections of an application. A scan that doesn't provide the correct authentication header will completely miss these issues.

To illustrate this, first, run a Nikto scan against the web server without the custom header. This simulates a scan by an unauthenticated attacker.

nikto -h http://127.0.0.1:8000

Nikto will run, but every request it sends will be met with an "Access Denied" response. The scanner cannot properly analyze the application because it cannot get past the initial authorization check. The results of such a scan are of limited value.

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: Werkzeug/2.0.1 Python/3.10.6
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ "Allowed HTTP Methods: GET, HEAD, OPTIONS"
+ OSVDB-3233: /: The site returned a 403 Forbidden, this may indicate that it's a default file.
...

By comparing this with the successful scan you ran in Step 3 (which used the header), you can see the difference. The scan with the custom header was able to interact with the application's core logic (as indicated by the "Welcome" message we saw with curl) and perform meaningful tests. The scan without the header was stopped at the front door.

This highlights the importance of using custom headers to ensure your vulnerability scans are as comprehensive as possible.

Summary

In this lab, you have learned a crucial technique for performing effective web application security assessments with Nikto.

You successfully:

• Identified an application's requirement for a custom HTTP header using curl.
• Learned the syntax for Nikto's -addheaders option.
• Performed a Nikto scan that included a custom header to gain authorized access.
• Verified that the custom header was being sent correctly using a netcat listener.
• Understood how scanning with custom headers can uncover vulnerabilities that would otherwise be missed.

This skill is essential for any security professional, as it enables more thorough testing of modern, complex web applications that rely on headers for authentication, state management, and other functions.