Login Testing: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Login Testing wird oft auf Benutzername und Passwort reduziert. In realen Anwendungen ist das zu kurz gedacht. Ein Login besteht fast nie nur aus einem POST auf /login. Moderne Anwendungen arbeiten mit vorgelagerten CSRF-Tokens, JavaScript-generierten Parametern, Redirect-Ketten, Anti-Automation-Mechanismen, Device-IDs, Session-Vorinitialisierung, SSO-Komponenten oder API-basierten Authentifizierungsaufrufen. Wer nur den sichtbaren Request testet, übersieht häufig die eigentliche Sicherheitslogik.

Der erste Schritt ist deshalb immer die saubere Rekonstruktion des gesamten Flows. Das beginnt mit einer frischen Session im Browser, sauberem Mitschnitt über Proxy und einer klaren Scope-Definition. Danach wird beobachtet, welche Requests vor dem eigentlichen Login stattfinden, welche Cookies gesetzt werden, ob ein Preflight-Request existiert, ob Hidden Fields dynamisch erzeugt werden und ob die Anwendung zwischen Browser-Login und API-Login unterscheidet. Gerade Single-Page-Applications senden Credentials oft an JSON-Endpunkte, während das sichtbare Formular nur ein Frontend-Wrapper ist.

Ein belastbarer Workflow startet mit einer Baseline: gültiger Login, ungültiger Login, gesperrter Benutzer, leerer Benutzername, leeres Passwort, Sonderzeichen, sehr lange Eingaben und Wiederholung desselben Requests mit identischer Session. Diese Vergleichswerte sind später entscheidend, um Unterschiede in Statuscode, Response-Länge, Redirect-Verhalten, Cookie-Rotation und Fehlermeldungen zu erkennen. Für diese Vergleichsarbeit ist Repeater das zentrale Werkzeug, weil sich Requests kontrolliert variieren lassen, ohne dass Browser-Logik dazwischenfunkt.

Wichtig ist auch die Frage, wo Authentifizierung tatsächlich entschieden wird. Manche Anwendungen prüfen Credentials serverseitig klassisch gegen eine Datenbank. Andere delegieren an Identity Provider, LDAP, OAuth oder JWT-basierte APIs. Wieder andere nutzen Mischformen: Web-Frontend mit Session-Cookie, Mobile-API mit Bearer-Token, Admin-Panel mit zusätzlichem MFA-Schritt. Login Testing muss diese Trennung verstehen, sonst werden Symptome getestet statt Ursachen.

Ein häufiger Fehler in Assessments ist das blinde Senden von Intruder-Angriffen auf den ersten sichtbaren Login-Request. Wenn dabei CSRF-Tokens, Nonces oder Session-Bindungen ignoriert werden, produziert der Test nur Fehlrauschen. Zuerst muss geklärt werden, welche Parameter statisch, welche dynamisch und welche serverseitig an die Session gebunden sind. Ebenso relevant ist, ob die Anwendung Fehlversuche pro Konto, pro IP, pro Session oder pro Device zählt. Ohne dieses Verständnis ist keine Aussage über Brute-Force-Schutz, Enumeration oder Lockout-Verhalten belastbar.

In der Praxis lohnt sich ein strukturierter Blick auf vier Ebenen: Eingabevalidierung, Authentifizierungsentscheidung, Session-Erzeugung und Nach-Login-Autorisierung. Viele kritische Schwachstellen liegen nicht im Passwortvergleich selbst, sondern in den Übergängen dazwischen. Ein Login kann formal korrekt abgesichert sein und trotzdem durch Session Fixation, unsaubere Redirect-Logik oder unvollständige Zustandsprüfungen angreifbar bleiben. Genau deshalb überschneidet sich Login Testing fast immer mit Session Management, Cookies und in modernen Umgebungen auch mit Jwt Testing.

Bevor Requests manipuliert werden, muss die Testumgebung stabil sein. Dazu gehört ein korrekt eingerichteter Proxy, ein funktionierendes Zertifikat für HTTPS-Traffic und ein Projektzustand, in dem keine Altlasten aus früheren Sessions stören. Wer Burp nur halb konfiguriert, produziert unvollständige Mitschnitte, verpasst Redirects oder interpretiert Browserfehler als Sicherheitsmechanismen. Falls die Umgebung noch nicht sauber steht, sind Proxy Einrichten und Zertifikat Installieren die Grundlage.

