The first invocation in Example 6-11 uses HTTP Basic authentication. Nikto will send your user ID and password, with a colon between them, in the headers of every request. For example, if the user ID is testuser and the password is testpw123, then Nikto will take the string testuser:testpw123, encode it with Base 64 (see Chapter 4), and then transmit it as part of the headers on every request. Even if some of the web pages do not require authentication, Nikto will be sending this authentication every time.
The second invocation in Example 6-11 uses NTLM authentication, so you need to know what "realm" the user ID is in.
Generally this a specific Active Directory domain. Nikto realizes that you want to use this kind of authentication if it sees two colons in the -id parameter. Again, Nikto will send this authentication information with every single request, whether it is required or not.
This is not exactly how web browsers do authentication. In a normal interaction between a web browser and a web server, the web browser first requests the web page without authentication. If the page is not supposed to be viewed without authenticating first, the web server returns a 400-series error code (typically 401, "Authentication Required").
The web browser then prompts the user for the user ID and password. After the user types the user ID and password into their web browser, the browser sends the same request, but with the authentication parameters. If the user ID and password are acceptable, then the server returns the actual web page. With Nikto supplying the credentials on every request, you will not see the 401 error followed by a 200 "OK" response. You will simply see the correct web page. For purposes of testing, this is usually acceptable, although it does not precisely mimic the normal browser-server interaction.
Recipe 6.12. Start Nikto at a Specific Starting Point 6.12.1. Problem
If your application is hosted on a server that runs many other applications, you may want to stop Nikto from probing too far and wide. Sometimes it is simply that the root URL does not lead to the application you want to test, and there is no link from the root to your application. Nikto also cannot follow JavaScript commands that might cause a web browser to visit different pages. You may have to determine the pages that your web browser is visiting, and then tell Nikto to visit there directly.
6.12.2. Solution
nikto.pl -output myhost.html -Format HTM \
-host www.example.com -port 80 -root /servlet/myapp.jsp 6.12.3. Discussion
This example makes Nikto start at http://www.example.com/servlet/myapp.jsp. It won't probe URLs like
http://www.example.com/servlet/ or http://www.example.com/. Although this may be what you want, remember that vulnerabilities in other parts of the site can create security concerns for your application.
Recipe 6.13. Using a Specific Session Cookie with Nikto 6.13.1. Problem
Often times modern applications have somewhat complex login processes that Nikto cannot duplicate. If it is important for Nikto to be logged in when it does its scan, but your web application uses a complex authentication process, you will need another way to ensure that Nikto is logged in. In this case, we will get a session cookie through one of our various ways of monitoring a session (see Recipes Section 11.1 and Section 11.2 for examples). Given that cookie, we'll give it to Nikto so that it can be logged in. It's probably worth it to start Nikto off at a page deeper in the application (rather than the main page), since we're already logged in.
6.13.2. Solution
nikto.pl -output myhost.html -g -C all -Format HTM \ -host www.example.com \
-port 80 -root /webapp1/homepage.aspx -config static.txt
The contents of static.txt need to have (at a minimum) the following line:
STATIC-COOKIE=PHPSESSID=1585007b4ef2c61591e3f7dc10eb8133 6.13.3. Discussion
This is an example of functionality that can only be enabled using Nikto's configuration file. No command-line argument is equivalent. The example cookie is named PHPSESSID (a common value for PHP-based web applications).
You can have much longer cookie values, if necessary. You simply copy and paste the entire cookie value that you observe in TamperData (or WebScarab or any other mechanism) into your configuration file.
Note that Nikto does lots of nasty stuff when probing. This could invalidate your session. You could discover that, after the first 4 or 5 requests, Nikto's session has been terminated, and it's no longer logged in. You might have to pay close attention and try to limit what it's testing.
Another trick to look out for is capturing your cookie on one system and running Nikto on another. Many web applications use your IP address as part of the session state. It might be in the cookie, or it might be something silently stored on the server and associated with your cookie. If you capture the cookie on one system and Nikto connects from a different IP address with that same cookie, the server might simply invalidate your session because the cookie moved from one IP address to another. Nikto won't see the logged-in results because the session will be invalid. One way to test whether Nikto is getting correct results is the following sequence of actions:
Log in on the application to test.
1.
Capture the session ID, cookie, or other authenticator (use WebScarab, EditCookies, or TamperData to get the session information).
2.
Configure Nikto according to this recipe and start it running.
3.
While Nikto is running, go back to your web browser and try to view pages that require a valid session.
4.
If your web browser can still view the pages that require authentication, then Nikto probably can, too. It at least means that Nikto's activities have not invalidated your web session, which is a good sign.
Recipe 6.14. Testing Web Services with WSFuzzer 6.14.1. Problem
You have a web service you need to test, and you want to generate a lot of automatic malicious input to it. As with other recipes in this chapter, you want to launch these tests automatically so that you get lots of coverage.
6.14.2. Solution
Fuzz testing is a class of testing that involves both randomly and strategically changing parameters in a protocol or other structured communication (for example, an image file). Wikipedia's article on fuzz testing
(http://en.wikipedia.org/wiki/Fuzz_testing) is a good introduction to the concepts. WSFuzzer is a project from the Open Web Application Security Project (OWASP), like WebScarab, WebGoat, and several others. It can be downloaded from http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project. The goal of WSFuzzer is to automate the fuzzing of parameters in web services communications.
In many cases, you can just point it to your WSDL file, and it will figure out how to test the web service. In some cases, you must give it an XML file that defines the SOAP structure for the service. Since this second case is more involved, it is the one we will show.
Prepare an XML file like the one shown in Example 6-12. Notice that all the parameters have been replaced with %s where they previously may have said int or string. Those %s tokens show the fuzzer where to insert its fuzzed arguments.
<DocCode>%s</DocCode>
<SearchQuery>%s</SearchQuery>
<MaxHits>%s</MaxHits>
</GetInfo>
</soap:Body>
</soap:Envelope>
WSFuzzer is very chatty and will prompt you with many questions about what you want to do. For example, it will ask about where you want to store the results file, what attack file you want to use, and whether you want it to
automatically fuzz. Example 6-13 shows a typical conversation when you run WSFuzzer. A few lines have been omitted for brevity.
Example 6-13. WSFuzzer questions at start up