Die Sicherheit eines Browsers sehe ich vor allem in zwei Bereichen:

1. Sicherheit gegenüber der Datenkrake (Browser-Hersteller überwacht Benutzer)
2. Sicherheit gegenüber einem oder mehreren Webservern (der Browser ist für Angriffe anfällig)

Sicherheit gegen eine permanente Überwachung

Zum 1. Punkt gab es in Version 5.0 insgesamt nur wenige Häkchen, die meines Erachtens dazu führten, dass der Benutzer irgendwie stetig unter Kontrolle stand: “Vorschläge für Navigationsfehler anzeigen”, “Phishing- und Malware-Schutz aktivieren” und “Helfen Sie mit, Google Chrome zu verbessern…Nutzungsstatistken…”. Diese Punkte standen recht offenkundig im Optionen-Menü und ließen sich schnell deaktivieren. Neben diesen Punkten sollte Google in keinem Falle nach Hause gefunkt haben. Sportliche Netzwerker würden hier, weil Google eben auch stark im Verdacht stand, sicherlich schon das ein oder andere Sniffing-Tool mitlaufen lassen haben. Bei positivem Test hätte es definitiv auch schon Aufruhr gegeben. Ich denke auch, dass sich Google im umstrittenen Browser-Gefecht solche gern aufgegriffenen Gegenargumente ersparen möchte, wenn Chrome sich langfristig etablieren soll.

Firefox ist an dieser Stelle übrigens nicht ganz so transparent: Zunächst muss man die versteckten Config-Einstellungen erst einmal finden: Man gibt hierfür in die Browser-Zeile “about:config” ein und bestätigt eine Warnmeldung “Blabla, ich bin nun selbst verantworlich…blabla…” und schließelich sucht man nach dem Schlüssel “safebrowsing.enabled” und schaltet diesen auf “false”.

In Alu-Version 6.0 sind noch diverse andere Optionen hinzugekommen. Unter anderem lässt sich nun das Verhalten bei Drittcookies steuern, welches ich dringend empfehle auf “keine Website” zu setzen. Denn auch Drittanbieter-Cookies führen zu einer schleichenden Dauerüberwachung. Ganz klar natürlich, wer sich Browser-Toolbars von Yahoo! oder Google installiert, der ist auf jeden Fall in “sicheren Händen”.

Neu in Version 6.0 ist die Autofill-Funktion. Hier kann man seine persönlichen Daten wie Adresse und Kreditkarten-Informationen fest im Browser hinterlegen. Auf Seiten mit entsprechend ausgestatteten Eingabefeldern kann Google Chrome dann diese zum Ausfüllen benutzen. Naja, wer’s braucht.

Sicherheit gegen Angriffe

Zur Sicherheit des Browsers gegenüber einem Webserver gilt zunächst, dass Google Chrome die Webkit-Engine nutzt und damit ein ausgereiftes Rendering anbietet. Daneben läuft jedes Tab in einem eigenen Prozess und kann daher den Browser oder andere Tabs nicht zum Absturz bringen. Das ist gut und trägt entscheidend zu einem sicheren Surfen bei. Obgleich nicht kommuniziert, hoffe ich, dass somit auch diverse Informationen eines Tabs aus einem anderen auf keinen Fall sichtbar sind.

Natürlich machen auch Google-Programmierer Fehler. Chrome als junges Produkt hat mit Sicherheit eine Menge Bugs im Quellcode versteckt. In den letzten Wochen fiel Google jedoch mit schnellen Bugfixes auf, ebenso sind Updates über das Repository sehr zeitnah im Umlauf. Da kann sich das Firefox (Iceweasel)-Team von Debian noch eine Scheibe abschneiden. Allerdings kennzeichnet Google den Chrome noch als Beta.

Die Java-Script-Engine V8 des Chrome ist sehr, sehr schnell. Für den Vergleich mit Firefox (lame!) nehme ich gern die Seite htmlspecialchars von PHP unter die Lupe. Ein Umschalten zwischen verschiedenen Tabs ist wie der Unterschied zwischen Tag und Nacht. Doch obgleich diese hohe Geschwindigkeit wirklich gut für ein angenehmes Arbeiten ist, habe ich hier die größten Bedenken. Werden genügend Bedingungen geprüft? Ist das Datenmodell ordentlich gekapselt oder eher auf Geschwindigkeit getrimmt?

