Echte Anmeldungen von irreführenden Antworten unterscheiden

HydraBeginner
Jetzt üben

Einführung

Fieldnote bereitet die Northline Print Fair vor. Aussteller melden sich an, um das Paket ihres eigenen Standes abzurufen: Ankunftszeit, Lieferort und Packliste. Ein erster Hydra-Test scheint mehrere gültige Zugangsdaten zu finden. Einige dieser Funde sind tatsächlich Fehlerseiten. Deine Aufgabe ist, echte Authentifizierung von einer irreführenden Antwort zu unterscheiden und anschließend das vollständige Paket des zugewiesenen Ausstellers abzurufen.

Du brauchst nur grundlegende Terminaleingabe, Pfadkenntnisse und den Wechsel zwischen Tabs. Hydra und das lokale Portal sind vorbereitet. Formularfelder, Suchbedingungen und Cookies werden vor ihrer Verwendung erklärt. Workstation ist dein Terminal, Exhibitor Portal die Website. Das sind zwei Oberflächen desselben isolierten Trainingscontainers, keine zwei Rechner. Alle Konten und Geschäftsdaten sind synthetisch. Teste ausschließlich das angegebene Übungsformular und das zugewiesene Konto mit den bereitgestellten Kandidaten. Verändere weder Server noch Konten oder Dokumente.

Die geschätzten 55 Minuten umfassen Lesen und gewöhnliche Fehler; die Zeit wurde nicht mit Einsteigern gemessen. Deine Ergebnisse sind ein wiederverwendbares Formularargument, ein originales Hydra-Ergebnis und das authentifiziert abgerufene Standpaket, kein schriftlicher Bericht.

Sehen, was eine echte Anmeldung öffnet

In diesem Schritt öffnest du ein nachweislich funktionierendes Vorschaukonto und ordnest es seinen eigenen Standdaten zu. Eine erfolgreiche HTTP-Anfrage bedeutet, dass der Server eine Antwort gesendet hat. Erfolgreiche Authentifizierung bedeutet, dass der Server eine Identität akzeptiert hat. Das sind unterschiedliche Tatsachen.

Öffne den Tab Exhibitor Portal. Wähle Start at the practice desk und dann Practice sign-in. Gib die Aussteller-ID preview und das Passwort Preview24 ein und wähle Sign in. Das Ergebnis zeigt Signed in as preview. Wähle Open your workspace. Der Stand heißt DEMO, und der Packhinweis kennzeichnet das Dokument als Übung. Das ist der normale Geschäftsablauf; dieses Vorschaupaket ist nicht dein endgültiger Auftrag. Wähle Sign out und anschließend den Navigationslink Practice desk.

Bekannter Vorschauarbeitsbereich mit dem Stand DEMO

Aussteller-ID und Stand zeigen, dass dies das Vorschaudokument ist. Der Downloadknopf allein beweist nicht, dass es dein zugewiesenes Paket ist.

Wechsle zu Workstation. Die Befehle dieses Labs beginnen in /home/labex/project/login-review. Die Oberfläche wechselt automatisch in dieses Verzeichnis; pwd zeigt zur Kontrolle das aktuelle Verzeichnis an:

pwd

Erwartet wird /home/labex/project/login-review. Falls du anderswo bist, wechselt cd das Verzeichnis:

cd /home/labex/project/login-review

Das Übungsformular sendet eine POST-Anfrage an /practice/login. Ein POST überträgt benannte Felder im Anfrageinhalt. Hier heißen sie username und password; & trennt sie. curl sendet eine Anfrage aus dem Terminal, unabhängig vom Browser. Im nächsten Befehl liefert --data die Felder, -s blendet die Fortschrittsanzeige aus, -o speichert den Antwortinhalt und -w gibt den HTTP-Status aus. Die einfachen Anführungszeichen halten Leerzeichen, & und %{http_code} für curl zusammen, statt sie von der Shell interpretieren zu lassen.

Sende absichtlich ein falsches Passwort:

curl -s -o wrong.html -w 'HTTP %{http_code}
' --data 'username=preview&password=Wrong24' http://127.0.0.1:8080/practice/login

Die Ausgabe ist HTTP 200. Das bedeutet, dass die Anwendung eine Seite zurückgegeben hat, nicht dass das Passwort funktioniert. wrong.html enthält diese Seite. grep sucht Text; seine Option -o zeigt nur den passenden Text, damit du nicht das umgebende HTML lesen musst:

