Authentication Bypass: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Authentication Bypass bedeutet nicht automatisch, dass ein Passwort erraten oder ein Login-Formular direkt überwunden wird. In der Praxis wird meist eine Kontrollkette gebrochen: Identitätsprüfung, Zustandsverwaltung, Autorisierungskontext oder die technische Bindung zwischen mehreren Requests. Genau deshalb scheitern viele Tests daran, dass nur die sichtbare Login-Seite betrachtet wird, während der eigentliche Fehler in Redirects, Session-Handling, API-Endpunkten oder Token-Validierung liegt.

Typische Anwendungen setzen Authentifizierung aus mehreren Bausteinen zusammen: Login-Formular, Session-Cookie, CSRF-Schutz, Redirect-Logik, Rollenprüfung, API-Gateway, Single-Sign-On oder mobile Backends. Ein Bypass entsteht oft dort, wo diese Bausteine nicht konsistent dieselben Annahmen treffen. Ein Frontend kann etwa korrekt auf eine Login-Seite umleiten, während ein JSON-Endpunkt im Hintergrund Daten ohne gültige Session ausliefert. Ebenso kann ein Reverse Proxy Header vertrauen, die vom Backend nie hätten akzeptiert werden dürfen.

Burp Suite ist in diesem Kontext kein Werkzeug zum blinden Ausprobieren, sondern zum Zerlegen des Authentifizierungsflusses in überprüfbare Einzelteile. Der Einstieg erfolgt fast immer über Proxy, die manuelle Verifikation über Repeater, und bei systematischen Varianten über Intruder. Wer Login- und Session-Mechanismen sauber verstehen will, arbeitet nicht requestweise isoliert, sondern modelliert den gesamten Ablauf: unauthentifizierter Zugriff, Login-Versuch, Session-Erzeugung, Session-Nutzung, Session-Verlust, Rollenwechsel, Logout und Re-Use alter Artefakte.

Ein sauberer Test trennt vier Fragen: Wird Identität geprüft? Wird der Prüfstatus korrekt gespeichert? Wird dieser Status bei jedem sensiblen Endpunkt erneut validiert? Und ist die Identität an den richtigen Benutzer, Client oder Kontext gebunden? Viele reale Schwachstellen liegen in der dritten und vierten Frage. Ein Request kann formal authentifiziert aussehen, obwohl die Session abgelaufen ist, ein JWT manipuliert wurde oder ein interner Header die Prüfung überschreibt.

Besonders relevant ist die Abgrenzung zu anderen Fehlerklassen. Ein Authentication Bypass ist nicht dasselbe wie Idor, obwohl beides zu unberechtigtem Zugriff führen kann. Bei IDOR ist der Benutzer oft korrekt eingeloggt, greift aber auf fremde Objekte zu. Beim Authentication Bypass fehlt die Identitätsprüfung ganz oder lässt sich technisch umgehen. Ebenso ist ein Bypass nicht automatisch Session Hijacking. Beim Hijacking wird eine fremde gültige Session übernommen; beim Bypass kann sogar ohne gültige Session Zugriff entstehen.

Die wichtigste praktische Konsequenz: Nicht nur das Login testen, sondern jede Stelle, an der eine Anwendung glaubt, dass ein Benutzer bereits authentifiziert ist. Genau dort entstehen die Fehler, die in echten Assessments am häufigsten übersehen werden.

Ein belastbarer Authentication-Test beginnt mit einer stabilen Baseline. Zuerst wird der Scope eng gesetzt, damit nur relevante Hosts, APIs und Subdomains erfasst werden. Danach wird der komplette Login-Flow einmal ohne Manipulation durchlaufen. Ziel ist nicht nur ein erfolgreicher Login, sondern eine vollständige Referenz: Welche Requests werden vor dem Login gesendet, welche Cookies entstehen, welche Redirects folgen, welche Header ändern sich, welche API-Calls liefern nach dem Login erstmals Daten?

In Burp ist die Proxy History dafür oft wertvoller als ein schneller Blick auf das Formular. Viele Anwendungen erzeugen vor dem Login bereits einen anonymen Session-Identifier, laden Konfigurationsdaten, holen CSRF-Tokens oder prüfen Feature-Flags. Wer diese Requests ignoriert, versteht später nicht, warum ein reproduzierter Request im Repeater plötzlich 401, 403 oder 302 liefert.