Für Login Testing sollte nach Möglichkeit ein frisches Browserprofil verwendet werden. Persistente Cookies, gespeicherte Tokens, Autofill-Daten oder Service-Worker-Caches verfälschen Ergebnisse. Besonders bei SPAs und SSO-Flows kann ein bereits vorhandener Refresh-Token dazu führen, dass der sichtbare Login gar nicht mehr vollständig durchlaufen wird. Ein sauberer Start bedeutet: Browserprofil neu, Burp-Projekt frisch, Scope gesetzt, unnötige Hosts gefiltert und der erste Durchlauf nur zur Beobachtung.

Im Proxy-Verlauf wird anschließend nicht nur der Login-POST betrachtet, sondern die gesamte Sequenz. Dazu gehören GET auf die Login-Seite, Laden von Konfigurationsendpunkten, Abruf von CSRF-Tokens, JavaScript-Requests, CORS-Preflights, Redirects nach erfolgreicher Anmeldung und API-Calls, die den eingeloggten Zustand bestätigen. Gerade bei komplexen Anwendungen ist der erste erfolgreiche Login die wichtigste Referenzaufnahme des gesamten Tests.

• Vor dem Test alle Cookies und lokalen Speicherwerte löschen oder ein neues Browserprofil verwenden.
• Den Scope auf die Zielanwendung begrenzen, damit History und Scanner nicht mit Fremdtraffic überlaufen.
• Einen gültigen und einen ungültigen Login vollständig mitschneiden und beide Requests separat markieren.
• Session-Cookies, CSRF-Parameter, Redirect-Ziele und Response-Unterschiede sofort dokumentieren.

Ein weiterer Kernpunkt ist Reproduzierbarkeit. Ein Test ist nur dann belastbar, wenn derselbe Request unter kontrollierten Bedingungen erneut gesendet werden kann. Deshalb werden relevante Requests frühzeitig an Repeater Anleitung oder an den Proxy-Editor übergeben. Dort lässt sich prüfen, ob der Request isoliert funktioniert oder ob zusätzliche Vorbedingungen nötig sind. Wenn ein Login im Browser klappt, im Repeater aber nicht, liegt das meist an fehlenden Cookies, abgelaufenen Tokens, Headern wie Origin oder Referer oder an einem vorgelagerten Initialisierungsrequest.

Auch die Response-Bewertung muss systematisch erfolgen. Statuscode allein reicht nicht. Viele Anwendungen liefern bei Erfolg und Misserfolg denselben 200-Status, unterscheiden sich aber in Body-Länge, JSON-Feldern, Redirect-Zielen oder Set-Cookie-Headern. Andere geben bei ungültigen Zugangsdaten bewusst generische Meldungen aus, verraten aber über Timing, Header oder Account-spezifische Nebeneffekte dennoch zu viel. Wer Login Testing ernsthaft betreibt, arbeitet deshalb immer mit mehreren Vergleichsmerkmalen gleichzeitig.

Ein Login-Request besteht aus mehr als zwei Feldern. In klassischen Formularen sind Benutzername, Passwort und CSRF-Token sichtbar. In moderneren Anwendungen kommen JSON-Strukturen, verschachtelte Objekte, Device-Fingerprints, Captcha-Tokens, Client-Nonce, Mandanten-IDs, Return-URLs oder versteckte Workflow-Parameter hinzu. Jeder dieser Werte kann sicherheitsrelevant sein. Die Aufgabe besteht darin, zwischen dekorativen und entscheidenden Parametern zu unterscheiden.

Im Repeater wird der Request daher schrittweise reduziert. Zuerst bleibt alles unverändert, um die Baseline zu bestätigen. Danach werden einzelne Header entfernt oder verändert: Origin, Referer, X-Requested-With, Content-Type, Accept, User-Agent. Anschließend folgen Parameter-Tests: Was passiert ohne CSRF-Token? Was passiert mit leerem Token, altem Token, Token aus anderer Session oder doppelt gesendetem Token? Wird der Request serverseitig abgelehnt oder nur clientseitig geschützt? Genau hier zeigen sich oft Implementierungsfehler, die im Browser unsichtbar bleiben.

Besonders wichtig ist die Bindung zwischen Token und Session. Ein CSRF-Token ist nur dann sinnvoll, wenn es an eine Session oder einen serverseitigen Zustand gekoppelt ist. Wenn ein Token global gültig, vorhersagbar oder wiederverwendbar ist, kann der Schutz faktisch wirkungslos sein. Dasselbe gilt für Login-Nonces oder Challenge-Werte. Viele Anwendungen generieren zwar dynamische Werte, prüfen sie aber nicht konsequent. Ein schneller Test besteht darin, einen erfolgreichen Login-Request zu duplizieren und nur den Token zu verändern, während alle übrigen Werte gleich bleiben.

