Benutzerdefinierte Header zu Nikto-Scans hinzufügen | Web-Sicherheit

Einleitung

Nikto ist ein beliebter Open-Source-Webserver-Scanner, der umfassende Tests gegen Webserver für mehrere Elemente durchführt, darunter über 6700 potenziell gefährliche Dateien/Programme, Prüfungen auf veraltete Versionen von über 1250 Servern und versionsspezifische Probleme auf über 270 Servern.

Manchmal erfordert eine Webanwendung, dass ein bestimmter HTTP-Header in Anfragen vorhanden ist. Dies kann zur Authentifizierung (wie ein API-Schlüssel oder ein Sitzungstoken), zum Routing zu einer bestimmten Version einer Anwendung oder zur Aktivierung eines Debug-Modus dienen. Standardmäßige Nikto-Scans würden in diesen Szenarien fehlschlagen oder unvollständig sein, da ihnen der erforderliche Header fehlen würde.

In diesem Lab lernen Sie, wie Sie die Option -addheaders von Nikto verwenden, um benutzerdefinierte Header in Ihre Scans einzufügen. Dies ermöglicht es Ihnen, Anwendungen zu testen, die spezifische Header-Anforderungen haben, und gewährleistet so eine gründlichere und genauere Sicherheitsbewertung.

Identifizieren eines benutzerdefinierten HTTP-Headers, der von einer Anwendung benötigt wird

In diesem Schritt interagieren Sie mit einer einfachen Webanwendung, um zu verstehen, warum ein benutzerdefinierter Header erforderlich sein könnte. Wir haben einen Webserver, der auf Port 8000 läuft und für den Zugriff einen spezifischen Header, X-LabEx-Auth, benötigt.

Versuchen wir zunächst, auf die Webanwendung ohne den benutzerdefinierten Header zuzugreifen, indem wir den Befehl curl verwenden.

curl http://127.0.0.1:8000

Sie erhalten die Meldung "Access Denied", da der erforderliche Header fehlt.

Access Denied

Senden wir die Anfrage nun erneut, aber diesmal fügen wir den erforderlichen benutzerdefinierten Header mit der Option -H in curl hinzu. Der Header ist X-LabEx-Auth mit dem Wert SecretToken.

curl -H "X-LabEx-Auth: SecretToken" http://127.0.0.1:8000

Dieses Mal gewährt der Server den Zugriff und gibt eine Willkommensnachricht zurück. Dies bestätigt, dass die Anwendung diesen spezifischen Header prüft.

Welcome, authorized user! The server is Apache/2.4.1 (Unix).

Dieser Prozess zeigt, wie Sie die Notwendigkeit eines benutzerdefinierten Headers identifizieren und bestätigen, bevor Sie einen Sicherheits-Scan durchführen.

Verwenden der Option -addheaders zur Angabe von Header und Wert

In diesem Schritt lernen Sie die Nikto-Option kennen, mit der benutzerdefinierte Header zu seinen Scans hinzugefügt werden.

Da wir nun wissen, dass ein benutzerdefinierter Header erforderlich ist, müssen wir Nikto anweisen, diesen in alle seine HTTP-Anfragen einzufügen. Nikto bietet zu diesem Zweck die Option -addheaders.

Die Syntax ist unkompliziert:

-addheaders "HeaderName:HeaderValue"

Sie ersetzen HeaderName durch den Namen des Headers (z. B. X-LabEx-Auth) und HeaderValue durch seinen entsprechenden Wert (z. B. SecretToken).

Wenn Sie mehrere benutzerdefinierte Header hinzufügen müssen, können Sie diese durch ein Zeilenumbruchzeichen (\n) trennen. Zum Beispiel:

-addheaders "Header1:Value1\nHeader2:Value2"

Für unser aktuelles Szenario würde die vollständige Nikto-Befehlsstruktur zum Scannen der Zielanwendung wie folgt aussehen. Beachten Sie, dass wir den Befehl in diesem Schritt nicht ausführen; wir erstellen ihn nur, um die Syntax zu verstehen.

nikto -h http://127.0.0.1:8000 -addheaders "X-LabEx-Auth: SecretToken"

Dieser Befehl weist Nikto an, den Host unter http://127.0.0.1:8000 anzuvisieren und den Header X-LabEx-Auth: SecretToken zu jeder Anfrage hinzuzufügen, die es während des Scans sendet.

Ausführen eines Scans mit dem benutzerdefinierten Header

In diesem Schritt führen Sie einen Nikto-Scan mit der Option -addheaders aus, die Sie gerade kennengelernt haben.

Nachdem der richtige Befehl erstellt wurde, ist es an der Zeit, den Scan auszuführen. Dadurch kann Nikto mit der Anwendung als autorisierter Benutzer interagieren und möglicherweise Schwachstellen aufdecken, die für nicht authentifizierte Benutzer nicht sichtbar sind.

Führen Sie den folgenden Befehl in Ihrem Terminal aus:

nikto -h http://127.0.0.1:8000 -addheaders "X-LabEx-Auth: SecretToken"

Nikto beginnt nun mit dem Scan. Da jede Anfrage den Header X-LabEx-Auth: SecretToken enthält, wird die Webanwendung diese erfolgreich verarbeiten. Beobachten Sie die Ausgabe von Nikto. Es wird den Server identifizieren und mit dem Testen auf verschiedene Schwachstellen beginnen.

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: Werkzeug/2.0.1 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
+ No CGI directories found (use '-C all' to force check all possible dirs)
+ "Allowed HTTP Methods: HEAD, OPTIONS, GET"
+ OSVDB-3233: /: Found a default page.
...
+ 15 requests: 0 error(s) and 5 item(s) reported on remote host
+ End Time:           ...
---------------------------------------------------------------------------
+ 1 host(s) tested

