Repeater Session Test: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Ein Session-Test mit Burp Repeater ist kein stumpfes Wiederholen einzelner Requests, sondern eine kontrollierte Analyse des Zustandsmodells einer Webanwendung. Genau dort passieren in realen Anwendungen die interessanten Fehler: Sessions bleiben nach Logout gültig, Rollenwechsel werden serverseitig nicht sauber erzwungen, Tokens sind nur kosmetisch vorhanden oder einzelne Endpunkte prüfen Authentisierung und Autorisierung unterschiedlich streng. Repeater ist dafür ideal, weil Requests präzise reproduzierbar bleiben und jede Änderung isoliert getestet werden kann.

Im Gegensatz zu breit angelegten Angriffswerkzeugen geht es hier nicht primär um Masse, sondern um Kausalität. Ein sauberer Session-Test beantwortet konkrete Fragen: Welche Werte identifizieren die Sitzung wirklich? Welche Header sind optional? Welche Cookies sind nur Tracking und welche sind sicherheitsrelevant? Wird der Benutzerzustand serverseitig geführt oder vertraut die Anwendung auf clientseitige Artefakte? Wer die Grundlagen von Repeater und den generellen Ablauf aus der Repeater Anleitung beherrscht, kann damit sehr schnell belastbare Aussagen über Authentisierung und Sitzungslogik treffen.

Der größte Denkfehler in der Praxis besteht darin, Session-Tests nur auf Cookies zu reduzieren. Moderne Anwendungen verteilen Zustandsinformationen über mehrere Ebenen: Session-Cookie, CSRF-Token, Bearer-Token, Refresh-Token, Custom Header, Device-ID, SameSite-Verhalten, serverseitige Session-Store-Einträge und manchmal sogar URL-Parameter. Repeater macht diese Zusammenhänge sichtbar, wenn Requests nicht nur gesendet, sondern systematisch variiert werden.

Ein belastbarer Test beginnt immer mit einer Referenzanfrage. Das ist ein Request, der in einem stabilen, authentisierten Zustand erfolgreich funktioniert, etwa der Abruf eines Profils, einer Kontoverwaltung oder eines API-Endpunkts mit sensiblen Daten. Diese Referenz wird in Repeater übernommen und danach in kleinen Schritten verändert. So lässt sich exakt erkennen, welcher Bestandteil für die Session wirklich relevant ist und welcher nur zufällig mitläuft.

Besonders wertvoll ist Repeater bei Anwendungen, die sich im Browser scheinbar konsistent verhalten, intern aber widersprüchliche Prüfungen durchführen. Ein Endpunkt kann korrekt auf ein Session-Cookie prüfen, während ein anderer nur auf einen Header oder eine Benutzer-ID vertraut. Solche Inkonsistenzen fallen im normalen Klicktest oft nicht auf, weil der Browser automatisch alle Zustandsdaten mitsendet. Repeater trennt diese Mechanismen voneinander und macht sichtbar, was der Server tatsächlich validiert.

Vor jedem Test muss klar sein, welche Bestandteile eines Requests den authentisierten Zustand tragen. In klassischen Webanwendungen ist das oft ein Session-Cookie wie PHPSESSID, JSESSIONID oder ein Framework-spezifischer Wert. In Single-Page-Apps kommen zusätzlich Authorization-Header, JWTs, X-CSRF-Token oder proprietäre Header hinzu. Ohne diese Trennung wird schnell das Falsche getestet. Dann wird etwa ein Cookie entfernt, während der eigentliche Zugriff weiterhin über einen Bearer-Token autorisiert wird, und das Ergebnis wird falsch interpretiert.

Ein sauberer Ansatz ist, zunächst alle Authentisierungsartefakte aus einem funktionierenden Request zu extrahieren und logisch zu gruppieren. Cookies sind nicht automatisch gleich wichtig. Ein Analytics-Cookie oder Consent-Cookie hat für die Session keine Bedeutung. Ein Anti-CSRF-Token schützt oft nur zustandsändernde Requests, nicht aber reine Lesezugriffe. Ein JWT kann Authentisierung und Rolleninformationen gleichzeitig transportieren, während ein Session-Cookie nur als Schlüssel in einen serverseitigen Store dient. Wer Session-Tests ernsthaft betreibt, muss diese Unterschiede lesen können.

