Ein sehr gute Ergänzung zur Analyse der Browsersicherheit im Buch findet sich in der neuen Thesis von Bastian Zimmermann zur clientseitigen Sicherheit im Browser . Während sich "Sichere Systeme" in Bezug auf die Browsersicherheit hauptsächlich mit Softwarefehlern, overflow Attacken und generell der Unfähigkeit zur Einschränkung von Schäden beschäftigt setzt Zimmermann einen ganz anderen Schwerpunkt: Er stellt die Frage in wieweit der browser ein fairer Partner des Bentuzers ist und dessen Interessen schützt. Und er geht dabei folgendermassen vor. Nach der Vorstellung einiger klassischer sowie neuer Attacken - Gifjar und clickjacking z.B. wird ein Konzept von Abwehrmassnahmen entwickelt mit denen der Browser Aktionen und Daten des Benutzers schützen könnten indem er auf Wissen um die Kommunikation zurückgreift.

Zimmermann kommt dabei zu sehr interessanten wie auch bestürzenden Ergebnissen. Weder Internet Explorer noch Firefox nutzen in der Grundkonfiguration Chancen zur Absicherung des Benutzers. Zumindest im Fall des Firefox klingt das überraschend auf den ersten Blick. Nimmt man dann aber z.B. die Defensivfähigkeiten des neuen Google Browsers zum Vergleich hinzu wird eines deutlich: Die Browser-Entwickler scheinen bezüglich Sicherheit in erster Linie an die Sicherheit des Browsers selber zu denken, und nicht an den Benutzer. Erst durch den Einsatz von Noscript oder Controle de Scripts bietet der Firefox erheblich mehr Absicherung der Userdaten und Aktionen.

Was könnte der Browser tun? Zimmermann stellt hier eine ganze Reihe von Möglichkeiten vor den User vor - zunehmend semantischen - Attacken zu schützen. Clickjacking besteht darin dem User eine Schaltfläche zu präsentieren die überlagert ist von einem anderen Objekt und die der User dadurch nicht als solches erkennen kann. Somit erteilt der User fälschlicherweise eine Erlaubnis durch einen Click die er gar nicht beabsichtigt hatte. Der Autor weist nun darauf hin dass der Browser ja eigentlich weiss dass die Schaltfläche verdeckt ist und er könnte den User warnen - tut er aber nicht.

ähnlich lässt sich in den Fällen argumentieren bei denen durch CSRF Attacken User Credentials verraten werden. Der Browser weiss doch dass ein Link von einer anderen Seite kommt und könnte dann die Credentials verweigern. Globale Cookie-pools stehen jedoch einer besseren Kontrolle der User Credentials im Wege.

Die Liste der Möglichkeiten des Browsers lässt sich noch lange fortsetzen. So kann der Browser DOM-basierte XSS Attacken durch eine Analyse der URL verhindern. Teilweise erweisen sich Abwehrmassnahmen wie z.B. die gelbe Leiste im Internet Explorer die Benutzer auf unterdrückte Popups hinweisen soll auch als völlig untauglich da in das gewohnte Feld der Webapplikation eingebettet. Der Benutzer muss für Sicherheitskritische Aktionen einen sog. "Trusted Path" - also eine klar abgegrenzte Zone des Vertrauens vorfinden. Dies kann nicht innerhalb des allgemeinen Platzes einer Page sein.

Eine wichtige Rolle innerhalb der Arbeit spielt natürlich die Benutzbarkeit. Ein granulare Konfiguration von Sicherheitsmassnahmen scheitert meist daran dass die Begriff den Benutzern völlig unverständlich sind (siehe IE Sicherheitsoptionen) und dass sie schwer sinnvoll einzusetzen sind (temporär? persistent?). Auch plug-ins wie Noscript sind hier noch keineswegs befriedigend und führen immer wieder zu Situationen in denen die aufgerufenen Sites nicht richtig funktionieren. Laien sind dann meist überfordert und erkennen nicht dass eine einfache Wiederholung der temporären Erlaubnis das Problem meist löst. (Allerdings lässt sich auch argumentieren dass eine Site die wichtige Teile ihrer Benutzung in einem Popup versteckt ihre Besucher eigentlich auch gar nicht verdient...)

Was bleibt zu tun? Die Thesis von Bastian Zimmermann bietet einen ausgezeichneten Startpunkt die clientseitige Sicherheit im Browser einmal inklusive eines Usability-Konzeptes und der Modellierung der Konzeptuellen Modelle der Benutzer zu untersuchen. Assoziieren die Benutzer das was die Entwickler meinen? Diese Frage lässt sich berechtigterweise z.B. beim Cookie-Mechanismus stellen? Denken Benutzer in Zonen (IE) oder in Aktionen? Darüber hinaus müsste geklärt werden welche Seiten bzw. welche Mechanismen es sind die bei einem Browser der den Benutzer tatsächlich schützt letztendlich nicht mehr funktionieren würden. Am Besten durch eine Integration der vorgeschlagenen Abwehrmassnahmen in den Firefox mit anschliessender empirischer Untersuchung der Usability von Browser und Websites. Daraus liessen sich Anweisungen für den Bau von Webapplikationen ableiten die auch in einem sicheren Browser noch funktionieren würden.

Eines muss in dem Zusammenhang ganz klar gesagt werden: Die Aufforderung Javascript einfach abzuschalten ist nicht mehr zeitgemäss und auch nicht durchsetzbar. Der Autor macht dies auch deutlich und zeigt Wege der Absicherung von Javascript auf. Auf die Problematik von Filtern wird dabei auch eingegangen.

Unser Gastautor Fred Spiessens hat eine Site extra für die Sprache Scoll und den Modellchecker Scollar aufgesetzt. Sie ist zu finden unter Scoll und Scollar

"Multitenant" Systeme werden im Buch als grundsätzlich virtualisierte Systeme beschrieben: aller Input und Output muss durch eine Virtualisierungsschicht vermittelt werden. Das bedeutet dass auch zur Authentisierung unterschiedlicher Kundenkreise jeweils unterschiedliche Repositories herangezogen werden sollten. Es sollte klar sein dass verschiedene Instanzen z.B. einer Kundenverwaltung auf Basis von SaaS (Software as a Service) nicht ein gemeinsames Administrationskennwort haben können. Die Deutsche Telekom hat gerade wieder demonstriert welche Folgen es hat wenn unterschiedlichste Zweigstellen etc. mit dem gleichen Administrationsaccount für alle Kundendaten arbeiten.

Ein interessanter Artikel beschreibt die Architektur unter Verwendung von LDAP um eine Authentisierung in einem mandantenfähigen SaaS System durchzuführen. Der Artikel ist von Massimiliano Parlione und Chico Charlesworth, beide IBM und heisst: Securing A Multitenant SaaS Application.

Hier kommt ein Tipp von Thomas Reuter: Ein Vortrag über CSS, injection flaws und CSRF mit Beispielcode in PHP. Es ist die Web Security Demo von Tony Bibbs mit einem Zip File zum herunterladen.

Sehr empfehlenswert für alle die die Attacken in diesem Band nachspielen wollen.