Dieser Beitrag bezieht sich auf einen früheren Artikel unter http://www.lieber-linux.de/2008/08/php-session-problem-mit-dem-ie-tob-605/.

Ich habe nun endlich das Problem, welches viele T-Online-Kunden beim Surfen auf so vielen Portalen haben, erkannt. Schuld ist der Browser selbst (Oh, welch Wunder!), der seine User-Agent-Kennung nach Lust und Laune wechselt!

So meldet sich der T-Online-Browser zunächst in dieser Form:

1

Mozilla/4.0 (compatible; MSIE 6.0; TOB 6.05; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Mozilla/4.0 (compatible; MSIE 6.0; TOB 6.05; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Später erscheint folgende Kennung am Server:

1

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Wie man sieht, wurde die spezielle T-Online-Kennung ” TOB 6.05;” in den späteren Clicks entfernt. Dies scheint ein nicht seltenes Phänomen zu sein, wenn ich unsere Logs richtig interpretiere. So liegt die durchschnittliche Click-Anzahl eines TOB-Surfers zwischen 1 und 2, d.h. die Session ging meist zwischen dem 1. und 2. Click verloren. Das ist nicht nur ärgerlich, das ist einfach katastrophal für jeden sicherheitsbewussten Webserver-Administrator.

Das Problem mit der Browser-Kennung

Viele Portale bieten Login-basierte Services an. Durch diese personalisierte Interaktion entstehen jedoch sensible, d.h. vertrauliche, Daten. Die Portale müssen daher sicherstellen, dass diese Daten nur der entsprechende Benutzer und ansonsten kein anderer Mensch der Welt sieht. Dabei verlassen sich Web-Applikationen unter anderem auf die Browser-Kennung des Gegenübers als eines von vielen Sicherheitsmerkmalen, um eine aktive Sitzung einem Kunden zuverlässig zuweisen zu können. Damit soll das sogenannte Session-Hijacking verhindert werden.

Session-Hijacking im Details

Session-Hijacking bedeutet das Kapern von aktiven Sitzungen eines Benutzers durch fremde Angreifer ohne Kenntnis von Passwörtern oder Login-Daten. Vielmehr zielt der Angreifer auf einen Sitzungsschlüssel, der vom Webserver zufällig für eine Sitzung als Schlüssel (Session-Key) erzeugt wird. Dabei wird die Tatsache ausgenutzt, dass Web-Server nur eine begrenzte Anzahl von Session-Keys generiert werden können, denn die Schlüssel sind immer 32-stellig und hexadezimal.

Durch genügendes Probieren kann bei einem sehr frequentierten Server in hinreichender Zeit ein aktiver Schlüssel entdeckt werden. Normalerweise wird der Schlüssel per Session-Cookie weitergegeben. Jedoch erlauben nicht alle Browser das Setzen eines Cookies, sodass die Weitergabe in der URL als Fallback-Methode häufig angeboten wird. Dort kann der Angreifer ansetzen und zufällige Session-Keys in hoher Geschwindigkeit durchprobieren. Hat er gar Kenntnis über die Existenz eines aktiven Session-Keys, so kann er mit deren Hilfe versuchen, die entfernte Sitzung zu übernehmen. Der betroffene Nutzer bekommt dies nicht unbedingt zu spüren.

Prävention: Die IP-Adresse

Neben der Browser-Kennung ist zum Beispiel die IP eine gute Methode, um Session Hijacking zu verhinden. Diese ist für einen Rechner im Internet eindeutig, allerdings nur für die Zeit der aktiven Nutzung, was in diesem Falle reicht. Durch die Knappheit der IP-Adressen halten Provider einen gewissen Pool von IP-Adressen bereit, von denen bei der Einwahl eine mehr oder weniger zufällig vergeben wird.

Allerdings ist hier Vorsicht geboten, da viele Nutzer hinter Web-Proxies surfen, die ihn in gewisserweise anonymisieren. Dies ist dem Surfer nicht immer bekannt, da große Zugangsprovider oft eigenes transparentes Proxy-Caching betreiben. In diesem Fall liegen viele Nutzer hinter nur einer sichtbaren IP-Adresse. Proxies können diese Weiterleitung über die HTTP-Header-Felder X_FORWARDED_FOR oder CLIENT_IP_ADRESS bekanntmachen. Doch die Angaben sind optional (ohne Gewähr) – verlassen kann man sich also darauf nicht.

Daneben gibt es fast überall lokale Netze (LANs), deren Benutzer alle mit der IP des Zugangsrechners (Gateways) surfen. Wenn wie in Firmen durch Standardisierung gleiche technische Bedingungen vorliegen, in dem Betriebssysteme und Browser vorgegeben werden, so erscheinen dem Server alle Benutzer dieses Netzwerks wie ein identischer Client.

Daneben kann es passieren, dass Zugangsprovider Proxying mit wechselnden End-IP-Adressen durchführen. AOL ist dafür bekannt. Dies erschwert dem Server, eine Session zumindest einer IP zuzuordnen. Um den Nutzer nicht zu verlieren, müssen Sub-Netze für die Weitergabe der Session erlaubt werden, doch selbst Class-B-Netze (zB. 123.5.xxx.xxx) werden hier oft verlassen.

Fazit: Mißtrauen ist gut, Kontrolle nicht möglich

In dieser Situation einen Spagat zwischen Kundendaten-Sicherheit wie den Schutz eingegebener Kreditkartendaten und das Angebot nutzerfreundlicher Sites hinzubekommen, fällt schwer. Was der Datenschutz auf der einen Seite richtig macht (das anonymisierte Surfen), erschwert den Datenschutz des Benutzers an anderer Stelle, nämlich in Online-Shops, Foren, Chat-Rooms oder Email-Services – überall dort, wo ein Login mehr als einen Click halten muss.

Letztendlich ist eine Sicherheitslücke wohl von schwererem Ausmaß als der Verlust einer Session – denn diese kann mit einem anderen Browser wiederholt werden. Daher gilt in meinen Augen folgende Regel: Strikte Prüfung des Logins und Vorbeugung von Session-Hijacking – kombiniert mit Empfehlungen (zB im Fehlerfall anderen Browser vorschlagen), die dem Surfer die Vertraulichkeit seiner eigenen Daten bewusst macht. Nur dies schafft langfristigen Datenschutz!