Sitzungsbezeichner

Ein Sitzungsbezeichner (auch Sitzungskennung, Sitzungsnummer oder Sitzungs-ID, englisch session identifier, kurz englisch session ID) wird bei Anwendungen auf zustandslosen Protokollen als Identifikationsmerkmal verwendet, um mehrere zusammengehörige Anfragen eines Benutzers zu erkennen und einer Sitzung zuzuordnen. Insbesondere bei Webanwendungen finden Session IDs breite Verwendung.

Im World Wide Web werden Dienste aller Art mit Hilfe des Hypertext Transfer Protocol (HTTP) angeboten. Diese Dienste bestehen häufig aus mehreren zusammengehörigen Anfragen und Antworten. Um beispielsweise in einem Webshop etwas einzukaufen, durchstöbert der Benutzer zuerst den Katalog, lässt sich einige Artikel im Warenkorb vormerken und führt dann die Bestellung aus.

Derart komplizierte Vorgänge werden von HTTP jedoch nicht direkt unterstützt, denn es ist ein zustandsloses Protokoll. Eine HTTP-Anfrage liefert nur eine einzige Webseite zurück und merkt sich nicht, welcher Benutzer dazugehört. Um mehrere solche Anfragen zusammenzufassen und dem Benutzer zuzuordnen, wird bei jeder Anfrage eine Session ID mitgeschickt. Diese kann sich die Webanwendung merken und so die einzelnen Anfragen einer gemeinsamen Sitzung zuordnen.

In der Regel wird die Sitzung nach einer gewissen Zeit automatisch (Zeitüberschreitung) oder durch Abmelden beendet und die Session ID wird gelöscht. Es ist deshalb nicht möglich, den aktuellen Status einer Sitzung – zum Beispiel durch Anlegen eines Lesezeichen – zu speichern und später wieder aufzurufen. Diese Beschränkung kann auch vom Betreiber des Dienstes beabsichtigt sein, um das direkte Verlinken auf einzelne Seiten seines Angebots („Deep Links“) zu verhindern.

Funktion

Die Session ID wird vom Server zu Beginn einer Sitzung (englisch session) erzeugt. Sie muss mit der Antwort des Servers zum Client übertragen werden und von diesem bei jedem weiteren Zugriff auf den Server mitgeliefert werden. Mit Hilfe der eindeutigen Session ID können die serverseitig gespeicherten Daten (Beispiel: Warenkorb) bei jedem Zugriff eindeutig mit einem Benutzer verbunden werden.

Die Session ID muss also mit jeder Antwort des Servers erneut an den Client übertragen werden. Eine Anfrage, die die Session ID nicht enthält wird als erste Anfrage einer neuen Sitzung gesehen, der Benutzer verliert also seine bisherige Sitzung.

Realisierung

Technisch kann die Übertragung der Session ID im Rahmen von HTTP durch sogenannte Cookies, Einfügen in die URIs oder unsichtbare Formularfelder erreicht werden.

Da die Funktion eines Cookie vom Server nicht vorausgesetzt werden kann, unterstützen viele Anwendungen beide Übertragungsformen: Bei der ersten Antwort wird die Session ID sowohl als Cookie als auch in den URIs übertragen. Enthält die nächste Anfrage die Session ID als Cookie, werden die URIs für den Rest der Sitzung nicht mehr modifiziert.

Übertragung im HTTP-Header (Cookie)

Cookies sind eine Erweiterung des HTTP, die für die Lösung solcher Probleme entwickelt wurde. Der Server kann mit seiner Antwort (HTTP-Response) ein kleines Datenpaket an den Browser senden, das dieser bei jeder weiteren Anfrage (HTTP-Request) an denselben Server wieder mitsenden wird.

Die Session ID-Übertragung mit Cookies erfordert also nur die einmalige Übertragung der Session ID vom Server zum Client, alle folgenden Anfragen enthalten die Session ID. Ein Vorteil ist, dass die Session ID auch bei statischen Webseiten oder Bildern erhalten bleibt.