• Primäre Session-Träger: Session-Cookies, Bearer-Tokens, JWTs, API-Keys, signierte Login-Tokens
• Sekundäre Zustandsdaten: CSRF-Tokens, Device-IDs, Nonces, Custom Header, Fingerprint-Werte
• Irrelevante Begleitdaten: Tracking-Cookies, Consent-Werte, UI-Präferenzen, A/B-Test-Parameter

Gerade bei APIs ist die Trennung zwischen Authentisierung und Sitzungsverwaltung oft unsauber dokumentiert. Ein Access-Token kann gültig sein, obwohl die Web-Session bereits beendet wurde. Umgekehrt kann ein Logout nur das Browser-Cookie löschen, nicht aber einen parallel existierenden API-Token invalidieren. Solche Konstellationen sind ein klassischer Befund im Bereich Session Management, weil sie zu inkonsistenten Sicherheitsgrenzen führen.

Auch Cookie-Attribute gehören in die Bewertung. HttpOnly, Secure, SameSite, Domain und Path entscheiden nicht darüber, ob ein Token serverseitig akzeptiert wird, aber sie beeinflussen die Angriffsfläche massiv. Ein Session-Test in Repeater zeigt zwar primär die serverseitige Akzeptanz, sollte aber immer mit einem Blick auf die Cookie-Eigenschaften kombiniert werden. Ein technisch funktionierendes Session-Cookie ohne Secure-Flag ist ein anderes Risiko als ein sauber gesetztes Cookie, das nur wegen fehlender Invalidation nach Logout problematisch ist.

Wenn unklar ist, wie ein bestimmter Wert kodiert ist, lohnt sich die parallele Analyse mit Decoder. Gerade Base64-kodierte JSON-Strukturen, JWT-Claims oder URL-kodierte Session-Parameter lassen sich so schneller einordnen. Entscheidend ist jedoch nicht die Dekodierung an sich, sondern die Frage, ob der Server den Wert prüft oder nur entgegennimmt.

Ein professioneller Session-Test folgt einer festen Reihenfolge. Zuerst wird im Browser ein klar definierter Zustand hergestellt: frisch eingeloggt, bekannte Rolle, keine Altlasten aus früheren Sessions. Danach wird über Proxy History ein geeigneter Request ausgewählt und an Repeater gesendet. Dieser Request sollte möglichst wenig dynamische Nebeneffekte enthalten und idealerweise einen sensiblen, aber reproduzierbaren Endpunkt ansprechen.

Danach beginnt die eigentliche Arbeit: nicht alles gleichzeitig ändern, sondern pro Test genau eine Hypothese prüfen. Wird das Session-Cookie entfernt, bleibt alles andere unverändert. Wird ein CSRF-Token manipuliert, bleibt die Session stabil. Wird ein Request nach Logout erneut gesendet, darf kein automatischer Browser-Refresh dazwischenfunken. Diese Disziplin ist entscheidend, weil Session-Fehler oft nur unter sehr spezifischen Bedingungen sichtbar werden.

Ein typischer Ablauf sieht so aus: Referenzrequest senden, Antwortcode und Response-Länge notieren, Session-Cookie entfernen, erneut senden, Ergebnis vergleichen, Cookie wiederherstellen, stattdessen Token manipulieren, erneut senden, danach Logout im Browser ausführen und denselben Request mit dem alten Zustand erneut testen. Wer so arbeitet, erkennt nicht nur, ob etwas funktioniert, sondern warum es funktioniert.

Die Vergleichbarkeit der Antworten ist zentral. Ein HTTP 200 bedeutet nicht automatisch Erfolg. Viele Anwendungen liefern bei ungültiger Session ebenfalls 200 zurück, zeigen aber eine Login-Seite, ein leeres JSON-Objekt oder eine generische Fehlermeldung. Deshalb müssen Header, Body, Redirects, Content-Length, Set-Cookie-Verhalten und semantische Inhalte gemeinsam bewertet werden. Für feine Unterschiede kann Comparer hilfreich sein, wenn zwei Antworten auf Byte- oder Wortebene gegenübergestellt werden sollen.

Ein weiterer Punkt ist die Trennung von Browserzustand und Repeaterzustand. Repeater sendet genau das, was im Request steht. Das ist ein Vorteil, aber auch eine Fehlerquelle. Wenn im Browser zwischenzeitlich eine neue Session aufgebaut wurde, sagt das nichts über den alten Request in Repeater aus. Deshalb sollten Testfälle dokumentiert und zeitlich sauber getrennt werden. In längeren Assessments spart ein definierter Workflow viel Zeit und verhindert Fehlinterpretationen.