Ein praxistauglicher Ablauf sieht so aus:

• Unauthentifizierten Zugriff auf Zielressourcen dokumentieren und Response-Codes, Redirect-Ziele, Header und Body-Merkmale notieren.
• Login vollständig mitschneiden und alle zustandsrelevanten Artefakte markieren: Cookies, Bearer-Token, CSRF-Werte, Nonces, Device-IDs, Hidden Fields.
• Nach erfolgreichem Login dieselben Zielressourcen erneut abrufen und Unterschiede mit dem unauthentifizierten Zustand vergleichen.
• Logout ausführen und prüfen, welche Artefakte weiter funktionieren oder serverseitig ungültig werden.

Diese Baseline verhindert einen klassischen Fehler: Ein einzelner erfolgreicher Request wird als Bypass interpretiert, obwohl nur ein altes Cookie aktiv war oder ein Browser automatisch Credentials nachgesendet hat. Deshalb sollten Tests regelmäßig im privaten Browserfenster, mit geleertem Cookie-Jar oder direkt im Repeater Session Test nachvollzogen werden.

Wichtig ist auch die Trennung von Browserzustand und Burp-Zustand. Manche Anwendungen setzen Cookies auf mehreren Pfaden oder Subdomains. Andere verwenden gleichzeitig Cookie-basierte Sessions und API-Tokens. Wenn Requests aus verschiedenen Tabs oder Tools vermischt werden, entstehen falsche Befunde. Deshalb lohnt sich ein definierter Workflow mit benannten Repeater-Tabs, klaren Kommentaren und einer festen Reihenfolge. Wer Burp noch nicht konsistent eingerichtet hat, sollte die Grundlagen zu Proxy Einrichten und Workflow beherrschen, bevor komplexe Authentifizierungsfehler bewertet werden.

Eine gute Baseline beantwortet am Ende drei Kernfragen: Welche Requests benötigen Authentifizierung wirklich? Woran erkennt der Server den Authentifizierungsstatus technisch? Und welche Komponenten entscheiden über Zugriff: Anwendung, API, Gateway oder vorgeschalteter Proxy? Erst wenn diese Fragen sauber beantwortet sind, beginnt der eigentliche Bypass-Test.

Viele Login-Flows bestehen aus mehreren Schritten, die nicht alle gleich zuverlässig abgesichert sind. Klassische Beispiele sind Pre-Auth-Endpoints, Passwort-Reset-Strecken, MFA-Vorbereitung, SSO-Callbacks, Device-Trust-Mechanismen oder API-Endpunkte, die vom Frontend vor und nach dem Login unterschiedlich genutzt werden. Ein häufiger Fehler ist die Annahme, dass ein erfolgreicher Redirect auf /login bereits Schutz bedeutet. Tatsächlich ist nur die Benutzeroberfläche geschützt, nicht zwingend die Ressource selbst.

Ein reales Muster: Der Browser ruft /account auf, erhält 302 auf /login, lädt danach JavaScript und dieses fragt /api/account/profile ab. Wenn /api/account/profile direkt 200 liefert, liegt der Fehler nicht im Login-Formular, sondern in der inkonsistenten Absicherung zwischen Frontend und API. Genau solche Fälle werden sichtbar, wenn Requests aus der History einzeln in den Repeater übernommen und ohne Browserkontext erneut abgespielt werden.

Ein weiteres Muster betrifft Multi-Step-Logins. Nach Eingabe von Benutzername und Passwort wird oft ein temporärer Status gesetzt, etwa pending_mfa=true oder ein Challenge-Token. Wenn das Backend spätere Requests nur auf das Vorhandensein dieses Zwischenstatus prüft, kann ein Angreifer unter Umständen direkt in einen authentifizierten Bereich gelangen, ohne den zweiten Faktor abzuschließen. Der Fehler liegt dann nicht in der Kryptografie des MFA-Verfahrens, sondern in der Zustandsmaschine.

Auch Redirect-Parameter sind kritisch. Anwendungen speichern nach dem Login oft eine Ziel-URL oder einen Return-State. Wenn dieser Zustand serverseitig nicht an die Session gebunden ist, kann es passieren, dass ein Request nach erfolgreichem Login in einen Bereich springt, dessen Zugriffskontrolle nur clientseitig geprüft wird. Das ist kein klassischer Open Redirect, sondern eine fehlerhafte Kopplung zwischen Navigation und Authentifizierungsstatus.

