Fingerprinting Server Software

Overview

Version disclosure is the cheapest recon an attacker buys. A single GET request returns the Server: header, the X-Powered-By: header, and any framework-default cookies. From those three signals the attacker derives: web server family + exact version, app-framework + version, language runtime + version. That maps directly to a CVE catalog query: every published CVE affecting any of those components, filtered to ones an unauthenticated attacker can trigger.

The fix is operationally trivial (one line in nginx, one line in Apache, one line in IIS) but the discipline isn't universal. This skill enumerates the signals + reports each disclosure with the severity matching how much it enables follow-on attack.

When the skill produces findings

Finding	Severity	Threshold	Affected control
Server header discloses version	MEDIUM	Server: nginx/1.18.0 or similar with explicit version	CWE-200
Server header discloses minor version	LOW	Server: nginx (no version)	CWE-200
X-Powered-By discloses framework version	MEDIUM	X-Powered-By: PHP/7.4.21, Express, ASP.NET	CWE-200
X-AspNet-Version present	HIGH	Specific dotnet runtime version	CWE-200
X-Runtime / X-Rails / X-Django headers present	LOW	Framework identification, no version	CWE-200
X-Generator: drupal/wordpress + version	MEDIUM	CMS family + version disclosure	CWE-200
Via header discloses proxy chain	LOW	Reveals upstream architecture (Varnish, Squid, CloudFront)	CWE-200
Framework-default Set-Cookie pattern	LOW	PHPSESSID, JSESSIONID, connect.sid, etc.	CWE-200
Error page reveals stack trace	HIGH	5xx response body contains source file paths or framework banner	CWE-209
HTTP/2 server-push fingerprint	LOW	HTTP/2 :server pseudo-header with version	CWE-200
ETag format identifies cluster member	LOW	Apache-style hex ETags reveal node	CWE-200

Prerequisites

• Python 3.9+ with requests
• Authorization for non-local targets

Instructions

Step 1 — Confirm Authorization

"Do you have authorization to perform server-fingerprinting probes on
 this target? I need confirmation before proceeding."

Step 2 — Run the scanner

python3 ${CLAUDE_PLUGIN_ROOT}/skills/fingerprinting-server-software/scripts/fingerprint_server.py \
    https://target.example.com \
    --authorized

Options:

Usage: fingerprint_server.py URL [OPTIONS]

Options:
  --authorized       Attest authorization (required for non-local)
  --output FILE      Write findings to FILE
  --format FMT       json | jsonl | markdown (default: markdown)
  --min-severity SEV (default: info)
  --timeout SECS     Per-probe timeout (default: 10)
  --trigger-error    Send a malformed request to surface error-page disclosure
                     (off by default — some WAFs block on this)

The scanner sends a baseline GET + an OPTIONS + (optionally) a malformed request to surface error-page disclosure. For each response, it parses the standard fingerprinting headers and classifies each match against the threshold table above.

Step 3 — Interpret findings

The vast majority of findings will be MEDIUM or LOW. CWE-200 is by itself rarely a critical vulnerability — it's a recon enabler.

The exception: error-page stack-trace disclosure (CWE-209) is HIGH because production error pages should never leak server-internal paths or framework banners. If the error page reveals /home/app/src/handlers/auth.py, the attacker now knows the source layout AND that the language is Python.

Step 4 — Cross-skill chaining

After this skill, suggest:

• detecting-debug-endpoints (#7) — fingerprinted framework points to which debug endpoints to probe (e.g., Server: nginx → check /nginx_status; X-Powered-By: Spring → check /actuator/*).
• detecting-exposed-secrets-files (#6) — framework fingerprint informs which CI / IDE / build-tool configs to probe for.

Examples

Example 1 — Post-deploy version-disclosure audit

User: "Make sure we're not leaking nginx version on prod."

python3 ${CLAUDE_PLUGIN_ROOT}/skills/fingerprinting-server-software/scripts/fingerprint_server.py \
    https://app.example.com --authorized --min-severity medium

Expected on a properly-configured host: zero findings of medium+.

Example 2 — Tech-stack identification on an unknown target

User: "Bug bounty submission. We don't know what stack this runs. What's the surface?"

python3 ${CLAUDE_PLUGIN_ROOT}/skills/fingerprinting-server-software/scripts/fingerprint_server.py \
    https://target.example.com --authorized --format markdown

Use the output to inform which subsequent skills to chain (debug- endpoint probe, secrets-file probe).

Example 3 — Error-page exposure check

User: "Audit production error pages for stack-trace disclosure."

python3 ${CLAUDE_PLUGIN_ROOT}/skills/fingerprinting-server-software/scripts/fingerprint_server.py \
    https://app.example.com --authorized --trigger-error --min-severity high

The --trigger-error flag sends a malformed request to provoke a 500. Some WAFs block on this; check with the target's ops team if the result comes back empty.

Output

JSON / JSONL / Markdown. Exit codes: 0 clean, 1 high/critical, 2 error.

Error Handling

• WAF blocks fingerprinting requests → expected on Cloudflare/Imperva targets. The CDN itself is what gets fingerprinted, not the origin.
• Connection error → exit 2.

Resources

• references/THEORY.md — Per-header reasoning: what each disclosure enables, threat-modeling guidance, CVE-lookup workflow
• references/PLAYBOOK.md — Per-server-type remediation snippets (nginx server_tokens, Apache ServerTokens, IIS removeHeader, Express helmet hidePoweredBy, framework-default cookie renaming)
• ../analyzing-tls-config/references/AUTHORIZATION.md — Active-scan authorization pattern