Header sind ebenfalls nicht nur Beiwerk. Manche Backends unterscheiden Browser- und API-Login anhand von Content-Type oder Accept. Andere aktivieren Schutzmechanismen nur, wenn Origin oder Referer fehlen. Wieder andere verlassen sich auf X-Forwarded-For oder proprietäre Header, um Rate Limits oder interne Vertrauenszonen zu steuern. Solche Konstruktionen sind fehleranfällig und führen regelmäßig zu Inkonsistenzen zwischen Web- und API-Authentifizierung. Wer parallel auch API Testing betrachtet, erkennt diese Unterschiede deutlich schneller.

Ein typisches Beispiel für die Zerlegung eines JSON-Logins sieht so aus:

POST /api/auth/login HTTP/1.1
Host: target.example
Content-Type: application/json
Origin: https://target.example
Cookie: pre_session=8f2c...

{
  "username": "alice@example.com",
  "password": "WrongPass123!",
  "csrfToken": "9d7b1...",
  "deviceId": "web-01",
  "rememberMe": false
}

Aus diesem Request ergeben sich sofort mehrere Testfragen: Ist username case-sensitiv? Wird password serverseitig normalisiert? Ist csrfToken an pre_session gebunden? Kann deviceId frei gewählt werden? Hat rememberMe Einfluss auf Cookie-Laufzeiten oder Token-Typen? Wird bei falschem Passwort dieselbe Session weiterverwendet oder rotiert der Server den Zustand? Solche Fragen sind nicht akademisch. Sie entscheiden darüber, ob Angriffe wie Enumeration, Session Fixation oder Bypass-Varianten realistisch sind.

Auch Redirect-Parameter verdienen Aufmerksamkeit. Viele Login-Flows akzeptieren returnTo, next, redirect_uri oder ähnliche Felder. Diese Parameter sind nicht nur für Open Redirects relevant, sondern auch für Logikfehler nach erfolgreicher Authentifizierung. Wenn ein System nach dem Login ungeprüft auf interne Pfade oder privilegierte Bereiche weiterleitet, lässt sich daraus oft ableiten, wie Autorisierung intern modelliert ist. Das ist ein guter Übergang zu tieferen Prüfungen wie Authentication Bypass.

Viele Anwendungen verraten mehr über den Login-Prozess, als beabsichtigt ist. Der Klassiker ist Benutzer-Enumeration. Dabei unterscheidet das System zwischen unbekanntem Benutzer und falschem Passwort, sei es über Text, Statuscode, Redirect, Antwortzeit oder Nebeneffekte wie Passwort-Reset-Hinweise. Selbst wenn die sichtbare Meldung generisch formuliert ist, können Response-Länge, Header oder Timing Unterschiede offenlegen. Deshalb werden immer mehrere Kontotypen getestet: existierend, nicht existierend, deaktiviert, gesperrt, noch nicht aktiviert und mit MFA erzwungen.

Timing ist dabei besonders heikel. Wenn ein existierender Benutzer einen teuren Passwort-Hash-Vergleich auslöst, ein nicht existierender Benutzer aber sofort abgelehnt wird, entsteht ein messbarer Unterschied. In kleinen Stichproben ist das oft verrauscht, bei wiederholten Requests aber klar erkennbar. Solche Unterschiede sind nicht immer trivial ausnutzbar, aber sie zeigen, dass die Implementierung intern unterschiedlich verzweigt. Das ist ein Warnsignal für weitere Logikfehler.

Lockout-Mechanismen werden ebenfalls häufig falsch bewertet. Ein System kann nach fünf Fehlversuchen sperren und trotzdem unsicher sein, wenn die Sperre nur pro Session zählt, sich durch Cookie-Wechsel umgehen lässt oder nur für das Web-Frontend gilt, nicht aber für die API. Ebenso problematisch sind Lockouts, die Benutzerkonten gezielt lahmlegen lassen. Dann wird aus einem Schutzmechanismus ein Denial-of-Service-Vektor gegen einzelne Accounts. Die Bewertung hängt also nicht nur davon ab, ob ein Lockout existiert, sondern wie er technisch umgesetzt ist.

Ein sauberer Test betrachtet deshalb mindestens folgende Unterschiede zwischen Erfolg und Misserfolg:

• Statuscode, Redirect-Kette und Ziel-URL nach dem Request.
• Response-Länge, JSON-Felder, Fehlermeldungstexte und Template-Unterschiede.
• Set-Cookie-Header, Session-Rotation und Ablaufzeiten.
• Antwortzeit bei existierenden und nicht existierenden Benutzern.
• Verhalten nach mehreren Fehlversuchen aus derselben und aus neuer Session.