grep -o 'Incorrect password' wrong.html

Du solltest Incorrect password sehen. Derselbe HTTP-Status kann sowohl einen echten Erfolg als auch eine abgelehnte Anmeldung begleiten. Ein gewöhnlicher Tippfehler im Passwort lässt sich hier beheben: Korrigiere den Wert und sende ihn erneut. Ein Verbindungsfehler bedeutet, dass die Anfrage den Dienst nicht erreicht hat. Prüfe 127.0.0.1, Port 8080 und den angegebenen Pfad, bevor du das Anmeldeergebnis interpretierst. Setze die VM nicht wegen eines Tippfehlers zurück.

Einen irreführenden Fund reproduzieren

In diesem Schritt führst du eine absichtlich fehlerhafte Klassifizierungsregel mit vier kleinen Übungspaaren aus. Dies demonstriert einen schlechten Test und ist keine verlässliche Prüfung.

Bleibe in Workstation. cat zeigt eine Datei an. Die vorbereitete Liste enthält vollständige Paare im Format username:password, eines pro Zeile:

cat practice-pairs.txt
preview:Wrong24
retired:Wrong24
offline:Wrong24
preview:Preview24

retired ist ein synthetisches Beispiel für ein nicht verfügbares Konto. offline ist ein kontrolliertes Dienstfehlerbeispiel: Die Übungsfunktion gibt HTTP 503 zurück, ohne eine Sitzung anzulegen. Es handelt sich nicht um den Ausfall eines vorgeschalteten Dienstes oder einen echten Aussteller. Das letzte Paar ist die bekannte funktionierende Vorschauanmeldung. Behalte diese kleine erlaubte Menge bei und erweitere sie nicht zu beliebigen Kombinationen aus Benutzernamen und Passwörtern.

Hydras Modul http-post-form sendet jedes Paar an ein Formular. Sein Argument besteht aus drei durch Doppelpunkte getrennten Teilen: POST-Pfad, Felder und Antwortbedingung. ^USER^ und ^PASS^ sind Hydra-Platzhalter. F= bedeutet: „Eine Antwort, die dieses Muster enthält, als Fehlschlag behandeln.“ Jede andere Antwort kann als Erfolg eingestuft werden. Dieser Befehl erkennt absichtlich nur Incorrect password und deckt andere Fehlerarten nicht ab.

Die Optionen sind -I, um eine alte Wiederherstellungsabfrage in diesem Arbeitsbereich zu ignorieren, -C für gepaarte Kandidaten, -s für den Port, -t 1 für einen einzelnen Arbeitsprozess, -o für den Ergebnisdateinamen und -b json für die JSON-Ausgabe. Das letzte Argument bleibt durch die Anführungszeichen ein einziges Argument, obwohl es Leerzeichen und & enthält.

hydra -I -C practice-pairs.txt -s 8080 -t 1 -o misleading.json -b json 127.0.0.1 http-post-form '/practice/login:username=^USER^&password=^PASS^:F=Incorrect password'

Um JSON ohne eigenes Programm zu lesen, nutze Pythons eingebauten Formatierer json.tool. python3 -m führt ein installiertes Modul aus:

python3 -m json.tool misleading.json

Lies die Liste results. Das bekannte funktionierende Vorschaupaar erscheint, aber auch ein Paar für das nicht verfügbare Konto oder den Dienstfehler kann auftauchen. Ein Fund ist eine Aussage der Bedingung, kein Beweis für einen authentifizierten Arbeitsbereich. Das übergeordnete Feld success: true beschreibt Hydras Ausführung, nicht die Gültigkeit jedes gemeldeten Passworts. Verwende diese irreführende Datei nicht als endgültiges Prüfergebnis.

Falls Hydra einen Syntax- oder Verbindungsfehler meldet, vergleiche das vollständige Argument samt Anführungszeichen und den Port mit dem obigen Befehl, korrigiere den Tippfehler und wiederhole diesen begrenzten Übungstest. Eine fehlgeschlagene Verbindung beweist weder ein funktionierendes Passwort noch ein gültiges negatives Prüfergebnis.

Mit bekannten Antworten kalibrieren