Das Problem dieses Ansatzes ist, dass Cookies auch über den Neustart des Browsers hinweg erhalten bleiben können, und von manchen Firmen zum Sammeln von Daten über den Benutzer verwendet werden. Aus diesem Grund haben manche Benutzer die Annahme von Cookies in ihrem Browser deaktiviert. Einige Webanwendungen weisen im Gegenzug explizit darauf hin, dass die Entgegennahme von Cookies im Browser aktiviert sein muss – z. B. um sich anzumelden.

Übertragung im URI

Da Folgeanfragen eines Benutzers in der Regel durch Anklicken eines Links oder Absenden eines Formulares erfolgen, kann die Session ID auch dadurch übermittelt werden, dass jeder URI innerhalb einer Webseite so modifiziert wird, dass er die Session ID enthält.

Hierzu sind zwei Vorgehensweisen verbreitet:

Session ID in einem URI

Query
http://www.example.com/index?sid=edb0e8665db4e9042fe0176a89aade16
Pfad
http://www.example.com/edb0e8665db4e9042fe0176a89aade16/index

Die Übertragung der Session ID im URI erfordert einen erhöhten Programmieraufwand und es gibt verschiedene Situationen, die zum Verlust der Sitzung führen können. Die Session ID wird zudem in der Logdatei des Servers aufgezeichnet.

Übertragung im Datenteil eines HTTP-Request (HTML-Formulare)

Eine Session ID kann auch – ähnlich der Übertragung im Query-Teil eines URI – im Datenteil eines HTTP-Request an den Server geschickt werden. Dazu wird die Session ID beim Absenden eines HTML-Formulars mit der Methode POST übertragen. In der Regel wird die Session ID in einem versteckten Formularfeld (input-Elemente des Typs „hidden“) gespeichert. Weil auch der HTML-Quellcode modifiziert werden muss, kann diese Methode ergänzend oder alternativ zur Übertragung in der URI eingesetzt werden.

Speicherung der Sessioninformationen auf dem Server

Die Daten einer Session, dazu gehören sowohl die Session ID als auch die Nutzdaten (Benutzer-ID, Warenkorbinhalt etc.), speichert der Webserver standardmäßig in einem dafür bestimmten Verzeichnis auf der Festplatte, häufig ist es das temporäre Verzeichnis des Betriebssystems (/tmp). Solch eine Datei sieht dann so aus: 

/tmp/sess_hvb0es1qdv5o91ogspmfk9ck77
UserID|i:212;Warenkorbinhalt|a:2:{i:0;s:8:"Artikel1";i:1;s:8:"Artikel2";}

Sessiondaten können aber auch an anderen (zentralen) Orten gespeichert werden, beispielsweise auf Netzlaufwerken, in einem Memcached oder einer Datenbank. Die meisten Webprogrammiersprachen unterstützen dies.

Sicherheit

Welche Übertragungsart für die Session ID auch gewählt wird, im Endeffekt vertraut der Server darauf, dass der Client dieselbe ID zurücksendet, die ihm übertragen wurde. Ein Benutzer kann aber, da er die Clientseite kontrolliert, eine beliebige Session ID zurücksenden. Sollte diese Session ID mit der eines anderen Benutzers übereinstimmen, ist das Ausspähen und Manipulieren der Daten anderer Benutzer möglich.

Es ist also von höchster Wichtigkeit, dass Session IDs nicht erraten werden können. Dies wird in der Regel dadurch erreicht, dass die Session ID zufällig aus einem Wertebereich ausgewählt wird, der so groß ist, dass er nicht durchsucht werden kann, und die Wahrscheinlichkeit, zufällig auf eine gerade verwendete Session ID zu stoßen, extrem gering ist.

Mögliche Angriffe auf eine bestehende Sitzung werden unter Session Hijacking beschrieben. Der Ansatz, als Angreifer eine gültige Sitzung zu erstellen und einem anderen Benutzer unterzuschieben, wird als Session Fixation bezeichnet.