Sitzungskennung in der URL

Eine Sitzungskennung ist funktional einem Passwort gleichwertig: Wer den Wert besitzt, ist der Nutzer. Dennoch kommt es vor, dass dieser Wert gut sichtbar in der Adresszeile steht, wo er anschließend an überraschend vielen Stellen festgehalten wird. Im Folgenden lesen Sie, über welche Wege das nach außen gelangt und warum das Problem mit HTTPS nicht gelöst ist.

Warum gehört eine Sitzungskennung nicht in die URL?

Eine Anwendung muss bei jeder Anfrage wissen, wer der Nutzer ist. Dafür sendet der Browser eine Sitzungskennung mit, normalerweise in einem Cookie. Steht diese Kennung in der URL, als Abfrageparameter oder als Teil des Pfads, wird sie Bestandteil der Adresse der Seite und damit Bestandteil von allem, was mit dieser Adresse geschieht.

Das ist der wesentliche Unterschied. Ein Cookie ist ein Stück verborgene Verwaltung zwischen Browser und Server: Es erscheint nirgends auf dem Bildschirm, wird nicht geteilt und landet nicht im Verlauf. Eine URL ist dazu gedacht, sichtbar, kopierbar und teilbar zu sein. Ein Geheimnis in einer URL ist ein Geheimnis in einer Struktur, die zum Weitergeben entworfen wurde.

Es läuft darauf hinaus, seine PIN auf die Außenseite der Bankkarte zu schreiben. Es funktioniert bestens, solange niemand hinsieht, doch Sie haben den Schutz genau dorthin verlegt, wo ihn jeder sehen kann.

Wohin gelangt die Sitzungskennung?

Die Zahl der Wege, auf denen eine URL festgehalten wird, ist größer, als die meisten Entwickler vermuten.

Verwundbar:

https://portal.example/vorgang/uebersicht?jsessionid=A3F91C7D4B2E8056

Diese eine URL landet unter anderem im Zugriffsprotokoll des Webservers, in den Protokollen jedes zwischengeschalteten Proxys oder Lastverteilers, im Browserverlauf des Nutzers, in seinen Lesezeichen, sofern er die Seite speichert, sowie in Überwachungs- oder Fehlerberichtssystemen, die Anfragen mitschreiben. Enthält die Seite zusätzlich eine externe Quelle oder einen Link nach außen, geht Folgendes an diesen Dritten:

GET /analytics.js HTTP/1.1
Host: statistik.example
Referer: https://portal.example/vorgang/uebersicht?jsessionid=A3F91C7D4B2E8056

Die Sitzung dieses Nutzers steht nun in den Protokolldateien einer Partei, die damit nichts zu tun hat. Und das alltäglichste Szenario verlangt gar keinen Angreifer: Der Nutzer kopiert den Link aus der Adresszeile und schickt ihn einem Kollegen, um ihm “kurz diese Seite” zu zeigen. Dieser Kollege öffnet damit das Konto des Absenders.

Sicher:

HTTP/1.1 200 OK
Set-Cookie: sid=A3F91C7D4B2E8056; HttpOnly; Secure; SameSite=Strict; Path=/

https://portal.example/vorgang/uebersicht

Die Kennung steckt nun in einem Cookie und verschwindet aus der Adresse. Die URL lässt sich bedenkenlos teilen, speichern und protokollieren. HttpOnly hält den Wert zusätzlich außerhalb der Reichweite von JavaScript, Secure verhindert die Übertragung über eine unverschlüsselte Verbindung, und SameSite=Strict sorgt dafür, dass das Cookie bei Anfragen von einer fremden Website nicht mitgeht.

Bei einem Framework, das dieses Verhalten standardmäßig anbietet, schalten Sie es ausdrücklich ab:

<!-- Java Servlet: ausschließlich Cookies, nie URL-Rewriting -->
<session-config>
  <tracking-mode>COOKIE</tracking-mode>
  <cookie-config>
    <http-only>true</http-only>
    <secure>true</secure>
  </cookie-config>