Die wichtigste Erkenntnis ist, dass der Scan erfolgreich ausgeführt wird, während ein Scan ohne den Header von der Anwendung blockiert würde.

Überprüfen, ob der Header mit einem Proxy-Tool gesendet wird

In diesem Schritt überprüfen Sie, ob Nikto den benutzerdefinierten Header tatsächlich mit seinen Anfragen sendet. Während professionelle Tools wie Burp Suite oder OWASP ZAP typischerweise dafür verwendet werden, können wir einen Proxy mit einem einfachen netcat (nc) Listener simulieren.

Zuerst müssen Sie ein zweites Terminal öffnen. Dies können Sie tun, indem Sie auf das "+" Symbol in der Registerkartenleiste des Terminal-Panels klicken.

Starten Sie im neuen Terminal-Tab einen netcat-Listener auf einem Port, z. B. 8888. Dieser Listener gibt einfach alle empfangenen Daten aus.

nc -l -p 8888

Wechseln Sie nun zurück zu Ihrem ursprünglichen Terminal-Tab. Führen Sie den Nikto-Scan erneut aus, aber diesmal leiten Sie ihn zu Ihrem netcat-Listener anstatt zum eigentlichen Webserver. Dadurch sendet Nikto seine HTTP-Anfrage an netcat, was uns die Inspektion ermöglicht.

nikto -h http://127.0.0.1:8888 -addheaders "X-LabEx-Auth: SecretToken"

Nachdem Sie den Befehl ausgeführt haben, wechseln Sie schnell zurück zum zweiten Terminal-Tab, auf dem netcat läuft. Sie sehen die von Nikto gesendete rohe HTTP-Anfrage. Suchen Sie in der Ausgabe nach dem Header X-LabEx-Auth: SecretToken.

GET / HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.00 (Nikto/2.5.0) (Evasions:None) (Test:000001)
X-LabEx-Auth: SecretToken
Accept-Encoding: gzip,deflate
Connection: close

Wie Sie sehen können, ist der benutzerdefinierte Header in der Anfrage enthalten. Dies bestätigt, dass die Option -addheaders wie erwartet funktioniert.

Sie können den netcat-Listener nun stoppen, indem Sie im zweiten Terminal-Tab Strg+C drücken, und dann den Tab schließen.

Testen auf Schwachstellen, die spezifische Header erfordern

In diesem Schritt lernen Sie die praktische Sicherheitsauswirkung der Verwendung benutzerdefinierter Header kennen, indem Sie Scans mit und ohne den Header vergleichen.

Viele Schwachstellen, wie z. B. Insecure Direct Object References (IDOR) oder Privilege Escalation-Fehler, existieren nur in authentifizierten Bereichen einer Anwendung. Ein Scan, der nicht den richtigen Authentifizierungsheader bereitstellt, wird diese Probleme vollständig übersehen.

Um dies zu veranschaulichen, führen Sie zunächst einen Nikto-Scan gegen den Webserver ohne den benutzerdefinierten Header aus. Dies simuliert einen Scan durch einen nicht authentifizierten Angreifer.

nikto -h http://127.0.0.1:8000

Nikto wird ausgeführt, aber jede von ihm gesendete Anfrage wird mit einer "Access Denied"-Antwort beantwortet. Der Scanner kann die Anwendung nicht richtig analysieren, da er die anfängliche Autorisierungsprüfung nicht bestehen kann. Die Ergebnisse eines solchen Scans sind von begrenztem Wert.

- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         ...
---------------------------------------------------------------------------
+ Server: Werkzeug/2.0.1 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
+ "Allowed HTTP Methods: GET, HEAD, OPTIONS"
+ OSVDB-3233: /: The site returned a 403 Forbidden, this may indicate that it's a default file.
...

Wenn Sie dies mit dem erfolgreichen Scan aus Schritt 3 (der den Header verwendete) vergleichen, können Sie den Unterschied erkennen. Der Scan mit dem benutzerdefinierten Header konnte mit der Kernlogik der Anwendung interagieren (wie durch die "Welcome"-Nachricht angezeigt, die wir mit curl gesehen haben) und aussagekräftige Tests durchführen. Der Scan ohne den Header wurde an der Eingangstür gestoppt.

Dies unterstreicht die Bedeutung der Verwendung benutzerdefinierter Header, um sicherzustellen, dass Ihre Schwachstellenscans so umfassend wie möglich sind.

Zusammenfassung

In diesem Lab haben Sie eine entscheidende Technik für effektive Sicherheitsbewertungen von Webanwendungen mit Nikto gelernt.

Sie haben erfolgreich:

Den Bedarf einer Anwendung an einem benutzerdefinierten HTTP-Header mit curl identifiziert.
Die Syntax für Nikto's -addheaders-Option gelernt.
Einen Nikto-Scan durchgeführt, der einen benutzerdefinierten Header enthielt, um autorisierten Zugriff zu erhalten.
Überprüft, ob der benutzerdefinierte Header korrekt gesendet wurde, indem ein netcat-Listener verwendet wurde.
Verstanden, wie Scans mit benutzerdefinierten Headern Schwachstellen aufdecken können, die sonst übersehen würden.

Diese Fähigkeit ist für jeden Sicherheitsexperten unerlässlich, da sie umfassendere Tests moderner, komplexer Webanwendungen ermöglicht, die für Authentifizierung, Zustandsverwaltung und andere Funktionen auf Header angewiesen sind.