GET /account/profile HTTP/1.1
Host: target.example
Cookie: session=7f9c2d1a8e4b6c10; csrf=8d2f1c
User-Agent: Mozilla/5.0
Accept: application/json
X-Requested-With: XMLHttpRequest

Aus so einer Referenzanfrage lassen sich mehrere Hypothesen ableiten: Ist nur das Cookie session relevant? Wird csrf bei GET ignoriert? Reicht X-Requested-With für irgendeine Sonderbehandlung? Gibt es nach Logout noch Zugriff, wenn der alte Request unverändert erneut gesendet wird? Genau diese Fragen machen aus einem simplen Wiederholungswerkzeug ein präzises Testinstrument.

Die interessantesten Befunde entstehen selten durch exotische Tricks, sondern durch inkonsistente Implementierungen. Ein Klassiker ist die fehlende serverseitige Invalidation nach Logout. Der Browser löscht das Cookie oder wird auf eine Login-Seite umgeleitet, aber der alte Session-Identifier bleibt im Backend aktiv. Ein in Repeater gespeicherter Request funktioniert dann weiterhin. Das ist kein kosmetischer Fehler, sondern ein direkter Verstoß gegen die Erwartung, dass Logout die Sitzung beendet.

Ebenso häufig sind Endpunkte, die nur teilweise geschützt sind. Die HTML-Oberfläche verlangt eine gültige Session, während JSON- oder API-Endpunkte mit denselben Daten schwächer abgesichert sind. Gerade Anwendungen mit Frontend-Framework und separatem Backend zeigen dieses Muster oft. Die UI blockiert den Zugriff sauber, aber ein direkter Request an /api/user/details oder /export/report liefert weiterhin Daten, wenn nur ein Teil der Prüfungen greift.

Ein weiteres Fehlerbild ist die unvollständige Rollenvalidierung. Nach einem Rollenwechsel, Passwortwechsel oder Rechteentzug bleibt ein alter Request mit zuvor erlangten Berechtigungen noch gültig. Das deutet darauf hin, dass die Anwendung Berechtigungen beim Login in die Session schreibt, aber nicht bei jeder Anfrage neu bewertet. In sensiblen Umgebungen kann das zu horizontalen oder vertikalen Privilegienproblemen führen und überschneidet sich häufig mit Idor-ähnlichen Zugriffsmustern.

Auch parallele Sessions sind ein Prüfpunkt. Manche Anwendungen sollen Mehrfachanmeldungen verhindern oder alte Sessions bei neuem Login invalidieren. In der Praxis bleibt die alte Session oft aktiv. Repeater ist ideal, um einen alten Request aufzubewahren, dann eine neue Anmeldung im Browser durchzuführen und anschließend den alten Request erneut zu senden. Wenn beide Sitzungen parallel funktionieren, ist das je nach Sicherheitsanforderung ein relevanter Befund.

Besonders kritisch wird es, wenn Session-IDs vorhersehbar, wiederverwendbar oder an unsichere Kontexte gebunden sind. Das führt in Richtung Session Hijacking. Repeater allein erzeugt diese Schwachstelle nicht, aber er hilft, die serverseitige Akzeptanz gestohlener oder alter Sitzungsartefakte sauber nachzuweisen. Entscheidend ist immer die Frage: Akzeptiert der Server einen Zustand, den er eigentlich verwerfen müsste?

Logout-Tests sind nur dann aussagekräftig, wenn zwischen clientseitigem und serverseitigem Verhalten unterschieden wird. Viele Anwendungen löschen beim Logout lediglich Cookies im Browser oder setzen eine Redirect-Kette in Gang. Das sieht für Benutzer korrekt aus, sagt aber nichts darüber aus, ob die Session im Backend invalidiert wurde. Der Nachweis gelingt nur, wenn ein vor dem Logout gespeicherter Request in Repeater nach dem Logout unverändert erneut gesendet wird.

Timeout-Tests sind ähnlich fehleranfällig. Ein sichtbarer Session-Timeout in der Oberfläche bedeutet nicht automatisch, dass alle Tokens abgelaufen sind. Häufig wird nur die UI in einen ausgeloggten Zustand versetzt, während API-Requests mit altem Token noch funktionieren. Deshalb sollte ein Timeout-Test immer mindestens einen Lese- und einen Schreib-Request umfassen. Ein GET auf Profildaten und ein POST auf eine zustandsändernde Aktion liefern oft unterschiedliche Ergebnisse.