Besonders anfällig sind hybride Anwendungen mit Web-Frontend und separater API. Das Frontend prüft vielleicht, ob localStorage oder ein Cookie vorhanden ist, während die API nur einen Header erwartet. Wenn beide Seiten unterschiedliche Wahrheiten über den Login-Zustand akzeptieren, entstehen Lücken. In Assessments lohnt sich daher immer ein paralleler Blick auf Login Testing, Session Management und API Testing.

Ein häufiger Denkfehler besteht darin, nur erfolgreiche Login-Versuche zu analysieren. Mindestens genauso wichtig sind negative Pfade: falsches Passwort, abgelaufener Token, abgebrochene MFA, Logout, Session-Timeout, parallele Sessions, Passwortänderung während aktiver Sitzung. Gerade dort zeigt sich, ob die Anwendung Zustände sauber invalidiert oder ob alte Artefakte weiterverwendbar bleiben.

Wer diese Fehlerbilder erkennt, testet nicht nur Formulare, sondern Zustandsübergänge. Genau dort entstehen die Bypässe, die in produktiven Anwendungen am meisten Schaden verursachen.

Die Mehrheit aller Authentication-Bypass-Fälle hängt an Session-Handling. Nicht weil Sessions grundsätzlich unsicher wären, sondern weil Anwendungen mehrere Zustände gleichzeitig verwalten: anonyme Session, authentifizierte Session, Remember-Me-Token, CSRF-Kontext, Rollenwechsel, Passwort-Reset-Status, MFA-Status und manchmal noch Gerätebindung oder Risk-Score. Sobald diese Zustände nicht atomar behandelt werden, entstehen Inkonsistenzen.

Ein klassischer Test beginnt mit dem Vergleich zwischen anonymer und authentifizierter Session-ID. Wird die Session nach dem Login nicht regeneriert, ist das zunächst eher Session Fixation als direkter Bypass. Trotzdem ist es relevant, weil eine vorab bekannte Session-ID später in einen authentifizierten Zustand übergehen kann. In Burp lässt sich das sauber prüfen, indem vor dem Login gesetzte Cookies notiert und nach dem Login auf Wiederverwendung kontrolliert werden.

Ebenso wichtig ist die Frage, welche Cookies wirklich autorisierungsrelevant sind. Viele Anwendungen setzen dekorative oder analytische Cookies, daneben aber ein einziges Session-Cookie, das den gesamten Zugriff steuert. Andere Systeme verwenden mehrere Cookies, etwa einen Session-Identifier plus ein Flag wie authenticated=true oder role=user. Wenn ein Backend versehentlich auf ein manipulierbares Flag vertraut, kann ein Bypass trivial werden. Solche Fehler sind seltener geworden, tauchen aber in Legacy-Anwendungen und internen Portalen weiterhin auf.

Prüfpunkte bei Session-basierten Anwendungen sind unter anderem:

• Wird die Session-ID nach erfolgreichem Login, Rollenwechsel oder MFA-Abschluss erneuert?
• Werden Logout, Passwortänderung und Timeout serverseitig durchgesetzt oder nur clientseitig dargestellt?
• Akzeptiert das Backend alte Cookies parallel zu neuen oder auf mehreren Pfaden und Subdomains?
• Existieren Endpunkte, die nur auf das Vorhandensein eines Cookies prüfen, nicht aber auf dessen serverseitige Gültigkeit?

Ein besonders gefährliches Muster ist die teilweise serverseitige und teilweise clientseitige Authentifizierungslogik. Das Frontend blendet Inhalte aus, wenn kein Cookie vorhanden ist, aber die API prüft nur, ob irgendein Session-Header gesetzt wurde. In Burp wird das sichtbar, wenn Requests aus dem Browser in den Repeater kopiert und schrittweise reduziert werden: erst unnötige Header entfernen, dann Cookies einzeln löschen, dann Reihenfolge und Pfade variieren. Ziel ist nicht nur ein funktionierender Request, sondern das minimale Set an Artefakten, das den Zugriff auslöst.