Fazit

Google Chrome ist per se nicht unsicherer als andere Browser. Im Gegenteil: Durch das Auftrennen der Tab-Prozesse sollte sich das grundlegende Sicherheitslevel erhöht haben. Und wer die Optionen nicht sorglos wählt, darf davon ausgehen, seine Privatsphäre gegenüber dem Hersteller zu beschützen. Geschraubt haben der Riese auf jeden Fall an der Performance – die ist vorbildlich, und mir kommt es so vor, als ob 6.0 noch ein Zacken schneller startet als die 5.0. Dennoch ist Chrome noch Beta-Ware, und im jugendlichen Code werden im Laufe der Jahre garantiert eine Menge Lücken sichtbar werden. Auf Chrome’s Javascript werden wir meines Erachtens auf jeden Fall noch viele erfolgreiche Angriffe sehen. Ich hoffe, Google bleibt weiterhin ein fixer Bugfixer.

Profitieren von Web-Sockets werden in erster Linie Anwendungen mit Echtzeit-Charakter: Online-Kooperations-Software wie Google Docs oder Chat-Systeme, die eben im Sande verlaufene Google Wave könnte ebenso wieder auferstehen, und Online Games könnten schneller, aber schlanker werden. Denn der Browser muss für die Aktualisierung nicht ständig den Server befragen, ob es neue Daten gibt: Sobald diese da sind, kann der Server diese dem Client nachsenden.

Das ist eine ganz andere Art HTTP, als wir sie bisher kennen, aber es ist eine coole und smarte Art. Ich habe mal für einen Automobilkonzern in einem Software-Projekt gearbeitet, wo es um eine Dokumentation von Fahrzeugstrukturen ging. Durch die Tiefe der Strukturen (Module, Stücklisten, Assemblys) konnte praktisch ständig mit einer Änderung gerechnet werden. Hier hätte die Software auf Basis eines Web-Clients wohl nur noch gepingt und geflackert. Mit einem PUSH-Modus wäre ein Web-Client als Implementationsplattform viel attraktiver gewesen (als es dieses komische Enterprise Java anscheinend war ), und man hätte viele geniale und interaktive Dinge damit machen können.

HTML/HTTP als Entwicklungsplattform

Neben diesem Aspekt gewinnt HTML/HTTP als Implementationsplattform noch an einer anderen Stelle gegenüber “herkömmlichen” Widget-Sets an Charme: Die Standardisierung ist hier etwas ganz einzigartiges. Es gibt für kein Widget-Set der Welt eine internationale Norm: Weder für GTK+, noch für Qt, MFC oder ein anderes Framework. HTML als grafische Benutzer-Schnittstelle ist dabei nicht nur menschenlesbar (und damit im Fehlerfall vom Benutzer debugfähig und interpretierbar), es ist zum anderen auch komplett plattform-neutral, portabel und durch ein unabhängiges Gremium standardisiert.

Man kann also die Rendering Software (den Browser) ebenso wechseln wie die Maschine, dessen OS, Standort oder IP.  Ebenso lassen sich durch die flexible Architektur Inhalte für verschiedene Geräte unterschiedlich aufbereiten und sogar während der Benutzer-Sitzung anders implementieren, ohne dass die Software (was in diesem Fall eine Session wäre), neu gestartet werden muss. Insofern muss ich mal eine ganz dicke Lanze für HTML/HTTP für die Applikationsentwicklung brechen.

Rapid Prototyping, Internationalisierung et cetera – all inclusive

Ebenso unterstützt HTML/HTTP das Design-Prinzip Rapid Prototyping, und für verschiedene Layer wie Persistenz-Schicht, Models, Controller oder Views einer klassischen Programmierersicht gibt es diverse Hilfsmittel. Je nach dem, wie man arbeiten möchte, kann man von den Models automatisch Views und Persistenzen erzeugen lassen, wie auch andersherum. Mit Java, ASP, PHP oder Perl (und sogar C++) stehen dem Entwickler diverse Sprachen zur Verfügung, während dies für den Benutzer absolut transparent bleibt. Man könnte sogar einige Module in Perl, andere in Java oder ASP umsetzen. Neben einem Mini-System lässt sich die Applikation dann a) super-easy “deployen” – dieser Schritt entfiele ja fast – aber auch ebensogut horizontal skalieren, wenn die Benutzerzahl ansteigt.

