Einführung
Das Studio-Team hat geändert, wie Sign out this browser mit Sitzungen umgeht. Das Beenden sämtlicher Sitzungen würde das alte Cookie unwirksam machen, aber auch einen anderen Browser unterbrechen, den das Mitglied weiterhin verwenden möchte. Die Abnahme muss sowohl das Sicherheitsergebnis als auch das zugesagte normale Verhalten abdecken.
Du bewahrst die ursprünglichen Konto- und Buchungsanfragen von Browser A in Burp Repeater auf, richtest für dasselbe Mitglied eine eigenständige Browser-B-Sitzung ein und testest beide nach dem Abmelden von A. Deine Übergabe kombiniert vertrauliche HTTP-Nachweise und eine Abnahmeentscheidung ohne Passwörter. Die Umgebung ist unabhängig: Es werden keine früheren Dateien, Sitzungen oder Burp-Tabs übernommen.
Absolviere zuerst Eine Buchungsanfrage nach dem Abmelden erneut senden. Du solltest wissen, wie du Burps temporäres Projekt startest, das Abfangen ausgeschaltet lässt, Verlaufszeilen an Repeater sendest, HTTP-Status liest und einen XML-Eintrag speicherst. Dieses Lab wiederholt den Bedienablauf und ergänzt einen Vergleich unabhängiger Sitzungen. Alle Konten und Buchungen sind synthetisch. Plane einschließlich Lesen und gewöhnlicher Fehler etwa 60 Minuten ein; dies ist eine Schätzung des Autors.
Die normale Buchung in Browser A als Ausgangszustand feststellen
In diesem Schritt stellst du den normalen Ablauf in dieser neuen Bereitstellung fest. Öffne Auditor und lies die vorgegebene Identität, Adresse und Autorisierung:
cat scope.json
Verwende ausschließlich http://members.test:8080/autumn, den Benutzernamen morgan und das Passwort PaperDay!47. Die Buchung gehört Morgan Reed: Printmaking, Platz P12. Erhalte den vorgegebenen Prüfumfang, die Zielkonfiguration, Daten und 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. Lasse Temporary project ausgewählt, klicke auf Next, lasse Use Burp defaults ausgewählt und klicke auf Start Burp. Falls Burp Suite is out of date erscheint, klicke auf OK, um mit der vorbereiteten Trainingsversion fortzufahren. Wähle im Hauptfenster Proxy → Intercept und stelle sicher, dass die Schaltfläche Intercept is off anzeigt. Falls sie Intercept is on anzeigt, klicke einmal darauf, damit normale Anfragen nicht angehalten werden.
Wechsle zu Browser A. Klicke auf die Chromium-Adressleiste, gib diese URL ein und drücke die Eingabetaste:
http://members.test:8080/autumn/
Wähle View my booking, gib morgan in Username und PaperDay!47 in Password ein und klicke dann auf Sign in. Wähle Never, falls Chromium das Speichern des Passworts anbietet. Bestätige Morgan Reed, Printmaking und Platz P12 auf Your next day of making und klicke dann auf Download booking. Die tatsächliche CSV enthält dieses Mitglied, diesen Workshop und diesen Platz.
Ein Tippfehler in den Zugangsdaten führt zu Sign-in unsuccessful; verwende try again und korrigiere die vorgegebenen Werte. Kehre bei einem falschen Pfad zur genauen Basis-URL zurück. Ein Verbindungsfehler im Browser ist keine HTTP-Ablehnung: Schließe Burps Assistenten ab, prüfe das Abfangen und die genaue Adresse und navigiere dann erneut. Das Schließen eines LabEx-Tabs setzt das Szenario nicht zurück.
Die erfolgreichen Anfragen von Browser A aufbewahren
In diesem Schritt bewahrst du die ursprüngliche Sitzung von Browser A auf, bevor ein weiterer Browser hinzukommt. Wechsle zu Burp und dann zu Proxy → HTTP history. Suche die Zeile GET /autumn/account für members.test:8080, klicke mit der rechten Maustaste darauf und wähle Send to Repeater. Wiederhole dies für GET /autumn/booking.csv. Falls ein Verlaufsfilter die CSV ausblendet, öffne die Filterleiste und aktiviere Show all.
Öffne den Haupttab Repeater. Bestätige im ersten Anfragetab den Kontopfad und den ursprünglichen Header Cookie: studio_session=... und klicke dann auf Send. Lies die Antwort unter Raw: HTTP 200 mit Morgan Reeds Buchung. Wähle den zweiten Anfragetab und klicke auf Send. Er muss HTTP 200 mit der tatsächlichen CSV-Buchungszeile zurückgeben.
Die beiden Anfragen verwenden dasselbe ursprüngliche Sitzungscookie von Browser A. Lasse sie einschließlich Host, Pfaden und Cookies unverändert. Die nummerierten Tabs in Repeater kennzeichnen Anfragen, während die LabEx-Tabs Browser A und Browser B unabhängige Browserprofile kennzeichnen. Das Wechseln eines LabEx-Tabs ändert nicht, welche Anfrage innerhalb von Repeater ausgewählt ist.
Diese erfolgreichen Antworten bilden den Ausgangszustand. Ein Cookie, das nie funktioniert hat, kann nicht zeigen, ob das Abmelden später eine echte Sitzung ungültig gemacht hat. Falls du die falsche Verlaufszeile ausgewählt hast, sende den richtigen Pfad an Repeater und verwende stattdessen diesen Anfragetab; erkenne ihn am Pfad, statt eine Tabnummer zu erraten.
Die Grenze der aktuellen Sitzung testen
In diesem Schritt prüfst du, ob das Abmelden eines Browsers nur dessen Sitzung beendet. Ein unabhängiges Browserprofil hat einen eigenen Cookie-Speicher. Ein zweiter Tab innerhalb von Browser A würde das Cookie von A teilen und diesen Vergleich nicht ermöglichen.
Wechsle zum LabEx-Tab Browser B. Navigiere in seiner Chromium-Adressleiste zu:
http://members.test:8080/autumn/login
Melde dich als dasselbe Mitglied, morgan, mit PaperDay!47 an. Wähle Never, falls du nach dem Speichern des Passworts gefragt wirst. Bestätige die Buchung und klicke auf Download booking. Lasse Browser B angemeldet. Seine erfolgreichen Konto- und Downloadanfragen müssen vor dem Abmelden von A erfolgen.
Für einen direkten Identitätsvergleich wechsle zu Burp → Proxy → HTTP history. Wähle die neueste /autumn/account-Anfrage von B und untersuche ihre Anfrage unter Raw. Ihr studio_session-Wert unterscheidet sich vom Wert, der in den ursprünglichen Repeater-Tabs von A aufbewahrt wird. Beide Sitzungen stehen für Morgan Reed, sind jedoch eigenständige Authentifizierungszustände. Kopiere keines der Cookies in deinen Bericht und ersetze das aufbewahrte Cookie von A nicht durch dasjenige von B.
Wechsle zu Browser A und klicke auf Sign out this browser. Die Anmeldeseite erscheint. Wechsle anschließend zu Burp → Repeater und klicke bei der ursprünglichen Kontoanfrage von A auf Send. Erwarte 401 Unauthorized und Sign in required. Sende auch die ursprüngliche Buchungsanfrage von A: Erwarte HTTP 401 ohne Mitgliederbuchungs-CSV. Lasse beide ursprünglichen Cookies intakt; eine Anfrage ohne Cookie würde die Ungültigmachung der alten Sitzung von A nicht testen.
Lies das unveränderte Cookie im linken Bereich sowie 401 Unauthorized mit Sign in required im rechten Bereich. Dies ist eine Ablehnung der zuvor funktionierenden Sitzung von A.
Wechsle nun zu Browser B. Klicke auf Chromiums Schaltfläche zum Neuladen neben der Adressleiste. Die Buchungsseite muss weiterhin Morgan Reeds Buchung zeigen. Klicke erneut auf Download booking und bestätige einen echten Download. Diese neuen Anfragen weisen den fortgesetzten Zugriff nach; eine ohne Aktualisierung auf dem Bildschirm belassene Seite könnte veraltet sein. Falls auch B den Zugriff verloren hätte, würde das Beenden sämtlicher Sitzungen den ausdrücklichen Vertrag this browser dieses Kurses verletzen, selbst wenn das alte Cookie von A abgelehnt wurde. Andere Produkte können absichtlich eine separate Aktion zum Abmelden aller Sitzungen anbieten; das ist ein anderer Vertrag.
Wechsle abschließend zu Browser A, melde dich erneut mit den vorgegebenen Zugangsdaten an, sieh dir die Buchung an und klicke auf Download booking. Eine neue Sitzung funktioniert weiterhin. Wechsle zurück zu Burp, ohne die ursprünglichen Repeater-Anfragen von A zu verändern. Ihre neuesten Antworten bleiben die beiden HTTP-401-Antworten nach dem Abmelden.
Du kannst diese begrenzte Änderung annehmen: Die alte Sitzung von A scheitert an beiden geschützten Ressourcen, die bereits eingerichtete unabhängige Sitzung von B funktioniert weiterhin und eine neue Anmeldung funktioniert. Dies weist nicht jeden Aspekt der Sitzungssicherheit nach.
Falls du versehentlich B abgemeldet oder das alte Cookie von A ersetzt hast, richte zwei neue unabhängige Sitzungen ein und wiederhole die vollständige Reihenfolge: Stelle in beiden Browsern den erfolgreichen Ausgangszustand für beide Ressourcen fest, bewahre die Anfragen von A auf, melde A ab, sende die Anfragen von A erneut, aktualisiere und lade in B herunter und bestätige dann eine neue Anmeldung in A. Das bloße erneute Öffnen eines Tabs erzeugt keine Ersatzsitzung.
Die Nachweise des angenommenen Tests aufbewahren
In diesem Schritt gibst du vertrauliche Nachweise und die belegte Annahmeentscheidung ab. Wechsle zu Auditor, das in /home/labex/project startet. Wie zuvor vermittelt, beschränkt umask 077 neue Dateien in dieser Shell, mkdir -p erstellt das Nachweisverzeichnis und chmod 700 macht dieses Verzeichnis nur für seinen Eigentümer zugänglich.
umask 077
mkdir -p evidence
chmod 700 evidence
Wechsle zu Burp → Repeater. Wähle die ursprüngliche Kontoanfrage von A und bestätige, dass ihre neueste Antwort HTTP 401 nach dem Abmelden ist. Klicke mit der rechten Maustaste im Editor Request, wähle Save item und gib diesen absoluten Pfad in File Name ein:
/home/labex/project/evidence/account-after.xml
Lasse Base64-encode requests and responses aktiviert und klicke auf Save. Schließe eine gegebenenfalls vorhandene Erfolgsmeldung mit OK. Wiederhole dies für die ursprüngliche Buchungsanfrage von A, deren neueste Antwort ebenfalls HTTP 401 sein muss:
/home/labex/project/evidence/booking-after.xml
Diese XML-Einträge enthalten das ursprüngliche Cookie von A. Base64 ist eine Kodierung, keine Verschlüsselung. Wechsle zu Auditor und beschränke die Dateien auf ihren Eigentümer:
chmod 600 evidence/account-after.xml evidence/booking-after.xml
ls -l evidence
Erwarte bei beiden Dateien -rw-------. Verwende für einen Bericht ohne Passwörter dasselbe wörtliche Here-Dokument-Format wie zuvor. > ersetzt assessment.json; das abschließende JSON muss in einer eigenen Zeile stehen.
cat > assessment.json <<'JSON'
{
"decision": "accept",
"account_after_logout": 401,
"booking_after_logout": 401,
"independent_browser_preserved": true,
"fresh_sign_in_works": true
}
JSON
cat assessment.json
Gib die ursprünglichen XML-Paare und diesen Bericht ab und halte Passwörter, Cookies und rohe Anfragen aus dem Bericht heraus. Vorhandene Serverfakten belegen den unabhängigen Zugriff von B und die neue Anmeldung; die Verifikation führt keine fehlenden Anmeldungen, Abmeldungen oder erneut gesendeten Anfragen aus. Ihre Anfrage zur Erhaltung der öffentlichen Seite kann einen Zugriffsdatensatz anhängen, und wiederholte Bewertungen erhalten deine Dateien.
Exportiere bei einem falschen Dateinamen dieselbe echte Antwort zum richtigen Pfad und wende erneut chmod 600 an. Falls sich deine Shell anderswo befindet, prüfe dies mit pwd und kehre mit cd /home/labex/project zurück. Halte die normale öffentliche Website und alle Zielressourcen intakt.
Zusammenfassung
Du hast ein korrigiertes Abmelden des aktuellen Browsers sowohl für die Kontoseite als auch für den Buchungsdownload getestet. Das alte Cookie wurde abgelehnt, eine eigenständige, bereits bestehende Browsersitzung behielt ihren Zugriff und eine neue Anmeldung funktionierte weiterhin. Vertrauliche Burp-XML-Paare und eine Bewertung ohne Passwörter bewahren die belegte Annahmeentscheidung auf.
Die unabhängige Challenge ändert Mitglied, Bereitstellungsadresse und Buchung. Wende denselben vollständigen Vertrag an und lasse beide echten Ressourcenantworten die Entscheidung bestimmen.
