Use a Proxy for Scanning with Nikto

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.

A proxy, in this context, is an intermediary server that sits between your tool (Nikto) and the target server. Tools like Burp Suite, OWASP ZAP, or mitmproxy are commonly used for this. Routing Nikto's traffic through a proxy is a powerful technique for security professionals. It allows you to see exactly what requests the scanner is sending and what responses it receives. This is invaluable for debugging scans, understanding a scanner's behavior, and even modifying traffic on the fly to bypass security measures.

In this lab, you will learn how to set up a local proxy, configure Nikto to use it, run a scan, and analyze the intercepted traffic. We will use mitmproxy as our proxy and a simple local Python web server as our target.

Set up a local proxy like Burp Suite or OWASP ZAP

In this step, you will start a simple web server to act as our scan target and then start mitmproxy, a lightweight, command-line proxy, to intercept our traffic. All operations will be done in the terminal.

First, let's start a basic Python web server. This server will host a simple index.html file from our current directory, ~/project. We will run it on port 8000 in the background so we can continue using the same terminal.

Execute the following command:

python3 -m http.server 8000 &

The & at the end of the command runs the process in the background. You should see an output indicating the process ID.

Next, let's start our proxy. We will use mitmweb, which is the web-based interface for mitmproxy. This provides a user-friendly way to view the captured traffic. It listens for proxy traffic on port 8080 by default and serves its web interface on port 8081.

Run the following command to start mitmweb, also in the background:

mitmweb --web-host 0.0.0.0 &

You will see some output as mitmweb starts up. Now you have a target server running on port 8000 and a proxy running on port 8080. You can view the proxy's traffic by opening a browser in the lab environment and navigating to http://127.0.0.1:8081. For now, it will be empty.

Configure Nikto to use the proxy with -useproxy

In this step, you will learn how to instruct Nikto to send its traffic through the mitmproxy instance we just started. Nikto has a dedicated command-line option, -useproxy, for this purpose.

The syntax for this option is -useproxy http://<proxy_host>:<proxy_port>. Since our mitmproxy is running on the local machine (127.0.0.1) on port 8080, the correct URL will be http://127.0.0.1:8080.

Before running a full scan, let's perform a simple test to ensure Nikto can connect to the target server through the proxy. We will use the -Plugins '@@NONE' option, which tells Nikto to connect and print the server banner but not run any vulnerability tests. This is a quick and effective way to verify our proxy configuration.

Execute the following command in your terminal:

nikto -h 127.0.0.1 -p 8000 -useproxy http://127.0.0.1:8080 -Plugins '@@NONE'

You should see output similar to this, showing Nikto's banner and information about the target server:

- Nikto v2.x.x
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: SimpleHTTP/0.6 Python/3.10.6
+ END TIME:           ...
---------------------------------------------------------------------------
+ 1 host(s) tested

Now, if you check the mitmweb interface in your browser at http://127.0.0.1:8081, you will see the first request captured from Nikto. This confirms that the proxy configuration is working correctly.

Run a scan directed through the configured proxy

In this step, with the proxy configuration verified, you will now perform an actual vulnerability scan with Nikto. This will generate a significant amount of traffic, all of which will be routed through and logged by mitmproxy.

To keep the scan time reasonable for this lab, we will use the -Tuning 1 option. The tuning option in Nikto controls the types of tests performed. -Tuning 1 focuses on "Interesting File / Seen in Log" checks, which is a good starting point.

Execute the following command to start the scan:

nikto -h 127.0.0.1 -p 8000 -useproxy http://127.0.0.1:8080 -Tuning 1

Nikto will now begin scanning the target server. You will see its progress and any findings directly in your terminal. The output might look something like this, depending on the findings:

- Nikto v2.x.x
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: SimpleHTTP/0.6 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
...
+ /: The server returns the following message when a request for a non-existent page is made: b'<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"\n        "http://www.w3.org/TR/html4/strict.dtd">\n<html>\n    <head>\n        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">\n        <title>Error response</title>\n    </head>\n    <body>\n        <h1>Error response</h1>\n        <p>Error code: 404.</p>\n        <p>Message: File not found.</p>\n        <p>Error code explanation: 404 - Nothing matches the given URI.</p>\n    </body>\n</html>'
...
+ END TIME:           ...
---------------------------------------------------------------------------
+ 1 host(s) tested

While the scan is running, you can switch to the mitmweb browser tab and watch the requests appear in real-time.

Observe the Nikto traffic in the proxy's HTTP history

In this step, you will focus on analyzing the traffic captured by mitmproxy. This is where the real value of using a proxy becomes clear. No new commands are needed for this step; you will use the mitmweb interface in your browser.

Navigate to the browser tab running mitmweb at http://127.0.0.1:8081. You should see a long list of web requests. Each entry in this list is a specific test that Nikto performed against the target server.

Click on any of the requests in the list on the left. The right panel will update to show the details of that specific request and its corresponding response.

Explore the interface:

Request Tab: Here you can see the exact HTTP request sent by Nikto. Pay attention to:
- The request line (e.g., GET /some/test/file.html HTTP/1.1).
- The Host header, which points to our target server.
- The User-Agent header, which will identify the client as Nikto.
Response Tab: This tab shows the server's full reply. You can see the HTTP status code (e.g., 200 OK or 404 Not Found), response headers, and the response body.

Take a few minutes to click through different requests. You'll see Nikto trying to access common administrative directories (like /admin/), checking for backup files (like /index.html.bak), and performing other standard checks. By observing this traffic, you gain a deep understanding of how a vulnerability scanner operates.

Analyze how the proxy affects the scan results

In this step, you will analyze how using a proxy can potentially affect a scan. To do this, you need a baseline for comparison. You will run the same Nikto scan again, but this time without the proxy.

Execute the same scan command as in Step 3, but omit the -useproxy option:

nikto -h 127.0.0.1 -p 8000 -Tuning 1

Observe the output in your terminal. Now, compare the results of this scan with the results from the proxied scan in Step 3. In our simple lab environment, with no firewalls or other security systems in place, the results should be identical.

So, what is the point of the proxy?

Visibility (Debugging): As you saw in the previous step, the primary benefit is visibility. If a scan was failing or producing unexpected results, the proxy would be the first place to look to understand what's going wrong. You can see the raw requests and responses, which is crucial for troubleshooting.
Performance: A proxy adds an extra "hop" for the network traffic, which can introduce a small amount of latency. For very large scans, this could slightly increase the total scan time.
Modification (Advanced): Advanced proxies can be configured to modify traffic. For example, you could set up a rule to automatically change the User-Agent from "Nikto" to a common browser string. This could be used to evade a simple Web Application Firewall (WAF) that blocks requests based on the Nikto user agent. While we are not performing modification in this lab, understanding this capability is key.

In summary, for this lab, the proxy's main effect was to give you a "man-in-the-middle" view into the scanning process, which is a fundamental skill for security testing.

Summary

In this lab, you have successfully learned how to leverage a proxy while performing a web vulnerability scan with Nikto.

You started by setting up the necessary environment, including a simple Python web server as a target and mitmproxy as your interception proxy. You then learned to use Nikto's -useproxy command-line option to route all of its scanning traffic through the proxy.

By running a scan and observing the traffic in the mitmweb interface, you gained direct insight into the types of requests Nikto sends and the responses it receives. Finally, by running a comparative scan without the proxy, you analyzed how a proxy can affect a scan, concluding that its primary role in this context is to provide critical visibility for analysis and debugging. This is a foundational technique used by security professionals to better understand and control their testing tools.