Auch Passwort-Policy-Fehler tauchen im Login-Kontext auf. Manche Systeme schneiden Eingaben stillschweigend ab, normalisieren Unicode uneinheitlich oder behandeln führende und nachgestellte Leerzeichen inkonsistent. Das kann dazu führen, dass ein Benutzer im Registrierungsprozess ein Passwort mit Sonderzeichen setzt, der Login-Prozess aber intern eine andere Normalisierung verwendet. Solche Fehler wirken zunächst wie Usability-Probleme, können aber in Einzelfällen zu Account-Verwechslungen oder unerwarteten Authentifizierungszuständen führen.

Ein weiterer Klassiker ist die inkonsistente Behandlung von Groß- und Kleinschreibung im Benutzernamen. E-Mail-Adressen werden oft case-insensitiv erwartet, intern aber nicht überall gleich verarbeitet. Wenn Registrierung, Login, Passwort-Reset und Audit-Logging unterschiedliche Normalisierung verwenden, entstehen schwer nachvollziehbare Zustände. In Assessments zeigt sich das häufig dadurch, dass alice@example.com und Alice@example.com in verschiedenen Endpunkten unterschiedlich behandelt werden.

Für solche Vergleiche ist der kombinierte Einsatz von Repeater und Comparer besonders effektiv. Requests und Responses lassen sich nebeneinander auswerten, ohne sich auf Bauchgefühl zu verlassen. Gerade bei minimalen Unterschieden in Headern oder Body-Strukturen spart das viel Zeit und verhindert Fehldeutungen.

Login Testing umfasst fast immer die Frage, wie widerstandsfähig ein System gegen wiederholte Anmeldeversuche ist. Dabei reicht es nicht, einfach viele Passwörter zu senden. Zuerst muss verstanden werden, welche Schutzmechanismen aktiv sind: feste Sperren, progressive Delays, Captcha nach Schwellenwert, IP-basierte Limits, kontoabhängige Limits, Device-Bindung, WAF-Regeln oder verhaltensbasierte Erkennung. Ein Test ohne dieses Verständnis liefert nur die Aussage, dass irgendwann eine Blockade auftritt, nicht aber, wie belastbar sie ist.

Mit Intruder lassen sich solche Prüfungen kontrolliert durchführen, aber nur mit sauberer Vorbereitung. Dynamische Tokens müssen berücksichtigt, parallele Requests bewusst gewählt und Auswertungskriterien vorab definiert werden. Bei Login-Endpunkten ist die wichtigste Frage nicht nur, ob ein Versuch blockiert wird, sondern woran Erfolg oder Misserfolg erkennbar ist. Viele Anwendungen antworten bei Blockaden weiterhin mit 200, setzen aber ein Flag im JSON oder liefern eine andere Fehlermeldung. Wer nur nach Statuscode filtert, übersieht das.

Ein realistischer Test trennt mehrere Szenarien: viele Passwörter gegen einen Benutzer, ein Passwort gegen viele Benutzer, verteilte Versuche über neue Sessions, Wechsel der IP falls autorisiert und technisch zulässig, sowie Wiederholung nach Wartezeit. Dadurch lässt sich unterscheiden, ob Limits benutzerzentriert, sessionspezifisch oder netzwerkbasiert sind. Besonders schwach sind Implementierungen, die Limits nur auf Client-Seite oder nur im sichtbaren Web-Formular erzwingen, während der zugrunde liegende API-Endpunkt frei ansprechbar bleibt.

Ein einfaches Beispiel für einen Intruder-tauglichen Request:

POST /login HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Cookie: csrf_session=ab31...

username=alice@example.com&password=§PASS§&csrf=7f9c2...

Dieser Request ist nur dann sinnvoll angreifbar, wenn csrf stabil oder automatisiert erneuerbar ist. Wenn das Token pro Versuch neu generiert werden muss, wird ein naiver Angriff scheitern. Dann muss zuerst geklärt werden, ob Burp-Makros, Session-Handling-Regeln oder ein anderer Workflow nötig sind. Ohne diese Anpassung misst der Test nur Token-Ablauf, nicht die Stärke des Login-Schutzes.

