Ravindra BagaleCourses & study guides मराठी Track your progress

20. Vulnerability Scanning and Assessment

20.5 Nikto: Web Server Scanning

By Last updated:

In short: Nikto checks web servers for dangerous files, outdated server software, default pages and missing security headers.

Nikto checks web servers for dangerous files, outdated server software, default pages and missing security headers. It is noisy (not stealthy) but quick – perfect for a first look at the Apache and Nginx servers you built in Chapters 7–9.

nikto -h http://192.168.56.20                          # scan the web server on Metasploitable 2
nikto -h http://192.168.56.20/dvwa/                     # scan one application path
nikto -h 192.168.56.20 -p 80,8180                       # several ports (8180 = Tomcat on Metasploitable 2)
nikto -h http://192.168.56.20 -o nikto_msf2.html -Format htm   # save an HTML report

Typical findings and what they mean:

Nikto says Meaning Fix (from what you learned earlier)
Server version disclosed (Apache/2.2.8) Attacker learns the exact version ServerTokens Prod, ServerSignature Off (Apache); server_tokens off; (Nginx)
Directory indexing found Files in a folder are listed publicly Options -Indexes (Apache); autoindex off; (Nginx)
phpinfo.php found Full PHP configuration exposed Delete test files from the web root
X-Frame-Options / Content-Security-Policy header missing Clickjacking and XSS protection absent Add security headers in the server config
HTTP TRACE method enabled Old cross-site tracing risk TraceEnable off (Apache)

Ravindra Bagale's Tip

Nikto gives many "OSVDB" and "may be" findings – not all of them are real. Confirm each finding yourself in the browser or with curl -I. And importantly: if you left phpinfo.php for testing in the Chapter 16 reels project, remove it now!

Lab

Run Nikto against http://192.168.56.20 and save the HTML report. Pick three findings and confirm each manually with curl -I or the browser. Then run Nikto against your own Apache server from Chapter 8, fix two findings in the config, restart with sudo service httpd restart, and scan again to confirm they are gone.

Turning Nikto findings into fixes

Nikto is noisy and quick. Treat each finding as a homework item for the web server you built in earlier chapters.

Common Nikto finding → fix

Server leaks version

Hide it.

# nginx
server_tokens off;
# Apache
ServerTokens Prod

What you see:

curl -I → Server: nginx
Directory listing enabled

Turn it off.

autoindex off;   # nginx
Options -Indexes  # Apache
Missing security headers

Add them at the web server or the app (helmet, Spring Security, SecurityMiddleware).

add_header X-Content-Type-Options nosniff always;
Outdated package

Patch the OS package or rebuild the image.

Real examples

Indian company (sample): a Zoho-style SaaS team runs Nikto in CI against every staging deploy. A failed job blocks promotion until headers are fixed. Global: OWASP secure headers projects document the same fixes Nikto complains about. Everyday: a shop inspection checklist. You do not argue with "exit light missing". You fit the light.

Recap

  • Nikto finds. Your earlier chapters already taught the fixes.
  • Lab and staging only.

Defender's worksheet (do this today)

  1. Write the lesson title and date in your notebook.
  2. List three systems you own (VMs, personal projects, or lab apps) where this lesson applies.
  3. Run one safe command or checklist item from the lesson on a lab system only.
  4. Paste the command and its output under an Evidence heading.
  5. Write one fix you would give a teammate in two sentences.
  6. Write one mistake students make with this topic and how to avoid it.

More real-world pictures

Indian workplace (sample data)

Suppose we are a junior analyst at Tech Mahindra supporting a client SOC. After reading this lesson you add one detection or one hardening item to the team weekly checklist, with the owner name and a due date. That is how learning becomes operations.

Global practice

Public bodies such as CERT-In (India), CISA (US) and NCSC (UK) publish advisories that map to the same ideas: patch, least privilege, logging and user awareness. Bookmark one advisory feed and read it every Monday.

Home and family

Explain this lesson to a family member in four sentences without jargon. If they can repeat the main warning back to you, you understand it well enough to teach.

Connect to earlier chapters

Parts 1 to 9 built Linux, web servers, databases and cloud pieces. This lesson only makes sense when you can point to a concrete config file, package name or architecture box from those parts. If you cannot, revisit the matching earlier chapter before you practise any tool command.

Common mistakes

  • Skipping written permission just for a quick scan.
  • Practising on hostel or office Wi-Fi targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying exploit commands onto production to verify. Verification for defenders means checking versions and patches, not firing modules.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Teach one other person the warning from this lesson.