In diesem Schritt speicherst du eine wiederverwendbare Bedingung, die echte Erfolge akzeptiert und alle drei bekannten Fälle ohne Anmeldungserfolg zurückweist. Bleibe in Workstation. Untersuche zunächst die anderen Antworten mit demselben Anfrageformat.

Die Anfrage für das nicht verfügbare Konto liefert absichtlich HTTP 200:

curl -s -o retired.html -w 'HTTP %{http_code}
' --data 'username=retired&password=Wrong24' http://127.0.0.1:8080/practice/login
grep -o 'Sign-in unavailable' retired.html

Die kontrollierte Dienstfehleranfrage liefert absichtlich HTTP 503. Es gibt keine gültige Sitzung, obwohl die Seite kein Incorrect password enthält:

curl -s -o offline.html -w 'HTTP %{http_code}
' --data 'username=offline&password=Wrong24' http://127.0.0.1:8080/practice/login
grep -o 'Service unavailable' offline.html

Rufe nun die bekannte positive Antwort ab. Diese curl-Anfrage hat ihre eigene Sitzung, getrennt vom Browser:

curl -s -o preview.html --data 'username=preview&password=Preview24' http://127.0.0.1:8080/practice/login
grep -o 'Signed in as preview' preview.html

Signed in as kennzeichnet hier das authentifizierte Ergebnis. Welcome kommt auch auf Fehlerseiten vor und kann die Authentifizierung daher nicht unterscheiden. Hydras S= wählt ein positives Muster: Die Antwort muss es enthalten, um als Erfolg zu zählen. Prüfe mit -U die Hilfe des installierten Moduls; sie erklärt Pfad, Felder und Bedingungssyntax:

hydra -U http-post-form

Speichere das vollständige Übungsargument. cat > calibration.txt schreibt Text in eine Datei; > ersetzt sie, falls sie bereits existiert. Ein Here-Dokument liefert mehrere Zeilen bis zur abschließenden Zeile EOF. Die Anführungszeichen um 'EOF' halten den Inhalt wörtlich. Der Abschlussmarker muss allein auf einer Zeile stehen, ohne Leerzeichen davor:

cat > calibration.txt <<'EOF'
/practice/login:username=^USER^&password=^PASS^:S=Signed in as
EOF

Eine Shell-Variable speichert Text zur Wiederverwendung in diesem Terminal. $(cat calibration.txt) liest die Datei; form= speichert das Ergebnis ohne Leerzeichen um =. Anführungszeichen um "$form" erhalten später die enthaltenen Leerzeichen innerhalb eines einzigen Arguments. Die Variable gehört zur aktuellen Terminalsitzung; führe nach einer erneuten Verbindung die Zuweisung noch einmal aus.

form=$(cat calibration.txt)
hydra -I -C practice-pairs.txt -s 8080 -t 1 -o calibration.json -b json 127.0.0.1 http-post-form "$form"
python3 -m json.tool calibration.json

Nur preview:Preview24 sollte gemeldet werden. Das falsche Passwort, das nicht verfügbare Konto und HTTP 503 sind nicht authentifiziert. Zur Kalibrierung gehört auch der bekannte Erfolgsfall: Eine Bedingung, die alles ablehnt, ist ebenfalls falsch. Ein ausreichend umfassendes Fehlermuster kann dem positiven Muster gleichwertig sein; eine bestimmte Schreibweise von S= ist nicht vorgeschrieben. Das gespeicherte Argument wird mit jeder bekannten Antwort einzeln getestet und nicht bloß wegen eines enthaltenen Schlüsselworts akzeptiert.

Das Paket des zugewiesenen Ausstellers abrufen

In diesem Schritt wendest du die kalibrierte Methode auf den zugewiesenen Aussteller an, authentifizierst dich anschließend unabhängig und rufst dessen tatsächliches Geschäftsdokument ab.

Öffne Exhibitor Portal, dann Exhibitor sign-in und View your review assignment. Das zugewiesene Konto ist papertrail, sein POST-Pfad /signin. Nur die drei Passwörter in candidates.txt sind erlaubt. Das Übungskonto gehört zu einem anderen Formular. Wechsle zu Workstation und lies die Kandidaten:

cat candidates.txt

Speichere ein zweites wiederverwendbares Argument mit dem zugewiesenen Pfad sowie denselben Feldern und derselben Bedingung:

