Einführung
Mitglieder von Fieldwork Studio können einen reservierten Workshop ansehen und ihre Buchungsbestätigung herunterladen. Das Team hat Sign out this browser hinzugefügt. Die Rückkehr zur Anmeldeseite wirkt überzeugend, weist aber nicht nach, ob eine zuvor aufgezeichnete Sitzung noch funktioniert.
Du verwendest Kalis Burp Suite Community Edition als HTTP-Proxy und Repeater, bewahrst die ursprünglichen Anfragen auf und testest nach dem Abmelden beide geschützten Ressourcen. Deine Abgabe besteht aus vertraulichen Anfrage-/Antwortnachweisen und einer kurzen Entscheidung über die Abnahme ohne Passwörter. Du bewertest die Anwendung; du reparierst ihren Server nicht.
Vorausgesetzt werden nur grundlegende Terminaleingaben und das Wechseln zwischen Tabs. Das Lab führt HTTP-Antworten, Cookies und Burps Bedienelemente ein. Alle Identitäten und Buchungen sind synthetisch, und die bereitgestellte Umgebung ist isoliert. Verwende ausschließlich dein vorgegebenes Konto und das Kursziel. Plane einschließlich Lesen und gewöhnlicher Fehler etwa 65 Minuten ein; dies ist eine Schätzung des Autors und keine Messung aus einem Anfängertest.
Eine echte Mitgliederbuchung als Ausgangszustand feststellen
In diesem Schritt stellst du die normale Nutzung fest, bevor du das Abmelden testest. Öffne Auditor, das Kali-Terminal. Es beginnt in /home/labex/project. cat zeigt eine Textdatei an. Lies die vorgegebene Autorisierung, Identität und Dienstadresse:
cat scope.json
Die Basis-URL ist http://members.test:8080/autumn. Verwende den Benutzernamen morgan und das Passwort PaperDay!47. Dein Mitglied ist Morgan Reed mit Platz P12 bei Printmaking. Das Ausrufezeichen gehört zum Passwort; gib es in das Browserformular ein. Teste keine anderen Identitäten oder externen Websites und verändere weder Zieldaten noch Code oder Prozesse.
Wenn ein grafischer Arbeitsbereich Disconnected anzeigt, klicke oben auf seine Schaltfläche Reconnect. Dadurch wird das vorhandene Fenster erneut verbunden; seine Browser-Cookies, Burp-Anfragen und der Fortschritt am Ziel bleiben erhalten.
Öffne Burp. Burp Community ist bereits installiert. Lasse im Startassistenten Temporary project ausgewählt und klicke auf Next. Lasse Use Burp defaults ausgewählt und klicke anschließend auf Start Burp. Falls Burp Suite is out of date erscheint, klicke auf OK, um mit der vorbereiteten Trainingsversion fortzufahren. Warte auf das Hauptfenster. Ein temporäres Projekt hält den laufenden Arbeitsbereich im Speicher; dieser Kurs verwendet ausdrückliche XML-Exporte für die Nachweisdateien statt einer kostenpflichtigen Funktion für auf Festplatte gespeicherte Projekte.
Burp ist ein Proxy: Die vorbereiteten Browser senden ihre HTTP-Anfragen darüber, sodass du den tatsächlichen Austausch untersuchen kannst. Wähle in Burp den Haupttab Proxy und den Untertab Intercept. Die Schaltfläche muss Intercept is off anzeigen. Falls sie Intercept is on anzeigt, klicke einmal darauf. Das Abfangen würde Anfragen anhalten; sie sollen normal weiterlaufen, während der Verlauf aufgezeichnet wird.
Wechsle zum LabEx-Tab Browser A. Dies ist ein vorbereiteter Chromium-Browser im selben Audit-Container wie Burp. Klicke auf seine Adressleiste, gib die folgende URL ein und drücke die Eingabetaste:
http://members.test:8080/autumn/
Lies die öffentliche Workshop-Seite und wähle View my booking. Trage die vorgegebenen Zugangsdaten in Username und Password ein und klicke auf Sign in. Falls Chromium das Speichern des Passworts anbietet, wähle Never. Du solltest Your next day of making erreichen; dort werden Morgan Reed, Printmaking und Platz P12 angezeigt.
Klicke auf Download booking. Die tatsächliche fieldwork-booking.csv enthält das Mitglied, den Workshop und den Platz. Chromiums Downloadleiste am unteren Rand zeigt die heruntergeladene Datei; Show all öffnet seine Downloadliste. Öffentliches Stöbern durch Workshops, das Ansehen deiner Buchung und dieser Download sind die normalen Funktionen, die du erhalten wirst.
Prüfe vor dem Herunterladen Mitglied, Workshop und Platz auf der Buchungskarte.
Ein falsches Passwort führt zu Sign-in unsuccessful mit einem Link try again. Folge diesem Link und gib die vorgegebenen Werte erneut ein. Eine Antwort Page not found bedeutet, dass der Pfad falsch ist; kehre zur genauen Basis-URL oben zurück. Ein Verbindungsfehler im Browser bedeutet, dass keine Antwort der Anwendung erhalten wurde: Prüfe die URL, schließe Burps Assistenten ab und stelle sicher, dass das Abfangen ausgeschaltet ist. Behandle einen Verbindungsfehler nicht als sicherheitsbedingte Ablehnung.
Browser B ist ein unabhängiges Browserprofil für das nächste Lab; verwende es hier noch nicht. Die beiden Browser-Tabs und Burp sind Fenster in einem Audit-Container, keine separaten virtuellen Maschinen. Das Wechseln zwischen LabEx-Tabs setzt weder das Ziel noch deine Arbeit zurück.
Die ursprünglichen Anfragen in Repeater aufbewahren
In diesem Schritt bewahrst du Anfragen auf, die bereits funktioniert haben. Wechsle zu Burp, wähle Proxy und dann HTTP history. Suche die GET-Anfrage an /autumn/account bei members.test:8080. Eine Anfrage ist das, was der Browser sendet; eine Antwort ist das, was der Server zurückgibt. GET liest eine Ressource. HTTP 200 OK bedeutet, dass diese Anfrage eine erfolgreiche Antwort erhalten hat.
Klicke auf die Kontozeile. Wähle in ihrem Anfrageeditor Raw und suche den Header Cookie. Beim Anmelden wurde ein Sitzungscookie namens studio_session ausgegeben: Der Browser sendet diesen Wert, um seine authentifizierte Sitzung zu kennzeichnen. Der Besitz des alten Cookies ist die Bedingung, die du testest. Das Löschen eines Browser-Cookies und eine neue Anfrage ohne Cookie würden eine andere Frage prüfen.
Klicke mit der rechten Maustaste auf die Kontozeile und wähle Send to Repeater. Mit Repeater kannst du eine aufbewahrte Anfrage erneut senden und die neue Antwort untersuchen. Suche anschließend die GET-Anfrage an /autumn/booking.csv, klicke mit der rechten Maustaste darauf und wähle Send to Repeater. Falls ein Verlaufsfilter die CSV-Anfrage ausblendet, klicke auf die Filterleiste über der Tabelle und aktiviere Show all. Schließe dann den Filterdialog und suche erneut den genauen Pfad. Verwende Host und Pfad, nicht nur die Zeilenposition.
Wähle den Haupttab Repeater. Der erste nummerierte Anfragetab, 1, ist die Kontoanfrage; 2 ist die Buchungsanfrage, entsprechend deiner Sendereihenfolge. Bestätige in 1, dass das Ziel http://members.test:8080 ist, die Anfragezeile GET /autumn/account HTTP/1.1 lautet und das ursprüngliche Cookie studio_session weiterhin vorhanden ist. Klicke auf Send. Wähle im Antwortbereich Raw, um HTTP/1.0 200 OK und den Inhalt der Buchungsseite zu lesen.
Wähle 2 und klicke auf Send. Erwarte 200 OK, den Inhaltstyp text/csv und die echten Buchungszeilen. Die HTTP-Version des Servers kann von derjenigen der Anfrage abweichen; die aussagekräftigen Beobachtungen sind der Status und der tatsächliche Buchungsinhalt des Mitglieds.
Beide aufbewahrten Anfragen müssen dasselbe Sitzungscookie verwenden. Vergleiche die Werte in Burp, ohne sie in einen Bericht zu kopieren. Lasse diese beiden Repeater-Anfragen während des gesamten Abmeldens unverändert: Entferne oder ersetze ihre Cookies nicht, ändere das Ziel nicht und sende über diese Tabs keine Abmeldeanfrage. Ihr erfolgreicher Ausgangszustand macht den späteren Vergleich aussagekräftig.
Falls du die falsche Verlaufszeile gesendet hast, schließe nur diesen Repeater-Anfragetab und sende die richtige Zeile. Erkenne die richtige Anfrage an ihrem Pfad; die Tabnummern können dann abweichen. Das Schließen eines Anfragetabs ist etwas anderes als das Schließen von Burp oder das Zurücksetzen der VM.
Das alte Cookie nach dem Abmelden testen
In diesem Schritt unterscheidest du das im Browser sichtbare Abmelden von der serverseitigen Ungültigmachung einer Sitzung. Wechsle zu Browser A. Klicke auf der Buchungsseite auf Sign out this browser. Der Browser kehrt zu Welcome back, der Anmeldeseite, zurück.
Dieser Seitenwechsel allein beweist nicht, dass der Server das alte Cookie nicht mehr akzeptiert. Wechsle zu Burp, öffne Repeater, wähle deine ursprüngliche Kontoanfrage und klicke erneut auf Send. Lasse ihr Cookie unverändert. Erwarte 200 OK und Morgan Reeds Buchungsinhalt. Die alte Sitzung gewährt nach dem Abmelden weiterhin Kontozugriff.
Wähle deine ursprüngliche Buchungsanfrage und klicke erneut auf Send. Erwarte 200 OK, text/csv und die Buchungszeile desselben Mitglieds. Dies ist eine echte erfolgreiche Downloadantwort, die mit dem alten Cookie erhalten wurde; eine erfolgreich wirkende Browserseite oder HTTP 200 mit lediglich einem Anmeldeformular würde dies nicht nachweisen.
Bei einem funktionierenden Abmelden des aktuellen Browsers sollten beide aufbewahrten geschützten Anfragen stattdessen 401 Unauthorized erhalten. Das bedeutet, dass die Anwendung diese Sitzung ablehnt. Hier akzeptiert der Server sie weiterhin für beide Ressourcen. Lehne die Änderung am Abmelden aufgrund deiner beobachteten Nachweise ab. Du hast diesen bestimmten Sitzungsfehler nachgewiesen, nicht jede mögliche Schwachstelle der Anwendung.
Bestätige, dass die gewöhnliche Nutzung weiterhin möglich ist. Wechsle zu Browser A, melde dich erneut mit morgan und PaperDay!47 an, sieh dir die Buchung an und klicke auf Download booking. Dadurch wird eine neue Sitzung ausgegeben und der normale Mitgliederablauf bleibt funktionsfähig. Kehre zu Burp zurück, ohne die Cookies in deinen beiden ursprünglichen Repeater-Anfragen zu ersetzen. Ihre neuesten Antworten müssen weiterhin die Antworten nach dem Abmelden sein, die du als Nächstes exportierst.
Vergleiche das unveränderte Cookie im linken Bereich Request mit 200 OK und der echten Mitgliederzeile im rechten Bereich Response. Ein erfolgreicher Status allein würde den Zugriff auf diese Buchung nicht nachweisen.
Falls du versehentlich ein ursprüngliches Cookie überschreibst oder beide aufbewahrten Anfragen schließt, wiederhole einen vollständigen Test: Zeichne eine neue erfolgreiche Sitzung für beide Ressourcen auf, bewahre ihre Anfragen auf, melde diese Sitzung ab und sende anschließend genau diese Anfragen erneut. Ein Cookie aus einer neuen Anmeldung ersetzt nicht das Cookie der Sitzung, die du abgemeldet hast.
Vertrauliche Nachweise und eine klare Entscheidung abgeben
In diesem Schritt speicherst du die tatsächlichen HTTP-Nachweise und hältst Zugangsdaten aus der Bewertung heraus. Wechsle zu Auditor. Anfrage-/Antwortnachweise enthalten ein verwendbares Sitzungscookie; beschränke deshalb den Zugriff, bevor du sie speicherst.
umask 077 macht neu erstellte Dateien und Verzeichnisse nur für deinen Benutzer zugänglich. Dies gilt für diese Terminalsitzung, nicht für jede zukünftige Shell. mkdir -p erstellt bei Bedarf das angegebene Verzeichnis. chmod 700 gibt seinem Eigentümer Lese-, Schreib- und Verzeichniszugriff, ohne Zugriff für Gruppe oder andere Benutzer.
umask 077
mkdir -p evidence
chmod 700 evidence
Wechsle zu Burp und wähle in Repeater die ursprüngliche Kontoanfrage. Bestätige, dass ihre aktuelle Antwort die Buchungsseite mit 200 OK nach dem Abmelden ist. Klicke im Editor Request mit der rechten Maustaste und wähle Save item. Dadurch werden Anfrage und Antwort zusammen gespeichert; Copy to file würde anderes Material speichern.
Gib im Dialog Select a file diesen absoluten Pfad in File Name ein:
/home/labex/project/evidence/account-after.xml
Verwende das Feld File Name nahe dem unteren Rand; die aktivierte Base64-Option steht darunter.
Lasse Base64-encode requests and responses aktiviert und klicke dann auf Save. Base64 stellt die ursprünglichen Bytes sicher innerhalb von XML dar; es verschlüsselt das Cookie nicht. Schließe eine gegebenenfalls erscheinende Erfolgsmeldung mit OK. Wiederhole Save item für die ursprüngliche Buchungsanfrage und verwende:
/home/labex/project/evidence/booking-after.xml
Wechsle zu Auditor. chmod 600 erlaubt nur dem Eigentümer das Lesen und Schreiben jeder Datei. ls -l zeigt Berechtigungen an; erwarte für beide XML-Dateien -rw-------.
chmod 600 evidence/account-after.xml evidence/booking-after.xml
ls -l evidence
Schreibe die folgende Bewertung ohne Passwörter. > ersetzt die benannte Datei. <<'JSON' beginnt ein Here-Dokument: Die Shell kopiert die folgenden Zeilen wörtlich bis zum abschließenden JSON in einer eigenen Zeile. Numerische Statuswerte stehen ohne Anführungszeichen; JSON true ist ein boolescher Wert. Halte Cookies, Passwörter und rohe Anfragen aus diesem Bericht heraus.
cat > assessment.json <<'JSON'
{
"decision": "reject",
"account_after_logout": 200,
"booking_after_logout": 200,
"fresh_sign_in_works": true
}
JSON
Lies deine Bewertung, um gewöhnliche Tippfehler zu entdecken:
cat assessment.json
Deine Übergabe besteht aus den beiden vertraulichen XML-Einträgen und dieser Bewertung. Die Einträge bewahren Anfragen mit dem ursprünglichen Cookie und ihre echten Antworten auf; der Bericht vermittelt die belegte Entscheidung, ohne Geheimnisse zu wiederholen. Die Verifikation prüft diese Beziehungen anhand vorhandener Serverfakten. Sie erzeugt für dich keine fehlenden Anmeldungen, Abmeldungen oder erneut gesendeten Anfragen und lässt deine Dateien unverändert. Ihre gewöhnliche Anfrage zur Erhaltung der öffentlichen Seite kann einen Zugriffsdatensatz anhängen.
Ist ein Dateiname falsch, wiederhole Save item mit dem angegebenen absoluten Pfad und wende erneut chmod 600 an. Falls du das Verzeichnis gewechselt hast, zeigt pwd das aktuelle Verzeichnis und cd /home/labex/project kehrt zum Arbeitsverzeichnis zurück. Ersetze fehlende Nachweise nicht durch eine handgeschriebene Erfolgsmeldung oder einen Screenshot.
Zusammenfassung
Du hast eine echte Buchung als Ausgangszustand festgestellt, zwei Anfragen mit dem ursprünglichen Cookie in Burp Repeater aufbewahrt, dich abgemeldet und gezeigt, dass der Server beide Anfragen weiterhin akzeptierte. Die Rückkehr eines Browsers zur Anmeldeseite wies keine Ungültigmachung der Sitzung nach. Du hast den normalen Ablauf erhalten und vertrauliche HTTP-Nachweise mit einer Ablehnungsentscheidung ohne Passwörter abgegeben.
Das nächste Lab untersucht eine korrigierte Bereitstellung. Ein unabhängiger Browser hilft dabei, das Beenden der aktuellen Sitzung vom unnötigen Beenden sämtlicher Sitzungen desselben Mitglieds zu unterscheiden.