Für diese Arbeit sind Kenntnisse zu Cookies und Repeater Parameter Testen besonders nützlich. Wer sauber arbeitet, dokumentiert immer, ob ein Zugriff an eine konkrete Session gebunden ist oder ob bereits das Vorhandensein eines formalen Markers genügt. Genau diese Unterscheidung entscheidet darüber, ob ein Befund ein echter Authentication Bypass oder nur ein Missverständnis im Testaufbau ist.

Auch SameSite, Secure und HttpOnly sind in diesem Kontext nur Randaspekte. Sie beeinflussen Transport und Missbrauchsszenarien, ersetzen aber keine serverseitige Validierung. Ein Cookie mit perfekten Flags bleibt wertlos, wenn das Backend seinen Inhalt oder seine Gültigkeit nicht korrekt prüft.

Token-basierte Authentifizierung wirkt oft robuster als klassische Sessions, erzeugt aber eigene Fehlerklassen. JWTs, OAuth-Access-Tokens, Refresh-Tokens und ID-Tokens werden in vielen Anwendungen vermischt oder falsch interpretiert. Ein häufiger Praxisfehler besteht darin, dass ein Token zwar formal vorhanden ist, aber nicht für den konkreten Zweck gedacht war. Wenn ein Backend etwa ein ID-Token als Autorisierungsnachweis akzeptiert, obwohl nur ein Access-Token zulässig wäre, entsteht ein Bypass nicht durch Krypto-Bruch, sondern durch falsche Semantik.

Bei JWTs beginnt die Analyse immer mit Struktur und Claims. Im Decoder lassen sich Header und Payload schnell prüfen: Algorithmus, issuer, audience, expiration, subject, Rollen und benutzerdefinierte Claims. Entscheidend ist danach aber die serverseitige Reaktion auf Manipulation. Ein Token darf nicht nur syntaktisch plausibel aussehen, sondern muss korrekt signiert, zeitlich gültig, für die richtige Audience ausgestellt und an den richtigen Kontext gebunden sein.

Typische Schwachstellen sind fehlende Signaturprüfung, unsaubere Algorithmus-Validierung, Akzeptanz abgelaufener Tokens, fehlende Prüfung von audience oder issuer, sowie die Nutzung von Rollenclaims ohne serverseitige Gegenprüfung. In internen APIs taucht außerdem regelmäßig der Fehler auf, dass ein Gateway das Token validiert, das Backend aber blind auf weitergereichte Header vertraut. Wird der Backend-Endpunkt direkt erreicht, fällt die eigentliche Schutzschicht weg.

Bei OAuth- und OIDC-Flows ist die Lage komplexer. Dort entstehen Bypässe oft in der Bindung zwischen Authorization Request, Callback, State, Nonce und Session. Wenn State-Werte nicht korrekt geprüft oder nicht an die Session gebunden werden, kann ein fremder oder alter Login-Kontext übernommen werden. Ebenso kritisch ist die Verwechslung von Frontend-Login und API-Autorisierung: Ein Benutzer ist im Browser scheinbar angemeldet, aber die API akzeptiert Tokens aus einem anderen Client oder Mandanten.

Ein belastbarer Test für moderne Token-Modelle umfasst mindestens folgende Schritte: Token dekodieren, Claims verstehen, minimale Änderungen durchführen, Signatur- und Gültigkeitsfehler provozieren, Audience und Issuer variieren, alte Tokens nach Logout erneut testen, Refresh-Verhalten prüfen und direkte Backend-Zugriffe ohne vorgeschaltetes Gateway versuchen. Wer tiefer in diese Themen einsteigen will, sollte die Bereiche Jwt Testing und Oauth Testing systematisch mitdenken.

Ein Beispiel für einen sinnvollen Repeater-Test:

GET /api/v1/profile HTTP/1.1
Host: target.example
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json
Connection: close

Danach werden nicht wahllos Claims verändert, sondern gezielt Hypothesen geprüft: Reagiert der Server auf ein manipuliertes exp? Wird ein geänderter sub akzeptiert? Führt ein Token ohne role-Claim trotzdem zum Zugriff? Liefert ein formal ungültiges Token denselben Fehler wie ein fehlendes Token? Unterschiedliche Fehlermeldungen und Statuscodes verraten oft, welche Prüfungen tatsächlich stattfinden und welche nur behauptet werden.