Ebenso wichtig ist die Unterscheidung zwischen Brute Force und Credential Stuffing. Bei Brute Force wird ein Konto mit vielen Passwörtern getestet. Bei Credential Stuffing werden bekannte Kombinationen aus Leaks gegen viele Konten geprüft. Schutzmechanismen reagieren auf beide Muster oft unterschiedlich. Ein System kann Brute Force gegen ein einzelnes Konto gut erkennen, aber verteilte Versuche mit jeweils einem Passwort pro Benutzer kaum. Diese Unterschiede sind sicherheitsrelevant, weil reale Angriffe selten nur einem simplen Muster folgen.

Bei allen Tests gilt: keine unkontrollierten Lastspitzen, keine unnötige Kontosperrung produktiver Benutzer und klare Freigabegrenzen. Login-Endpunkte sind betriebsnah und sensibel. Saubere Testraten, definierte Testkonten und dokumentierte Abbruchkriterien sind Pflicht. Wer methodisch arbeitet, bekommt belastbare Ergebnisse, ohne die Anwendung zu destabilisieren.

Ein erfolgreicher Login endet nicht mit der Meldung „Willkommen“. Der sicherheitskritische Teil beginnt oft erst danach: Welche Session wird erzeugt, welche alte Session bleibt bestehen, welche Cookies ändern sich und welche Rechte werden an welchen Zustand gebunden? Viele Anwendungen authentifizieren korrekt, versagen aber bei der Session-Härtung. Das führt zu Session Fixation, unvollständiger Session-Rotation oder inkonsistentem Logout-Verhalten.

Der Kerncheck ist einfach: Vor dem Login wird die anonyme Session dokumentiert, nach dem Login werden alle Set-Cookie-Header und vorhandenen Cookies verglichen. Eine sichere Anwendung sollte die relevante Session-ID nach erfolgreicher Authentifizierung rotieren oder einen neuen authentifizierten Zustand erzeugen, der nicht auf einer vorab kontrollierbaren Kennung basiert. Wenn dieselbe Session-ID vor und nach dem Login bestehen bleibt, ist das zumindest prüfungswürdig und in vielen Fällen ein echtes Risiko.

Besonders problematisch sind Anwendungen, die mehrere Cookies parallel nutzen: ein Tracking-Cookie, ein Pre-Session-Cookie, ein Auth-Cookie und vielleicht noch ein CSRF-Cookie. Dann muss klar sein, welches Cookie tatsächlich den eingeloggten Zustand trägt. Nicht selten rotiert nur ein unkritisches Cookie, während die eigentliche Session stabil bleibt. Solche Fehler werden übersehen, wenn nur auf den ersten Set-Cookie-Header geschaut wird.

Ein typischer Vergleich sieht so aus:

Vor Login:
Set-Cookie: session=anon_4f2a...; HttpOnly; Secure
Set-Cookie: csrf=9c1d...

Nach Login:
Set-Cookie: session=anon_4f2a...; HttpOnly; Secure
Set-Cookie: auth=1; HttpOnly; Secure

Wenn die Session-ID unverändert bleibt und nur ein zusätzliches Flag gesetzt wird, muss geprüft werden, ob eine vorab gesetzte Session von einem Angreifer kontrolliert oder vorhersehbar beeinflusst werden kann. Genau daraus entsteht Session Fixation. In Burp lässt sich das testen, indem eine anonyme Session bewusst stabil gehalten, der Login durchgeführt und anschließend geprüft wird, ob dieselbe Kennung nun authentifiziert ist. Vertiefend ist hier Repeater Session Test relevant.

Auch Cookie-Attribute gehören zur Bewertung: HttpOnly, Secure, SameSite, Domain, Path und Ablaufzeit. Ein Login-Cookie ohne Secure auf HTTPS ist ein klarer Befund. SameSite ist vor allem im Zusammenspiel mit CSRF-Schutz relevant. Domain- und Path-Attribute entscheiden darüber, ob Cookies unnötig breit im Anwendungskontext verfügbar sind. Lange Laufzeiten bei „remember me“-Funktionen müssen gesondert betrachtet werden, insbesondere wenn keine zusätzliche Gerätebindung oder Re-Authentifizierung für sensible Aktionen existiert.

Nach dem Login sollte außerdem geprüft werden, ob privilegierte Zustände korrekt getrennt sind. Manche Anwendungen setzen nach normalem Login eine Basissession und aktivieren erhöhte Rechte erst nach zusätzlicher Bestätigung. Andere markieren Rollen direkt im Cookie oder Token. Wenn diese Übergänge unsauber implementiert sind, entstehen Möglichkeiten für Rechteausweitung oder Session-Missbrauch. Login Testing endet deshalb nie am ersten erfolgreichen Zugriff auf das Dashboard.