• Vor dem Logout einen funktionierenden Request in Repeater sichern
• Logout oder Timeout im Browser vollständig auslösen
• Den alten Request ohne Änderungen erneut senden
• Auf Statuscode, Redirect, Response-Inhalt und Set-Cookie achten
• Zusätzlich prüfen, ob eine neue Session stillschweigend erzeugt wird

Session-Rotation nach Login oder Privilegienwechsel ist ein weiterer Kernpunkt. Nach erfolgreichem Login sollte eine neue Session-ID vergeben werden, damit eine vor dem Login bekannte ID nicht weiterverwendet werden kann. Dasselbe gilt oft nach Passwortänderung, MFA-Aktivierung oder Rollenwechsel. Repeater kann hier zwei Requests gegeneinanderstellen: einen mit der alten, einen mit der neuen Session-ID. Wenn beide denselben privilegierten Zustand repräsentieren, fehlt möglicherweise eine saubere Rotation oder Invalidation.

Bei Single-Page-Apps muss zusätzlich auf Refresh-Tokens geachtet werden. Ein Access-Token kann ablaufen, während ein Refresh-Token weiterhin neue Access-Tokens erzeugt. Wird beim Logout nur das Access-Token verworfen, bleibt die Sitzung faktisch bestehen. Solche Fälle werden oft übersehen, weil der Browser den Refresh-Prozess automatisch abwickelt. In Repeater lässt sich der Refresh-Request isolieren und mit alten Tokenwerten erneut testen.

Ein häufiger Irrtum ist, dass ein 401 nach Logout automatisch Entwarnung bedeutet. Wenn derselbe Benutzer durch einen stillen Re-Auth-Mechanismus sofort wieder eine gültige Session erhält, kann ein alter Workflow weiterhin funktionieren. Deshalb müssen nicht nur Einzelrequests, sondern komplette Request-Ketten betrachtet werden. Wer tiefer in solche Abläufe einsteigen will, sollte die Grundlagen aus API Testing und Cookies mitdenken.

Viele Fehlbewertungen entstehen, weil CSRF-Schutz und Session-Prüfung vermischt werden. Ein Request kann wegen eines ungültigen CSRF-Tokens scheitern, obwohl die Session selbst noch gültig ist. Umgekehrt kann ein Request mit gültigem CSRF-Token abgelehnt werden, weil die Session abgelaufen ist. Repeater erlaubt es, beide Mechanismen getrennt zu prüfen: erst nur Session-Cookie ändern, dann nur CSRF-Token, dann beides kombiniert. Erst daraus ergibt sich ein klares Bild.

Bei JWT-basierten Anwendungen ist besondere Vorsicht nötig. Ein JWT kann signiert und formal korrekt sein, aber veraltete Rollen oder Claims enthalten. Wenn der Server Claims direkt vertraut und keine serverseitige Revalidierung durchführt, bleiben Berechtigungen unter Umständen länger bestehen als vorgesehen. Repeater ist hier nützlich, um alte Tokens nach Rollenänderung, Logout oder Passwortwechsel erneut zu testen. Ergänzend lohnt sich ein Blick auf Jwt Testing, wenn Claims, Signaturen und Ablaufzeiten tiefer analysiert werden sollen.

Custom Header sind ein weiteres Problemfeld. Manche Anwendungen erwarten Header wie X-Auth-Token, X-User-Id, X-Tenant oder X-Requested-With und behandeln Requests je nach Vorhandensein unterschiedlich. In schlecht implementierten APIs kann ein Header sogar Teile der Autorisierung beeinflussen. Repeater macht solche Abhängigkeiten sichtbar, wenn Header einzeln entfernt, dupliziert oder manipuliert werden.

Mehrfachzustände treten auf, wenn Browser-Cookie, Local-Storage-Token und serverseitige Session parallel existieren. Dann kann ein Endpunkt auf Cookie-Basis arbeiten, ein anderer auf Bearer-Token-Basis. Das führt zu widersprüchlichen Ergebnissen, wenn nur ein Mechanismus invalidiert wird. In der Praxis sollte deshalb jeder relevante Endpunkt darauf geprüft werden, welche Authentisierungsquelle tatsächlich ausgewertet wird. Ein erfolgreicher Logout in der Weboberfläche ist wertlos, wenn API-Endpunkte mit altem Bearer-Token weiterlaufen.

POST /api/profile/update HTTP/1.1
Host: target.example
Cookie: session=7f9c2d1a8e4b6c10
Authorization: Bearer eyJhbGciOi...
X-CSRF-Token: 4c2e9a1f
Content-Type: application/json

