Let's perform web application scanning using Nikto:

1. The syntax and usage complexity associated with running Nikto largely depends on the nature of the application that it is being run against. To see an overview of the usage and syntax of this tool, use the nikto -help command.
2. In the first example provided, a scan is performed against google.com. The -host argument can be used to specify the hostname value of the target to be scanned. The -port option defines the port that the web service is running on. The -ssl option instructs Nikto to establish an SSL/TLS session with the target web server before scanning, as follows:

3. Alternatively, the -host argument can also be used to define the IP address value for the target system to be scanned. The -nossl argument can be used to instruct Nikto to not use any transport-layer security.
4. The -vhost option can be used to specify the value of the host header in HTTP requests. This can be particularly helpful in any case where multiple virtual hostnames are hosted on a single IP address. Have a look at the following example:

5. In the following example, a Nikto scan is performed against the web service hosted on the Metasploitable2 system. The -port argument is not used because the web service is hosted on the TCP port 80, which is the default scan port for Nikto. Additionally, the -nossl argument is not used because by default, Nikto will not attempt an SSL/TLS connection over port 80:

6. The results from the Nikto scan of the Metasploitable2 web service display some of the items that are frequently identified by Nikto. These items include risky HTTP methods, default installation files, exposed directory listings, sensitive information disclosure, and files to which access should be restricted. Awareness of these files can often be useful in looking to gain access to or identifying vulnerabilities on a server.