Nicht jeder Authentication Bypass hängt an Formularen, Cookies oder Tokens. In Unternehmensumgebungen entstehen viele kritische Befunde durch Infrastrukturannahmen. Anwendungen hinter Reverse Proxies, API-Gateways, WAFs oder SSO-Komponenten vertrauen häufig Headern wie X-Forwarded-User, X-Authenticated-User, X-Remote-User oder internen Rollenheadern. Diese Header sollen nur von vorgeschalteten Systemen gesetzt werden. Wenn das Backend sie jedoch direkt aus externen Requests akzeptiert, ist der Bypass oft trivial.

Der Testansatz ist hier methodisch: Zuerst wird ein normaler authentifizierter Request analysiert. Danach wird geprüft, ob der Zugriff auch ohne Session oder Token funktioniert, wenn bestimmte Header ergänzt werden. Wichtig ist, nicht blind eine bekannte Headerliste zu senden, sondern aus der Zielumgebung abzuleiten, welche Header plausibel sind. Hinweise liefern Response-Header, Fehlermeldungen, Debug-Ausgaben, Framework-Konventionen oder interne Namensmuster in JavaScript-Dateien.

Ein einfaches Beispiel:

GET /admin HTTP/1.1
Host: target.example
X-Forwarded-User: admin
X-Authenticated-User: admin
X-Original-URL: /admin
Connection: close

Ein 200-Response ist hier noch kein endgültiger Beweis. Es muss geprüft werden, ob echte privilegierte Funktionen erreichbar sind oder nur eine statische Seite ausgeliefert wird. Deshalb sollten Folgeaktionen getestet werden: Benutzerliste abrufen, Einstellungen ändern, Audit-Log öffnen, API-Calls ausführen. Erst wenn serverseitig geschützte Aktionen ohne legitime Authentifizierung funktionieren, liegt ein belastbarer Befund vor.

Ein weiteres reales Muster sind Pre-Auth- oder Health-Endpunkte, die intern für Monitoring, SSO oder Initialisierung gedacht waren. Solche Pfade liegen oft unter /internal, /actuator, /auth/status, /session/validate oder ähnlichen Routen. Nicht jeder dieser Endpunkte ist direkt kritisch, aber viele verraten Authentifizierungszustände, Benutzerkontexte oder akzeptieren interne Parameter. In Kombination mit Header-Vertrauen oder schwacher Pfadfilterung kann daraus ein vollständiger Bypass entstehen.

Auch URL-Rewriting und Original-URL-Header sind relevant. Manche Proxies prüfen nur den äußeren Pfad, während das Backend einen anderen Pfad aus X-Original-URL oder X-Rewrite-URL verarbeitet. Wenn der Proxy /login schützt, das Backend aber /api/admin aus einem Header übernimmt, wird die Schutzschicht umgangen. Solche Tests gehören in jeden ernsthaften Web-Pentest und lassen sich mit Proxy Modify Request oder im Repeater sehr effizient durchführen.

Die wichtigste Regel dabei: Infrastrukturfehler immer end-to-end verifizieren. Ein einzelner Header, der eine andere Fehlermeldung erzeugt, ist nur ein Hinweis. Ein echter Authentication Bypass liegt erst vor, wenn ein geschützter Zustand ohne legitimen Authentifizierungsnachweis erreicht wird.

Authentication Bypass lässt sich selten durch wahlloses Fuzzing zuverlässig finden. Erfolgreiche Tests folgen Hypothesen. Repeater dient dazu, einzelne Annahmen präzise zu prüfen: Welcher Header ist relevant? Welches Cookie trägt den Zustand? Welche Redirect-Kette ist entscheidend? Intruder kommt erst dann ins Spiel, wenn Variationen systematisch durchprobiert werden sollen, etwa Headernamen, Parameterkombinationen, Rollenwerte oder bekannte interne Pfade.

Ein sinnvoller Repeater-Workflow beginnt mit einem funktionierenden authentifizierten Request. Danach wird schrittweise reduziert. Zuerst unnötige Header entfernen, dann Cookies einzeln löschen, dann Token variieren, dann Request-Methode und Content-Type prüfen. Ziel ist ein minimales funktionierendes Muster. Erst wenn klar ist, welche Elemente den Zugriff steuern, lohnt sich eine Intruder-Kampagne.

