...denn das Problem existiert für Server-Applikationen vollkommen
unabhängig vom inneren Aufbau der Server. Und es existiert unabhängig
von der konkreten Art und Weise der Identifizierung des Clients.
Es ist einfach ein Problem, das sich UM die IDENTIFIZIERUNG eines
Clients aus der Sicht eines Servers bzw. eines Geschäftsprozesses auf
dem Server heraus ergibt.
Dabei geht es um folgende Dinge:
1. Die Anmeldung unter einem Konto geht einher mit dem Übertragen
vertraulicher Daten bzw. dem Einsetzen vertraulicher Zustände
(Gewähren erweiterter Rechte, Zugriff auf persönliche Daten,
Einleitung verbindlicher und verpflichtender Geschäftsprozesse). Sie
verlangt zwingend die Übertragung aller Daten einschließlich der
Session-Kennung unter HTTPS und eine Abkopplung der Sitzung vom
vorherigen, nicht-authentifizierten Zustand! Eine Sitzung hat
dieselbe Bedeutung wie ein Kommunikationskanal! Wer vertrauliche
Daten über einen Kommunikationskanal überträgt, der auch schon vor
einer Authentifizierung verwendet wurde, verdient die Bestrafung
seiner Sünden!
2. Für Gelegenheitsbesucher sieht man in der Regel keine Anmeldung
und keine HTTPS-Übertragung vor, weil die üblicherweise die Hauptlast
des Servers darstellen, aber keine vertraulichen Daten übertragen
müssen, damit der Server in diesen Fällen weniger belastet wird.
Die dabei aufgesetzten Sessions enthalten nur Daten, die der
Bequemlichkeit des Besuchers dienen und sind unkritisch, wenn sie von
dritten eingesehen werden.
Da sie offen übertragen wird, ist die Session-Kennung trivial
abfangbar und darf nicht weiter verwendet werden, sobald sich ein
Besucher mit seinem Konto angemeldet hat!
3. Unterschiedliche Projekte auf ein und demselben Server, die
unterschiedlichen Geschäftsverhältnissen zugeordnet sind, haben
zwingend unterschiedliche Sessions zu verwalten!
Dazu muß der Server dem Browser nur mitteilen, DASS diese Sessions
eben innerhalb ihrer Pfad-Bereiche auf dem Server individuell
unterschiedlich sind.
Das HTTP-Protokoll mit seiner Cookie-Verwaltung (wenn man - wie
üblich - Cookies zur Session-Verwaltung nutzt) sieht das durchaus
vor. Man muß es nur nutzen!
4. Der Mißbrauch vom "Referrer" muß dadurch verhindert werden, daß
die Session-Kennung auf keinen Fall in der URL (als GET-Parameter)
übertragen wird! Dies ist ein Protokoll-Unsinn, für den weder die
bedauernswerten Internet-Nutzer noch die Server-Programmierer etwas
können, dem aber zwingend vorgebeugt werden muß - und zwar auf
Server-Seite!
----
Sobald sich also ein Besucher unter einem Konto an einem
eigenständigen Projekt anmelden will, muß zwingend die Übertragung
auf HTTPS umgeschaltet und eine neue Sitzung mit einer neuen Kennung
aufgebaut werden. Jede Navigation innerhalb der Geschäftsprozesse muß
fortan über HTTPS-Links erfolgen!
Wird das so umgesetzt, sind automatisch bestimmte Angriffsszenarios -
wie zum Beispiel das im Beitrag beschriebene "Session Fixation", bei
dem eine Session-Kennung nach Login gleich bleibt und per URL an ein
Opfer übertragen wird - nicht denkbar.
Es ist auch nicht notwendig, die alte - für den anonymen Besuch
vorgesehene - Session zu verwerfen, weil in deren Kontext einfach
absolut keinerlei vertrauliche Daten übertragen werden und diese
Session auch nicht für den vertraulichen Bereich benutzbar ist. Ganz
im Gegenteil kann der Besucher durchaus im selben Browser
verschiedene Seiten mit verschiedenen Sitzungen am Laufen haben - für
den anonymen Status und für jedes Login in jedem Projekt eine extra
Sitzung. (Eine andere Frage ist es, ob der User das
auseinanderzuhalten schafft - aber niemand zwingt ihn dazu, gelle?)
----
Womit man sich als Server-Programmierer auseinanderzusetzen hat, ist
die konkrete Art und Weise, wie der Server bzw. die verwendete
Programmiersprache es gestattet, die Sitzungsverwaltung mit den
beschriebenen Eigenschaften aufzusetzen. Da die Server bzw. die
Laufzeitsysteme der verwendeten Programmiersprachen nicht ahnen
können, wann in einem Projekt ein Login stattfindet, muß naturgemäß
der Programmierer selbst dafür sorgen, daß Session-Kennungen bei
Bedarf neu gebildet werden.
Womit man sich als Server-Administrator auseinanderzusetzen hat, ist
die konkrete Art und Weise, wie man von zu dämlichen Programmierern,
die ersteres nicht gerafft haben, aufgesetzte Projekte im nachhinein
von außen so zurechtbiegen kann, daß sie die Kriterien dennoch
erfüllen. In der Regel muß man sich dafür natürlich auch mit der
Server-Programmierung befassen und richtet sowas wie "Filter" (auf
Java-Servern) oder Auto-Includes (auf PHP-Servern) ein.
