Einführung
Webtests beginnen mit dem Verständnis normalen HTTP-Verhaltens. Eine erfolgreiche Verbindung, ein Statuscode, Antwortmetadaten und Seiteninhalt liefern jeweils einen anderen Teil des Bildes.
Dieses Lab stellt einen lokalen Webdienst bereit, damit du GET- und HEAD-Anfragen mit curl untersuchen kannst. Du liest seine Antworten und bewahrst nützliche Header und Inhalte ohne Verzeichnisraten, Injektion oder Authentifizierungsumgehung.
Eine HTTP-Ressource und ihren Status lesen
In diesem Schritt prüfst du mit curl eine lokale HTTP-Ressource und unterscheidest Anwendungsstatus von Verbindungserfolg.
Öffne Kali und wähle den gemeinsamen Arbeitsbereich:
kali
cd /home/labex/project
Eine URL wie http://127.0.0.1:8080/scope.txt bezeichnet Schema (http), Host (127.0.0.1), optionalen Port (8080) und Pfad (/scope.txt). Host und Port wählen den Dienst; der Pfad wählt eine Ressource darin.
Curl stellt Anfragen an URLs. Seine Standard-HTTP-Methode ist GET, die eine Repräsentation einer Ressource anfordert. Fordere die Übungsseite an:
curl http://127.0.0.1:8080/
Der Antwortkörper ist eine HTML-Seite mit dem Titel Kali Training Welcome. Curl gibt den Körper als Text aus; es stellt die Seite nicht wie ein Webbrowser dar.
Die Option -i nimmt Antwortheader in die Anzeige auf. Prüfe die Umfangsressource:
curl -i http://127.0.0.1:8080/scope.txt
Die Statuszeile meldet 200 OK, gefolgt von Headern, einer Leerzeile und dem Körper Authorized local training only. HTTP-Header beschreiben die Antwort; der Körper trägt ihren Inhalt.
Fordere einen Pfad an, den der bereitgestellte Server nicht anbietet:
curl -i http://127.0.0.1:8080/missing
Das liefert 404 Not Found mit kurzem Körper. TCP-Verbindung und HTTP-Austausch waren dennoch erfolgreich; die Anwendung meldet, dass die angeforderte Ressource fehlt. Curl kann ohne Option zum Fehlschlagen bei Fehlerstatus bei HTTP 404 erfolgreich enden. Lies deshalb den Antwortstatus, statt jede abgeschlossene Anfrage als gültige Ressource anzusehen.
-o schreibt den Körper in eine benannte Datei. -s verbirgt die Fortschrittsanzeige, während -S bei fehlgeschlagener Übertragung weiter Fehler zeigt; kombiniert werden sie zu -sS. Speichere den Umfangstext:
curl -sS -o scope.txt http://127.0.0.1:8080/scope.txt
cat scope.txt
Erwartete Ausgabe:
Authorized local training only.
Du hast den Antwortkörper gespeichert statt einer handgeschriebenen Beschreibung.
Antwortheader getrennt vom Körper speichern
In diesem Schritt vergleichst du GET und HEAD und bewahrst Serverheader und Seite als separate Artefakte.
Die Option -I (großes I) lässt curl eine HEAD-Anfrage senden. HEAD fordert Antwortmetadaten ohne Übertragung des Ressourcenkörpers an:
curl -I http://127.0.0.1:8080/
Achte auf 200 OK, Content-Type: text/html und den Übungsseitenheader. Die Antwort enthält keinen HTML-Körper. Ein Content-Length-Header kann dennoch beschreiben, wie groß der entsprechende GET-Körper wäre.
Verwende GET für tatsächlichen Inhalt. Curls Option -D schreibt Antwortheader in den folgenden Dateinamen, -o den Körper in eine andere Datei:
curl -sS -D response-headers.txt -o page.html http://127.0.0.1:8080/
Lies die gespeicherten Metadaten:
cat response-headers.txt
Sie sollten einen erfolgreichen Status, HTML-Inhaltstyp und X-Training-Site: guided-web enthalten. Server- und Datumsfelder können variieren.
Lies den Körper separat:
cat page.html
Erwarteter Inhalt:
<html><title>Kali Training Welcome</title><body>Local practice site.</body></html>
Header und Körper beantworten unterschiedliche Fragen: Erstere beschreiben die Serverantwort, Letzterer enthält die angeforderte Ressource. Ihre Trennung erleichtert spätere Vergleiche und Textverarbeitung.
Zusammenfassung
Du hast URL-Bestandteile interpretiert, GET- und HEAD-Anfragen gestellt, HTTP-Status von Verbindungserfolg unterschieden und Header sowie Körper geprüft. Du hast ursprüngliche Antwortmetadaten und Seiteninhalt separat für spätere Analysen gespeichert.