Intruder ist besonders nützlich bei folgenden Szenarien:

• Variationen interner Vertrauensheader wie X-Forwarded-User, X-Remote-User oder X-Original-URL gegen einen bekannten geschützten Endpunkt.
• Systematische Prüfung mehrerer Rollen-, Mandanten- oder Statuswerte in JSON- oder Form-Parametern.
• Vergleich von Response-Längen, Redirect-Zielen und Statuscodes bei unauthentifizierten, teil-authentifizierten und manipulierten Requests.
• Enumeration von API-Pfaden, die vom Frontend nach dem Login genutzt werden, aber serverseitig uneinheitlich geschützt sind.

Wichtig ist die richtige Auswertung. Bei Authentifizierungsfehlern sind Statuscodes allein oft irreführend. Viele Anwendungen liefern immer 200 und signalisieren Fehler nur im Body, in JSON-Feldern oder durch subtile Header-Unterschiede. Deshalb sollten Response-Länge, Schlüsselwörter, Redirect-Orte, Set-Cookie-Verhalten und Timing gemeinsam betrachtet werden. Der Comparer hilft dabei, minimale Unterschiede zwischen legitimen und manipulierten Antworten sichtbar zu machen.

Ein Beispiel für einen gezielten Test ist die Variation eines Rollenparameters in einem JSON-Request, der nach dem Login gesendet wird:

POST /api/session/continue HTTP/1.1
Host: target.example
Content-Type: application/json
Cookie: session=abc123

{
  "user":"victim@example.com",
  "state":"mfa_pending",
  "role":"admin"
}

Hier geht es nicht darum, ob role=admin irgendwo im Client sichtbar ist, sondern ob das Backend diesen Wert ungeprüft übernimmt. Ein echter Pentest prüft danach immer Folgeeffekte: Wird ein Admin-Dashboard erreichbar? Ändern sich API-Berechtigungen? Tauchen neue Menüpunkte nur im Frontend auf oder funktionieren auch privilegierte Backend-Aktionen?

Wer Burp in solchen Szenarien effizient einsetzen will, profitiert von sauberem Tool-Verständnis in Repeater Anleitung und Intruder Anleitung. Entscheidend bleibt aber die Methodik: erst verstehen, dann reduzieren, dann variieren, dann verifizieren.

Ein belastbarer Authentication-Bypass-Befund besteht nicht aus einer Vermutung, sondern aus einer reproduzierbaren Kette. Beispiel eins: Eine Web-Anwendung schützt /dashboard per Redirect auf /login. Das Frontend lädt nach erfolgreichem Login jedoch /api/me, /api/billing und /api/notifications. Im Test zeigt sich, dass /api/me ohne Session 401 liefert, /api/notifications 302 auf /login ausgibt, aber /api/billing direkt 200 mit sensiblen Daten zurückgibt. Das ist ein klarer Bypass auf API-Ebene, obwohl die sichtbare Web-Oberfläche korrekt reagiert.

Beispiel zwei: Eine Anwendung nutzt MFA. Nach Passwortprüfung wird ein Cookie mfa_state=verified gesetzt, bevor der zweite Faktor abgeschlossen ist. Ein nachfolgender Request auf /app/home prüft nur dieses Cookie und nicht den serverseitigen Abschlussstatus. Wird der Request im Repeater mit dem Zwischenzustand wiederholt, ist der Zugriff ohne OTP möglich. Der Fehler liegt nicht im OTP-Verfahren, sondern in der falschen Vertrauensgrenze zwischen Zwischenstatus und finalem Login.

Beispiel drei: Eine interne Admin-Anwendung sitzt hinter einem Reverse Proxy. Extern ist /admin nicht erreichbar. Das Backend akzeptiert jedoch X-Forwarded-User: admin und liefert bei direktem Zugriff auf einen weniger bekannten Hostnamen vollständige Admin-Funktionen. Der eigentliche Fehler ist die Annahme, dass nur der Proxy diesen Header setzen kann. In der Praxis ist das einer der gefährlichsten Bypass-Typen, weil er oft sofort zu Vollzugriff führt.