Viele aktuelle Anwendungen nutzen keine klassische serverseitige Session als primären Authentifizierungsmechanismus. Stattdessen werden Access Tokens, Refresh Tokens, ID Tokens oder externe Identity Provider eingesetzt. Dadurch verschiebt sich der Fokus des Login Testings. Nicht mehr nur das Formular ist relevant, sondern der gesamte Token-Lebenszyklus: Ausgabe, Speicherung, Weitergabe, Erneuerung, Widerruf und Bindung an Client oder Kontext.

Bei JWT-basierten Anwendungen muss zuerst geklärt werden, ob das Token nur ein Transportformat oder tatsächlich die Autorisierungsquelle ist. Ein JWT kann signiert, aber inhaltlich überprivilegiert sein. Es kann korrekt validiert, aber unsicher gespeichert werden. Es kann ablaufen, aber über einen schwach geschützten Refresh-Mechanismus beliebig erneuert werden. Deshalb gehört zum Login Testing moderner Anwendungen fast immer auch ein Blick auf Jwt Testing und auf die Frage, ob Claims wie role, sub, aud, iss oder exp sauber geprüft werden.

OAuth- und OIDC-Flows bringen zusätzliche Fehlerklassen mit: unsaubere redirect_uri-Prüfung, fehlende state-Validierung, schwache PKCE-Umsetzung, Token-Leaks über Browser-History oder Referrer und Verwechslung zwischen Frontchannel- und Backchannel-Logik. Wer nur den finalen Token-Request betrachtet, verpasst oft die eigentliche Schwachstelle im Autorisierungsfluss. Deshalb muss der gesamte Redirect- und Token-Austausch mitgeschnitten und logisch rekonstruiert werden. Für diese Fälle ist Oauth Testing die passende Vertiefung.

Auch SPAs mit Backend-for-Frontend-Architektur sind tückisch. Das sichtbare Login kann Credentials an einen internen API-Endpunkt senden, der wiederum mit einem Identity Service spricht. Danach landet ein Session-Cookie im Browser, obwohl intern JWTs verwendet werden. In solchen Konstruktionen muss klar getrennt werden, welche Komponente welche Sicherheitsentscheidung trifft. Sonst wird ein Token-Problem fälschlich als Formularproblem oder umgekehrt bewertet.

• Prüfen, wo Tokens gespeichert werden: Cookie, Local Storage, Session Storage oder In-Memory.
• Access- und Refresh-Token getrennt bewerten, insbesondere Laufzeit und Widerrufsverhalten.
• Claims nicht nur dekodieren, sondern gegen serverseitige Prüfungen und Rollenlogik testen.
• Bei OAuth den vollständigen Redirect-Flow inklusive state, nonce und redirect_uri nachvollziehen.

Ein häufiger Praxisfehler ist die Verwechslung von Dekodierung und Validierung. Ein JWT lässt sich leicht lesen, aber daraus folgt nicht, dass es manipulierbar ist. Umgekehrt ist ein korrekt signiertes Token nicht automatisch sicher, wenn sensible Claims blind vertraut oder Tokens an unsicheren Stellen gespeichert werden. Für die Analyse einzelner Token-Bestandteile kann Decoder nützlich sein, die eigentliche Sicherheitsbewertung entsteht aber erst durch kontrollierte Manipulation und serverseitige Reaktion.

Moderne Login-Architekturen verlangen deshalb mehr als Formularfuzzing. Sie erfordern Verständnis für Protokolle, Zustandswechsel und Vertrauensgrenzen zwischen Browser, Frontend, Backend und Identity Provider. Genau dort liegen heute viele der interessanten Befunde.

Der Repeater ist beim Login Testing das präziseste Werkzeug, weil sich einzelne Hypothesen isoliert prüfen lassen. Statt sofort große Angriffsmengen zu senden, wird der Login-Request manuell zerlegt. Das Ziel ist nicht Geschwindigkeit, sondern Verständnis. Ein guter Repeater-Workflow beginnt mit einer unveränderten Kopie des erfolgreichen und des fehlgeschlagenen Requests. Danach werden Änderungen immer einzeln vorgenommen, damit Ursache und Wirkung klar bleiben.

Ein sinnvoller Ablauf ist: zuerst nur Passwort ändern, dann nur Benutzername, dann Token, dann Cookies, dann Header, dann Reihenfolge oder Duplikation von Parametern. Viele Frameworks verarbeiten doppelte Parameter unerwartet, etwa indem der erste oder letzte Wert gewinnt. Wenn Login-Parameter mehrfach gesendet werden können, lohnt sich ein Test auf Parser-Differenzen zwischen Reverse Proxy, WAF und Anwendung. Solche Inkonsistenzen sind selten, aber hochinteressant.