Die Internationalisierung von Applikationen gestaltet sich besonders einfach, wobei der Browser mit Accept-Headern als Mittler zwischen Benutzer und dessen Sprachauswahl dient. Diverse andere Vorzüge, die mir dazu noch einfallen (Trennung von HTML, CSS und Javscript, der Rechner müllt nicht mit der Benutzer-Konfig zu, man braucht keine Installation, zentralisierte Datenspeicherung, etc.) lassen HTML/HTTP gegenüber anderen GUI-Frameworks immer öfter den Vorzug geben. Und schließlich kommen nun noch Web-Sockets um die Ecke und lassen das HTTP-Protokoll noch einmal kräftig zulegen.

Meiner Meinung nach läuten die Glocken ganz, ganz deutlich: Wer interaktive Applikationen schreibt, sollte ganz offensichtlich eine Online-Implementierung abwägen. Ich freue mich jetzt schon auf diverse neue Spielwiesen, die dabei entstehen werden.

Doch warum gibt es immer wieder neue Sicherheitslücken?

Hier überlagern sich meines Erachtens mehrere Teilprobleme:

1. Technologie-Wandel: Die Welt ist im stetigen Wandel. Software bildet aber immer nur einen Snapshot, einen momentanen Wissenstand ab. Was zukünftig damit zu verarbeiten ist, ist bei Erstellung der Software unklar.
2. Die Kommerzialisierung der Netzkultur fordert ihre Opfer: Das Netz wird zum Angriffsziel derer, die nicht zur Loge seiner offiziellen Beherrscher gehören. Im Zeitalter der Information ist der Besitz von Daten, Servern, Technologien wie auch das Wissen zur Manipulation und Zerstörung von Infrastruktur bares Geld wert.
3. Die Geschwindigkeit, in der Software erstellt, konsumiert (benutzt) und entsorgt wird, ist gegenüber traditionellen Produkten unvergleichbar erhöht. Die Kosten durch Schaden aus Software-Fehlfunktionen wird weiterhin unterschätzt – Software macht ja (zunächst) nichts wirklich kaputt. Aus diesem Kreativitätsdruck heraus wird viel zu unreife Software auf den Markt geworfen: Früher oft Bananensoftware – reift beim Kunden – genannt, findet im Netz seine Fortsetzung in der beta-Kultur des Web 2.0.
4. Die Schnittstellen von verschiedenen technologischen Bereichen sind inkompatibel. An diesen Reibepunkten entstehen Konvertierungsverluste, die nur mit ungemein hohem Aufwand optimal unterdrückt werden können. Gerade hier wird oft die 80:20-Regel der Softwareerstellung zugunsten der schnellen 80%-Funktionalität vorgezogen: Es funktioniert, im Prinzip, wenn man es so oder so benutzt. Ein Beispiel: Desktop und Netz. Sie funktionieren anders und sind für andere Daten konzipiert. Ein Übergang Netz -> Desktop oder Desktop -> Netz ist extrem fehleranfällig.
5. Software ist nicht immer frei. Unfreie Software kann weder von Sicherheitsexperten begutachtet, noch von so vielen freiwilligen Helfern verbessert werden. Firmen glauben leider immer noch an das Mysterium Software-Monopol. Aber das weiß der geneigte Leser dieses Blogs sicherlich besser…

In eingangs genannten Fall sind

• die Sicherheitsfunktionen der Browser auf dem Stand der Netzangriffe vor Erstellung der jeweiligen Version
• der Flash-Player eine proprietäre unkontrollierbare Software
• die Schnittstelle zwischen HTML und Flash mehr als unausgereift und nicht standisiert
• die Rückverfolgbarkeit von Angriffen auf das eigene System nur für Experten machbar

Man kann nur hoffen, dass der kommende Standard von HTML 5.0 unter Webentwicklern angenommen und durch die Integration von Ogg Theora und SVG die Verbreitung binärer Plugins eingedämmt wird.

just my 2 cents

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:

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:

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!