{"email":"user@example.org"}

Bei so einem Request sind mindestens vier Hypothesen testbar: Reicht der Bearer-Token allein? Reicht das Session-Cookie allein? Ist X-CSRF-Token nur für Browser-Requests relevant? Wird der Request auch nach Logout noch akzeptiert, wenn nur einer der beiden Authentisierungsmechanismen aktiv bleibt? Genau diese Trennung verhindert falsche Schlussfolgerungen.

Ein typischer Fall aus Webanwendungen mit Kundenportal: Nach dem Logout wird der Benutzer auf /login umgeleitet. Ein zuvor in Repeater gespeicherter GET /api/account weiterhin mit altem session-Cookie liefert jedoch noch Name, Adresse und Vertragsdaten. Der Befund ist nicht einfach nur „Logout unvollständig“, sondern konkret: serverseitige Session-Invaliderung fehlt oder greift nicht für den API-Endpunkt. Das ist reproduzierbar, klar abgrenzbar und technisch belastbar.

Ein zweites Beispiel betrifft Rollenwechsel. Ein Administrator entzieht einem Benutzer eine Berechtigung, etwa den Zugriff auf Exportfunktionen. Im Browser verschwindet der Menüpunkt sofort. Ein alter POST /export/report in Repeater funktioniert jedoch weiterhin mit derselben Session. Hier liegt das Problem meist darin, dass Rollen beim Login in die Session geschrieben und danach nicht mehr gegen die aktuelle Berechtigungslage geprüft werden.

Ein drittes Beispiel findet sich oft bei mobilen Backends und SPAs. Der Browser-Logout löscht nur das Session-Cookie, aber ein im Local Storage abgelegter Bearer-Token bleibt gültig. Repeater zeigt dann, dass /api/orders mit Authorization-Header weiterhin Daten liefert, obwohl die Weboberfläche ausgeloggt ist. Solche Fälle wirken auf den ersten Blick wie UI-Bugs, sind aber in Wahrheit Sicherheitsprobleme in der Trennung von Frontend und API.

Auch Race-ähnliche Situationen lassen sich manuell vorbereiten. Wenn ein Passwort geändert oder MFA aktiviert wird, sollte die alte Session häufig invalidiert werden. Ein in Repeater vorbereiteter Request kann unmittelbar nach der Änderung erneut gesendet werden. Wird er noch akzeptiert, ist die Session-Bindung an sicherheitsrelevante Zustandsänderungen unzureichend. Für umfangreichere Varianten kann später Intruder ergänzend eingesetzt werden, aber der erste Nachweis gelingt oft schon mit Repeater.

Wer konkrete Request-Muster sehen will, findet in Repeater Beispiele zusätzliche Szenarien. Entscheidend bleibt jedoch immer die Interpretation: Nicht jeder erfolgreiche alte Request ist automatisch kritisch. Die Bewertung hängt davon ab, welche Sicherheitsanforderung verletzt wird, welche Daten betroffen sind und ob der Zustand nach Logout, Timeout oder Rechteänderung eigentlich hätte beendet sein müssen.

Der häufigste Fehler ist ein unsauberer Ausgangszustand. Wenn mehrere Tabs offen sind, automatische Token-Refreshes laufen oder der Browser im Hintergrund neue Sessions erzeugt, wird das Ergebnis unbrauchbar. Repeater selbst arbeitet deterministisch, aber die Testumgebung oft nicht. Deshalb sollten Session-Tests in einer kontrollierten Umgebung stattfinden: definierter Benutzer, definierter Login-Zeitpunkt, möglichst keine parallelen Aktionen.

Ein weiterer Fehler ist die Fixierung auf Statuscodes. Anwendungen antworten bei Session-Problemen oft mit 200, liefern aber HTML statt JSON, ein leeres Objekt statt Daten oder eine Login-Maske im Response-Body. Wer nur auf 200, 302 oder 401 schaut, übersieht reale Unterschiede. Response-Länge, Content-Type, Redirect-Ziele, Set-Cookie-Header und semantischer Inhalt müssen gemeinsam gelesen werden.

Ebenso problematisch ist das gleichzeitige Verändern mehrerer Parameter. Wenn Cookie, CSRF-Token und Header zusammen geändert werden, lässt sich nicht mehr sagen, welcher Faktor den Unterschied verursacht hat. Gute Session-Tests sind kleinteilig. Jede Änderung prüft genau eine Hypothese. Das kostet anfangs etwas mehr Zeit, spart aber später Diskussionen bei der Bewertung.