Auch Content-Type-Manipulationen sind praxisrelevant. Manche Endpunkte akzeptieren sowohl application/x-www-form-urlencoded als auch application/json, validieren aber nur einen Pfad sauber. Andere reagieren auf GET, obwohl nur POST vorgesehen ist. Wieder andere ignorieren unbekannte Felder nicht, sondern überschreiben interne Zustände. Solche Unterschiede zeigen, wie robust die Authentifizierungslogik wirklich ist.

Beispiel für einen gezielten Header- und Parameter-Test:

POST /api/login HTTP/1.1
Host: target.example
Content-Type: application/json
Origin: https://evil.example
Cookie: pre_session=8f2c...

{
  "username": "alice@example.com",
  "password": "CorrectPassword!",
  "csrfToken": "",
  "rememberMe": true,
  "role": "admin"
}

Dieser Request prüft mehrere Dinge gleichzeitig, sollte aber in der Praxis in Einzeltests zerlegt werden: Wird Origin geprüft? Ist csrfToken wirklich erforderlich? Wird rememberMe serverseitig kontrolliert? Wird ein zusätzliches role-Feld ignoriert oder unsauber verarbeitet? Gerade bei JSON-APIs tauchen immer wieder Fälle auf, in denen unerwartete Felder intern gemappt werden oder Debug-Logik aktivieren.

Ein weiterer starker Test ist die Wiederverwendung alter Requests. Ein erfolgreicher Login-Request wird gespeichert und später mit derselben Session, mit neuer Session und nach Logout erneut gesendet. Wenn alte Requests unerwartet wieder funktionieren, kann das auf schwache Nonce-Prüfung, Replay-Probleme oder unvollständige Invalidierung hinweisen. Dasselbe gilt für Passwort-Reset- oder MFA-Übergänge, sofern sie Teil des Login-Flows sind.

Für fortgeschrittene Analysen lohnt sich außerdem der Vergleich zwischen Browser-Verhalten und manuellem Request. Wenn der Browser nach Login zusätzliche API-Calls ausführt, die Rechte oder Profilzustand laden, kann ein scheinbar erfolgreicher Login im Repeater in Wahrheit unvollständig sein. Dann muss geklärt werden, ob die Authentifizierung selbst erfolgreich war oder nur der erste Schritt eines mehrstufigen Zustandswechsels. Genau solche Details trennen oberflächliche von belastbaren Befunden.

Viele falsche Befunde entstehen nicht durch fehlende Technik, sondern durch unsauberen Workflow. Ein klassischer Fehler ist die Annahme, dass ein 200-Status einen erfolgreichen Login bedeutet. In vielen Anwendungen liefert auch ein Fehlversuch 200 und signalisiert den Fehler nur im Body. Umgekehrt kann ein 302-Redirect sowohl Erfolg als auch Misserfolg bedeuten. Ohne Baseline-Vergleich sind solche Signale wertlos.

Ebenso problematisch ist das Testen mit abgelaufenen oder fremden Tokens. Wenn ein Request im Repeater fehlschlägt, wird oft vorschnell ein Schutzmechanismus vermutet. Tatsächlich ist häufig nur das CSRF-Token ungültig oder die Session nicht mehr synchron. Deshalb muss vor jeder Aussage klar sein, welche Werte dynamisch sind und wie lange sie gültig bleiben. Wer das nicht prüft, verwechselt normale Zustandslogik mit Sicherheitskontrolle.

Ein weiterer häufiger Irrtum betrifft Browser-seitige Sperren. Wenn das Frontend nach mehreren Fehlversuchen einen Button deaktiviert oder ein Captcha einblendet, ist damit noch nichts über den zugrunde liegenden Endpunkt gesagt. Entscheidend ist, ob dieselbe Logik serverseitig erzwungen wird. Genau deshalb wird jeder sichtbare Schutz immer direkt am Request getestet, nicht nur im UI beobachtet.

Auch Caching und parallele Sessions verfälschen Ergebnisse. Ein Benutzer kann im Browser bereits eingeloggt sein, während im Repeater mit einer alten Session gearbeitet wird. Oder ein Service Worker liefert eine gecachte Login-Seite mit veraltetem Token. Solche Effekte sehen auf den ersten Blick wie inkonsistente Sicherheitslogik aus, sind aber reine Testartefakte. Saubere Trennung von Browser-Sessions, konsequentes Löschen von Zuständen und klare Benennung gespeicherter Requests verhindern diese Fehler.