Beispiel vier: Eine mobile API verwendet Bearer-Tokens. Nach Logout wird das Token im Client gelöscht, serverseitig aber nicht invalidiert. Alte Tokens funktionieren weiter für /profile, /orders und /payment-methods. Das ist streng genommen eher mangelhafte Session-Invalidierung, führt aber funktional zu unberechtigtem Zugriff und muss wie ein Authentifizierungsproblem behandelt werden.

Beispiel fünf: Ein Passwort-Reset-Flow erzeugt einen temporären Reset-Kontext. Ein Endpunkt /api/account/context akzeptiert diesen Kontext und liefert bereits Benutzerdaten, obwohl noch kein neues Passwort gesetzt wurde. Wenn derselbe Kontext später auch für geschützte Aktionen akzeptiert wird, entsteht ein Bypass über einen eigentlich unterstützenden Prozess.

Diese Beispiele zeigen ein Muster: Der Fehler sitzt selten dort, wo Benutzer ihn vermuten. Nicht das sichtbare Login ist das Problem, sondern die technische Kopplung zwischen Zuständen, Endpunkten und Vertrauensannahmen. Wer nur auf 200 oder 302 schaut, übersieht die eigentliche Schwachstelle. Wer dagegen den gesamten Ablauf mit Burp nachvollzieht, erkennt, an welcher Stelle die Anwendung Authentifizierung nur simuliert statt durchzusetzen.

Gerade bei Authentication Bypass entstehen viele Fehlalarme. Ein häufiger Irrtum ist die Verwechslung von Caching, statischen Inhalten oder clientseitig gerenderten Platzhaltern mit echtem Zugriff. Wenn eine Seite ohne Login HTML ausliefert, heißt das noch nicht, dass sensible Daten oder Aktionen verfügbar sind. Ebenso kann ein 200-Response nur eine generische Shell sein, die eigentlichen Daten werden erst per API geladen. Deshalb muss jeder Befund auf Datenzugriff oder privilegierte Aktion verifiziert werden.

Ein zweiter häufiger Fehler ist die Nutzung eines noch gültigen Browserzustands. Moderne Browser senden Cookies, Authorization-Header oder Client-Zertifikate teilweise automatisch mit. Auch Service Worker, lokale Speicherzustände oder parallele Tabs verfälschen Ergebnisse. Deshalb sollten kritische Tests immer in Burp isoliert reproduziert werden, idealerweise mit explizit gesetzten und dokumentierten Headern statt implizitem Browserverhalten.

Ein dritter Punkt betrifft Response-Differenzen. Manche Anwendungen antworten bei fehlender Authentifizierung mit 200 und einer Login-Maske im Body, andere mit 401, 403 oder 302. Wieder andere liefern bei ungültigem Token denselben Fehler wie bei fehlendem Token. Diese Unterschiede sind wertvoll, aber nicht automatisch sicherheitsrelevant. Erst wenn ein geschützter Zustand ohne legitime Authentifizierung erreicht wird, ist die Schwachstelle bestätigt.

Für saubere Verifikation empfiehlt sich folgender Prüfrahmen:

Erstens muss der Ausgangszustand klar unauthentifiziert sein. Zweitens muss der manipulierte Request reproduzierbar denselben Zugriff liefern. Drittens muss der Zugriff serverseitig relevant sein, also Daten lesen, ändern oder privilegierte Funktionen ausführen. Viertens muss ausgeschlossen werden, dass nur ein alter oder paralleler Authentifizierungszustand wiederverwendet wurde. Fünftens sollte die Auswirkung dokumentiert werden: Welche Daten, welche Rolle, welche Aktion, welcher Scope?

Auch die rechtliche und organisatorische Seite gehört dazu. Authentication-Tests dürfen nur im freigegebenen Rahmen stattfinden. Besonders Header-Manipulation, Token-Tests, Session-Reuse und Rollenwechsel können produktive Konten beeinflussen. Deshalb sind Testkonten, definierte Zeitfenster und klare Freigaben Pflicht. Wer in professionellen Umgebungen arbeitet, sollte die Grenzen aus Legal und Ethisches Hacking strikt beachten.

Ein guter Befund ist am Ende knapp, technisch präzise und reproduzierbar. Er beschreibt nicht nur, dass ein Login umgangen wurde, sondern wie, unter welchen Bedingungen und mit welcher Auswirkung. Genau diese Qualität trennt belastbare Sicherheitsanalyse von bloßem Request-Spiel.