• Keine Referenzantwort dokumentiert und daher keine belastbare Vergleichsbasis
• Logout nur im Browser beobachtet, aber alte Requests nicht erneut getestet
• API- und UI-Endpunkte vermischt, obwohl sie unterschiedliche Prüfungen haben
• Automatische Token-Erneuerung übersehen und dadurch falsche Schlüsse gezogen
• Nur sichtbare Oberfläche bewertet statt serverseitige Akzeptanz nachzuweisen

Auch Caching kann Ergebnisse verfälschen. Ein GET-Request auf statische oder halb-statische Inhalte kann aus Cache-Schichten bedient werden und dadurch den Eindruck erwecken, eine Session sei noch gültig. Deshalb sollten für Session-Tests bevorzugt Endpunkte gewählt werden, die eindeutig benutzerspezifische, dynamische Daten liefern oder serverseitige Aktionen auslösen. Alternativ helfen Cache-Control-Header und ein kritischer Blick auf Response-Metadaten.

Schließlich wird oft vergessen, dass Session-Tests nicht isoliert von Autorisierung betrachtet werden dürfen. Wenn ein Request trotz abgelaufener Session funktioniert, weil der Endpunkt ohnehin öffentlich ist, liegt kein Session-Problem vor. Wenn ein Request mit fremder Objekt-ID funktioniert, obwohl die Session korrekt ist, handelt es sich eher um ein Autorisierungsproblem. Die Trennlinie ist wichtig, damit Befunde technisch sauber bleiben.

Ein guter Session-Befund steht und fällt mit der Reproduzierbarkeit. Es reicht nicht, dass ein alter Request „irgendwie noch ging“. Dokumentiert werden müssen Ausgangszustand, Benutzerrolle, Zeitpunkt des Logins, betroffener Endpunkt, verwendete Session-Artefakte, exakter Logout- oder Timeout-Schritt und die Unterschiede zwischen Referenz- und Testantwort. Nur so lässt sich später nachvollziehen, ob tatsächlich eine Sicherheitsgrenze verletzt wurde.

Hilfreich ist eine einfache Struktur pro Testfall: Ziel des Tests, Referenzrequest, erwartetes Verhalten, tatsächliches Verhalten, technische Auswirkung. Bei Session-Themen sollte zusätzlich festgehalten werden, ob der Fehler nur einen einzelnen Endpunkt betrifft oder systematisch mehrere Bereiche. Ein isolierter API-Endpunkt mit fehlender Invalidation ist anders zu bewerten als eine global weiter gültige Sitzung nach Logout.

Für die technische Beweiskette sind Screenshots allein selten ausreichend. Besser sind gespeicherte Requests und Responses, idealerweise mit markierten Unterschieden. Wenn ein alter Request nach Logout weiterhin personenbezogene Daten liefert, sollte genau dieser Response dokumentiert werden. Wenn nur Redirects oder Set-Cookie-Header abweichen, muss das ebenfalls sichtbar sein. Präzision ist hier wichtiger als Menge.

Auch die Risikobewertung sollte technisch begründet sein. Relevante Fragen sind: Ermöglicht der Fehler Zugriff auf sensible Daten? Bleiben zustandsändernde Aktionen möglich? Betrifft das nur denselben Benutzer oder auch fremde Konten? Ist ein Angreifer auf lokale Browserkontrolle angewiesen oder reicht ein abgegriffenes Token? Solche Punkte entscheiden darüber, ob aus einem Session-Fehler ein kritischer Befund wird.

In professionellen Assessments gehört außerdem dazu, Gegenproben durchzuführen. Wenn ein alter Request nach Logout noch funktioniert, sollte geprüft werden, ob das für weitere Endpunkte ebenfalls gilt. Wenn eine Session nach Passwortwechsel aktiv bleibt, sollte getestet werden, ob auch sicherheitsrelevante Aktionen wie E-Mail-Änderung, Export oder API-Zugriff weiter möglich sind. Erst diese Breite macht aus einem Einzelbeobachtung einen belastbaren Nachweis über die Qualität der Session-Architektur.

Wer Burp insgesamt strukturierter einsetzen will, profitiert von einer sauberen Basis in Anleitung, einem klaren Verständnis des Interface und einem disziplinierten Vorgehen im Web Pentest. Session-Tests sind kein isolierter Spezialfall, sondern ein Kernbestandteil jeder ernsthaften Prüfung authentisierter Anwendungen.