In Teams ist Dokumentation entscheidend. Jeder relevante Request sollte mit Kontext gespeichert werden: Zeitpunkt, Benutzerkonto, Session-Zustand, erwartetes Ergebnis, tatsächliches Ergebnis. Ohne diese Disziplin lassen sich Befunde später kaum reproduzieren. Das gilt besonders bei Login-Flows mit MFA, SSO oder zeitabhängigen Tokens. Ein guter Testbericht beschreibt nicht nur, dass etwas funktioniert hat, sondern unter welchen Vorbedingungen und mit welchen Einschränkungen.

Wenn Burp selbst unerwartetes Verhalten zeigt, etwa fehlende Requests, TLS-Probleme oder unstabile Intercepts, muss zuerst die Tool-Kette geprüft werden. Fehler in Proxy-Konfiguration oder Zertifikatseinbindung führen schnell zu falschen Schlussfolgerungen über die Anwendung. In solchen Fällen helfen Funktioniert Nicht und Debugging, bevor weiter an der Zielanwendung gesucht wird.

Saubere Workflows bedeuten am Ende vor allem: Hypothesen einzeln testen, Ergebnisse vergleichen, Zustände kontrollieren und keine Annahmen aus dem UI ungeprüft auf den Server übertragen. Genau so entstehen belastbare Aussagen statt zufälliger Beobachtungen.

Ein praxistauglicher Workflow für Login Testing ist kein starres Rezept, aber er folgt einer klaren Reihenfolge. Zuerst wird die Anwendung beobachtet, dann reproduziert, dann gezielt manipuliert und erst danach skaliert. Diese Reihenfolge verhindert, dass Zeit in große, aber inhaltlich schwache Tests investiert wird. Wer zuerst versteht und dann automatisiert, findet mehr und produziert weniger Rauschen.

Ein bewährter Ablauf beginnt mit Scope und Baseline. Danach folgt die Zerlegung des Login-Flows in Vorbereitungsrequests, eigentlichen Auth-Request, Session-Erzeugung und Nach-Login-Verhalten. Anschließend werden Unterschiede zwischen gültigen und ungültigen Zuständen systematisch verglichen. Erst wenn klar ist, welche Parameter dynamisch sind und woran Erfolg erkennbar ist, kommen Intruder- oder Automatisierungsansätze ins Spiel. Für größere Assessments ist ein definierter Workflow entscheidend, damit Login-Tests nicht isoliert, sondern im Kontext des gesamten Web-Tests bewertet werden.

Zur fachlichen Tiefe gehört auch die Einordnung von Befunden. Nicht jede Enumeration ist gleich kritisch, nicht jede fehlende Session-Rotation ist automatisch ausnutzbar und nicht jedes Rate Limit ist ausreichend, nur weil es existiert. Die Bewertung hängt von Ausnutzbarkeit, Angriffsoberfläche, Schutzschichten und betrieblichem Kontext ab. Ein internes Admin-Portal mit schwachen Lockouts ist anders zu bewerten als ein öffentliches Kundenportal mit Millionen Konten.

Ein belastbarer Workflow endet außerdem nicht am Login selbst. Nach erfolgreicher Authentifizierung folgen immer Anschlussprüfungen: Session-Weitergabe zwischen Tabs, Logout-Invalidierung, Zugriff mit alten Cookies, Rechtewechsel, Passwortänderung, Remember-Me-Verhalten und API-Zugriffe mit denselben Tokens. Viele kritische Schwachstellen zeigen sich erst in diesen Übergängen. Deshalb ist Login Testing eng mit Themen wie Web Pentest und Pentesting verzahnt.

Wer methodisch arbeitet, erkennt schnell wiederkehrende Muster: Frontend-Schutz ohne Serverprüfung, schwache Token-Bindung, unvollständige Session-Rotation, inkonsistente Fehlermeldungen, API-Endpunkte ohne dieselben Limits wie das Web-Formular. Diese Muster tauchen in sehr unterschiedlichen Technologien auf, weil sie weniger von Frameworks als von Architektur- und Implementierungsentscheidungen abhängen.

Am Ende zählt nicht, wie viele Requests gesendet wurden, sondern wie gut der Authentifizierungsmechanismus verstanden wurde. Gutes Login Testing liefert klare Antworten auf konkrete Fragen: Was entscheidet über Erfolg oder Misserfolg? Welche Zustände werden erzeugt? Welche Schutzmechanismen greifen wirklich? Wo sind Unterschiede zwischen UI, API und Session-Schicht? Genau daraus entstehen verwertbare Befunde und saubere technische Empfehlungen.