</session-config>

Welche Auswirkungen hat eine Sitzungskennung in der URL?

Der Schweregrad reicht von mittel bis hoch, abhängig davon, wie leicht ein Dritter an die URL gelangt. Anders als bei vielen anderen Sitzungsproblemen braucht es hier keinen Angreifer mit Netzwerkposition oder Einschleusung: Die wahrscheinlichste Ursache ist ein Nutzer, der selbst einen Link weiterleitet.

Gelingt es jemandem, eine gültige Sitzungskennung zu erlangen, ist die Übernahme vollständig. Für die Anwendung ist der Empfänger vom rechtmäßigen Nutzer nicht zu unterscheiden: Er hat dieselben Rechte, sieht dieselben Daten und kann dieselben Vorgänge ausführen. Es kommt kein Passwort ins Spiel, und eine Zwei-Faktor-Authentifizierung wird nicht erneut verlangt, da die Authentifizierung bereits stattgefunden hat.

Es gibt zudem eine schwer zu behebende Seite. Sitzungskennungen, die in Protokolldateien gelandet sind, stehen dort häufig jahrelang, verteilt über Systeme mit weiter reichendem Zugriff als die Anwendung selbst: Administratoren, Lieferanten und Analyseplattformen. Selbst nach Behebung der Schwachstelle bleiben diese Spuren bestehen und sind mit derselben Sorgfalt zu behandeln wie gespeicherte Passwörter.

Wie spürt man eine Sitzungskennung in der URL auf?

Ein Tester achtet beim Durchgehen der Anwendung auf jeden Parameter, der wie eine Kennung aussieht: Namen wie sid, sessionid, jsessionid, phpsessid, token oder auth in der Abfrage oder im Pfad. Das deutlichste Signal ist ein Sitzungswert, der beim Anmelden in der URL erscheint und danach mitläuft.

Anschließend wird geprüft, ob der Wert tatsächlich Zugang gewährt: Der Tester öffnet dieselbe URL in einem sauberen Browser ohne Cookies. Funktioniert das, steckt die Sitzung vollständig in der URL. Ebenso wird nach Frameworks gesucht, die bei fehlenden Cookies automatisch auf URL-Rewriting zurückfallen; dieses Verhalten zeigt sich mitunter erst, wenn man Cookies abschaltet. Auch Fehlerseiten, PDF-Exporte und E-Mails werden betrachtet, denn dort landen regelmäßig vollständige URLs. AssistSec beurteilt dabei zusätzlich die Referrer-Konfiguration und das Vorhandensein externer Quellen, denn diese bestimmen gemeinsam, wie weit eine offengelegte Kennung tatsächlich reist.

Wie verhindert man eine Sitzungskennung in der URL?

• Übertragen Sie Sitzungskennungen ausschließlich in Cookies und schalten Sie URL-Rewriting in Ihrem Framework ausdrücklich ab.
• Setzen Sie am Session-Cookie die Attribute HttpOnly, Secure und SameSite.
• Platzieren Sie niemals Token, Wiederherstellungscodes oder API-Schlüssel in einem Abfrageparameter oder im Pfad.
• Nutzen Sie zum Teilen von Inhalten eine eigene, ausdrückliche Freigabefunktion mit einem eigenen, begrenzten Token.
• Setzen Sie Referrer-Policy: strict-origin-when-cross-origin oder strenger als ergänzende Schicht.
• Filtern Sie Sitzungskennungen aus Protokolldateien und Überwachungsdaten oder protokollieren Sie nur den Pfad ohne Abfrage.
• Widerrufen Sie alle bestehenden Sitzungen, wenn Sie diesen Fehler beheben, denn frühere Kennungen gelten als offengelegt.
• Erneuern Sie die Sitzungskennung beim Anmelden, damit ein zuvor geteilter Wert keine Rechte mehr verleiht.