cat > form.txt <<'EOF'
/signin:username=^USER^&password=^PASS^:S=Signed in as
EOF
form=$(cat form.txt)

Anders als -C liefert -l papertrail einen festen Benutzernamen und -P candidates.txt dessen erlaubte Passwörter. Führe die kleine zugewiesene Prüfung aus und speichere ein neues originales JSON-Ergebnis:

hydra -I -l papertrail -P candidates.txt -s 8080 -t 1 -o findings.json -b json 127.0.0.1 http-post-form "$form"
python3 -m json.tool findings.json

Der einzige echte Fund nennt papertrail mit dem Passwort InkPaper7. Diese Aussage gilt nur für das angegebene Konto und die Kandidatenmenge. Sie behauptet nicht, dass die gesamte Website sicher ist.

Wechsle zu Exhibitor Portal. Wähle Exhibitor sign-in, gib das gefundene Paar ein und wähle Sign in, dann Open your workspace. Prüfe papertrail, Stand N-14, Ankunft 09:15 und North loading door. Wähle Download booth kit, um den echten Browserdownload abzurufen. Diese Datei liegt im Downloadbereich deines Browsers und erscheint nicht automatisch im Trainingscontainer.

Zugewiesener papertrail-Arbeitsbereich mit echtem Downloadlink

Prüfe vor dem Download die Felder für Aussteller und Stand oberhalb des Packhinweises.

Wechsle zurück zu Workstation, um die erforderliche Kopie in der VM zu speichern. Ein Cookie ist eine vom Server ausgestellte Sitzungskennung. -c exhibitor.cookies speichert die bei dieser Terminalanmeldung erhaltenen Cookies. Diese Cookie-Datei gehört zu curl; Browser und Hydra teilen sie nicht automatisch. Der Antwortinhalt wird in signin.html gespeichert:

curl -s -c exhibitor.cookies -o signin.html --data 'username=papertrail&password=InkPaper7' http://127.0.0.1:8080/signin

Rufe den authentifizierten Download mit derselben Datei ab. -b sendet ihre Cookies. -f sorgt bei einer HTTP-Ablehnung für einen Status ungleich null, statt unbemerkt eine Fehlerseite als Paket zu speichern:

curl -f -s -b exhibitor.cookies http://127.0.0.1:8080/kit.json -o booth-kit.json

Ein 403 oder curl-Exitstatus 22 bedeutet, dass dieser Client keine akzeptierte Sitzung besitzt. Prüfe Benutzername, Passwort, Formularpfad und Cookie-Dateiname, wiederhole die Anmeldung und danach den Download. Ein 404 bedeutet einen falschen Pfad. Diese Fehler lassen sich beheben; ersetze das Paket nicht durch eine kopierte Vorschaudatei.

python3 -m json.tool booth-kit.json

Vergleiche Aussteller, Stand und Ankunft mit der Seite. Das vollständige Paket enthält auch drei Drucksachenständer, zwei Tischdecken und den Hinweis zu nummerierten Schutzhüllen für Drucke. Die Existenz einer Datei oder ein passender Ausstellername allein beweisen nicht, dass das gesamte Dokument korrekt ist.

Öffne zuletzt Visitor guide in Exhibitor Portal. Die öffentlichen Ankunftsinformationen müssen weiterhin verfügbar sein. Du hast nur deine eigenen Dateien und Sitzungen verändert und dabei Dienst, Konten und Geschäftsdaten erhalten. Deine endgültigen Dateien sind form.txt, findings.json und booth-kit.json im Arbeitsbereich. Die Prüfungen lesen vorhandene Anmelde- und Downloadereignisse und testen das gespeicherte Argument in einem getrennten, temporären Dienst; sie ergänzen keine fehlende Arbeit am echten Portal.

Zusammenfassung

Du hast tatsächlich authentifizierte Arbeitsbereiche mit Antworten für falsche Passwörter, nicht verfügbare Konten und Dienstfehler verglichen. Du hast einen falsch positiven Hydra-Fund reproduziert, eine wiederverwendbare Formularbedingung mit positiven und negativen Beispielen kalibriert und anschließend mit einer getrennten Cookie-Sitzung die zugewiesene Identität bestätigt und deren vollständiges Paket abgerufen. HTTP 200, eine Erfolgsmeldung zur Ausführung oder eine allgemeine Welcome-Meldung beweisen allein keine Authentifizierung.