Sicherheit im Internet - Teil 1 back to frontpage

In Ergänzung zu meinem Blogpost Die Falle des prefetching möchte ich in diesem Blogpost noch etwas ausführlicher auf Probleme (und mögliche Problemlösungen) eingehen, die während des Surfens durch’s Netz auftauchen. Ich bin kein Fan von Hysterie, jedoch ein gesundes Misstrauen und ein bewusstes, informiertes Handeln und Nutzen des Mediums macht es einfacher zu Verstehen, wie man Problemen aus dem Weg gehen und seine Privatsphäre besser schützen kann.

Um zu verstehen, mit welchen Tools man den Gefahren Herr werden kann, stelle ich zunächst in diesem Teil 1 meiner Blogpostserie einige der Techniken (sowie die damit verbundenen Sicherheitsprobleme und Problemlösungsansätze) vor, die im Web zum Einsatz kommen, um dem Leser danach im Teil 2 konkrete Software- und Konfigurationsempfehlungen zu geben, die die Problemlösungen aus diesem Teil aufgreifen und umsetzen.

Die vorgestellten Techniken sind keineswegs Teufelswerk, sondern überwiegend sinnvoll, notwendig und beeinflussen nicht zuletzt auch - richtig eingesetzt - den Komfort beim Surfen in positiver Weise. Zu den Schlagwörtern gehören JavaScript, Cookies und Plugins wie Flash oder Java. Etwas weniger bekannt dürften iframes sein, die jedoch auch eine große Rolle beim Thema Sicherheit spielen. Gesicherte Verbindungen mittels https dürfen beim Thema Sicherheit im Internet natürlich nicht fehlen und werden von mir daher auch diskutiert. Teil 1 ist damit vollständig.

An konkreten Umsetzungen der diskutierten Problemlösungsansätze wären hier die Firefox Add-Ons (Erweiterungen) NoScript, AdBlock Plus, RequestPolicy, CookieMonster, Better Privacy und HTTPS Everywhere zu nennen. Für andere Browser gibt es für einige Add-Ons Äquivalente, für andere leider nicht. Firefox bietet hier derzeit noch die größte und beste Auswahl an Tools, um die Sicherheit beim Browsing zu erhöhen. Ich werde jedoch bei den einzelnen Add-Ons auf mögliche Alternativen für den Browser Chrome hinweisen. Mangels Kenntnisse über mögliche Add-Ons für Opera und den Internet Explorer kann ich hier leider keine größeren Tipps aussprechen, bin jedoch für jeden Hinweis in den Kommentaren dankbar!

Ein kleiner Disclaimer vorab: Mir ist bewusst, dass die technische Sicht in dieser Blogpostreihe von mir teils vereinfacht dargestellt wird und von Details abstrahiert. Dies hat schlicht den Grund, um sich auf die Kernproblematik zu konzentrieren und zu verdeutlichen, wie etwas funktioniert und warum es unter Umständen problematisch ist. Zu viele zusammenhanglose Details sind da nicht nützlich.

Kleines Vorwort: Warum Techniken einschränken?

Bevor ich den Punkt “Warum?” für die einzelnen Techniken im Detail kläre (siehe dazu weiter unten ausführlich), möchte ich zunächst einen allgemeingültigen Grund dafür liefern, warum es sinnvoll ist den Einsatz von Techniken auf Webseiten gemäß der Regel “Was nicht explizit erlaubt ist, ist verboten” zu reglementieren:

Keine Software ist wirklich zu 100% sicher (im Sinne von Abwesenheit von Gefahren oder Risiken). Damit könnte ich den Punkt eigentlich auch schon abhaken. Aber so einfach möchte ich es mir nicht machen, sondern eine etwas ausführlichere Begründung liefern:

Es liegt in der Natur von Software, dass diese Fehler enthält. Software wird von Menschen entwickelt, und Menschen machen Fehler. Je größer und komplexer eine Software ist, desto mehr Potential hat sie, fehleranfällig zu sein. Jeder Softwarehersteller muss sich daher Gedanken zum Thema Sicherheit machen, insbesondere im Hinblick auf den Gefährdungsgrad. Browser sind komplexe Anwendungen, die sich einer nicht überschaubaren Anzahl Gefährdungen gegenübersehen (dem Internet). Ein kleiner Taschenrechner hingegen ist weniger komplex und hat einen wesentlich geringeren Gefährdungsgrad, da dieser (in der Regel) nur mit dem Benutzer vor dem Computer interagiert.

Browser sind beliebte Angriffsziele, da sie heutzutage praktisch auf jedem Computer (vor-)installiert sind und einen direkten - vielleicht sogar den direkten - Draht zu einem möglichen Opfer darstellen (neben E-Mail, wobei hier der Aufwand ungleich größer ist). Browserhersteller müssen sich daher aufgrund der großen Komplexität, dem hohen Verbreitungs- und damit hohem Gefährdungsgrad wesentlich mehr Gedanken über potentielle Risiken machen und Sicherheitstechniken entwickeln, um mögliche Sicherheitsprobleme zu minimieren. Stets die aktuellste Browserversion installiert zu haben ist daher praktisch Pflicht und wenn nicht sogar schon fast fahrlässig, wenn man noch mit einer veralteten Version im Web unterwegs ist. In diesem Zusammenhang sind insbesondere so genannte 0day-Attacken zu nennen. Es handelt sich dabei um das böswillige aktive Ausnutzen von Sicherheitslücken, die selbst dem Hersteller bislang unbekannt sind. In solchen Fällen ist eine besonders schnelle Reaktion des Softwareherstellers in Form eines Updates notwendig (und der damit verbundene Aktualisierungsvorgang auf dem Rechner, auf dem die Software installiert ist!); manchmal hat man das Glück, dass man die betroffene Komponente (zum Beispiel die JavaScript-Engine oder das Plugin Flash) im Browser deaktivieren kann.

Gängige Browser können durch Plugins und Add-Ons (Erweiterungen) erweitert werden.

Plugins werden regelmäßig dazu genutzt, Medieninhalte im Browser darzustellen. Hierzu gehören zum Beispiel der Acrobat-Reader, der PDF-Dateien im Browser eingebettet darstellt, Flash, das Videos und sonstige Animationen auf Webseiten ermöglicht, Java für kleine Java-Applets und andere Video-Plugins zur Darstellung von Video-Dateien im Browser. Add-Ons erweitern in der Regel die Funktionalität des Browsers (zum Beispiel könnte ein Add-On weitere Informationen zur Vertrauenswürdigkeit einer Webseite in der Toolbar neben dem Adressfeld anzeigen).

Add-Ons sind prinzipbedingt weniger Gefahren ausgesetzt als es Plugins beispielsweise sind, können jedoch auch ein Risiko darstellen. Insbesondere sollte eine gesunde Vorsicht vor unbekannten oder weniger bekannten Add-Ons an den Tag gelegt werden; man sollte sich vor der Installation eines Add-Ons genau überlegen, ob man ein Add-On benötigt, oder nicht (es gab zum Beispiel bereits Fälle, bei denen ein Add-On einen Trojaner enthielt). Add-Ons werden je nach Browser und eingeräumten Zugriffsrechten unterschiedliche Zugriffsmöglichkeiten auf das eigentliche System, Seiteninhalte, Lesezeichen, Cookies u. ä. gewährt. Bösartige Add-Ons können diese Rechte missbrauchen, um den Benutzer zu schädigen oder auszuspionieren. Die Rechte sind jedoch auch gleichzeitig nötig, um zum Beispiel Add-Ons zu entwickeln, die automatisch Seiteninhalte filtern und unliebsame Elemente entfernen (Werbeblocker).

Dem Benutzer bleiben nur wenige, aber effiziente Möglichkeiten, den persönlichen Gefährdungsgrad weiter zu reduzieren.

Hierzu gehört das Deaktivieren von ungenutzten und nicht benötigten Plugins, da diese sehr oft weitere Tore zum Computersystem in Form von Sicherheitslücken öffnen (Flash ist hierfür ein sehr gutes Beispiel, dazu jedoch später mehr). Ebenso erreicht man einen guten Grundschutz, indem man potentiell anfällige Browser-Funktionen (hier ist insbesondere JavaScript zu nennen, siehe auch oben 0day-Attacken) nur für Webseiten freischaltet, denen man ein gewisses Vertrauen entgegenbringt. Gefährlichen oder unseriöse Webseiten (also solche, die möglicherweise über Schadcode und Sicherheitslücken versuchen könnten, das Computersystem zu kompromittieren), insbesondere jene, die man nicht explizit selber geöffnet hat (siehe später iframes oder in meinem oben verlinkten Blogpost “Die Falle des prefetching”), nimmt man mit solchen Verfahrensweisen erheblichen Wind aus den Segeln, mithin reduziert man also die möglichen Angriffspunkte und erhöht somit die Sicherheit beim Surfen.

Vor der Installation eines Add-Ons sollte man sicherstellen, dass man es von einer vertrauenswürdigen Quelle (zum Beispiel von der Seite des Herstellers oder aus dem Mozilla Add-On Katalog) installiert; zudem sollte man die Rezensionen und die Anzahl Downloads überfliegen und sich selber fragen: Reichen einem die positiven Rezensionen, kann man mit den negativen Seiten des Add-Ons leben und ist es bereits ausreichend verbreitet (Anzahl Downloads/Installationen)?

Nachdem ich nun allgemeine Gründe erörtert habe, die beim Einsatz von Techniken im Web die Vorgehensweise “Was nicht explizit erlaubt ist, ist verboten” rechtfertigen, möchte ich nun detailliert die im Web eingesetzten Komponenten und ihre Gefährdungen vorstellen. Im Teil 2 werde ich Add-Ons für Firefox vorstellen, die mögliche Angriffspunkte reduzieren und Datenschutz sowie die Selbstbestimmung beim Surfen erhöhen.

Für alle, die meinen Beitrag zum prefetching noch nicht gelesen haben, empfehle ich sich diesen Beitrag zunächst zu Gemüte zu führen, um eine wichtige Grundlage für die Selbstbestimmung zu schaffen.

Cookies und Tracking

Cookies sind ein notwendiges Instrument in unserem Netzzeitalter. Sie ergänzen das Protokoll HTTP (Hypertext Transfer Protocol), über das die Webseiteninhalte ausgeliefert werden, um die Möglichkeit, Zustände zu definieren. HTTP kommt alleinig die Aufgabe zu, Daten (Webseitenquelltexte, Bilder, Videos, etc.) zu transportieren. Es arbeitet zustandslos und weiß beispielsweise nicht, ob der Client (Besucher der Seite) aktuell auf einer Webseite eingeloggt ist, oder nicht. Diese wichtige Funktion erfüllen die Cookies.

Eine typische Anmeldeprozedur (“Login”) auf einer Communityseite könnte zum Beispiel folgendermaßen ablaufen:

  1. Benutzer surft http://www.mycommunity.tld/login an. Per HTTP werden alle benötigten Inhalte vom Server an den Benutzer übertragen.

  2. Der Benutzer gibt seine Benutzerdaten auf der Anmeldeseite ein und drückt auf “Login”. Die Anfrage wird per HTTP an den Server übertragen, dieser prüft daraufhin die Benutzerdaten und erzeugt eine Sitzung (serverseitig, zum Beispiel in einer Datenbank), die eindeutig über ein zufällig generiertes Passwort identifizierbar ist.

  3. Jetzt kommen die Cookies ins Spiel: Der Server weist mit einem bestimmten Befehl per HTTP den Browser des Benutzers an, dieses Sitzungspasswort, über das der Server die Sitzung wiederfinden kann, im Browser des Benutzers unter dem - hier frei gewählten - Namen “session” zu speichern. Der Browser kommt dieser Anfrage nach und legt diese Informationen lokal ab.

  4. Mit jeder zukünftigen Anfrage an die Community-Seite übermittelt der Browser automatisch das Sitzungspasswort unter der Bezeichnung “session”. Der Server kann nun zunächst der Anfrage (zum Beispiel das Aufrufen der Profilseite eines Freundes in der Community) die passende Sitzung zuordnen. Aus der Sitzung kann er entnehmen, dass der Benutzer mit dem Inhaber des angeforderten Profils befreundet ist. Er lässt daher die Anfrage zu und übermittelt die Profilseite an den Browser. Hätte der Browser das Sitzungspasswort nicht übermittelt, hätte der Server keine Informationen darüber gehabt, ob der Besucher der Seite die nötigen Berechtigungen hat, das Profil einzusehen. Der Server hätte die Anfrage im Zweifel verweigern müssen.

Ohne Cookies läuft also nichts mehr! Warum werden sie dann jedoch oft so verteufelt? Das Problem liegt an der Medaille, die bekanntlich zwei Seiten hat.

Große Werbenetzwerke (zum Beispiel AdSense von Google) oder andere Datenkraken (die Google-Suche wird hier sehr oft als Beispiel gebracht) nutzen Cookies, um Benutzer eindeutig zu identifizieren. Dabei erzeugen sie für jeden Besucher ein neues Profil und speichern dieses in ihrer Datenbank ab. Sie weisen den Browser des neuen Besuchers an, die Profilnummer als Cookie zu hinterlegen.

Große Werbenetzwerke sind deshalb groß, weil sie von vielen Webseitenbetreibern extern eingebunden werden (die berühmte Werbung auf den Webseiten). Mit jedem Webseitenaufruf, das ein Werbeelement des Werbenetzwerkes enthält, fragt der Browser zunächst per HTTP beim Werbenetzwerk die Daten für die Werbeeinblendung ab. Hat der Benutzer bereits eine Profilnummer in seinem Browser als Cookie hinterlegt bekommen, übermittelt er die Profilnummer an das Werbenetzwerk. Bis hier wäre es noch nicht weiter problematisch: das Werbenetzwerk kennt bis jetzt nur die Zugriffszeit und die Bitte unseres Browsers, Werbung an ihn auszuliefern. Das eigentliche Problem hierbei liegt beim sogenannten Referrer. Mit jeder HTTP-Anfrage, die der Browser verschickt, überträgt er auch die Verweisseite, von der diese Anfrage kam. Bindet die Community also Werbung ein, erhält das Werbenetzwerk innerhalb der HTTP-Anfrage die Mitteilung, dass die Werbung auf der Community eingebunden werden soll.

Dies stellt insgesamt schon eher ein Problem dar, da sich nun mit zunehmendem Verbreitungsgrad des Werbenetzwerkes (und unter uns: Google AdSense ist wirklich erschreckend oft im Netz anzutreffen) detaillierte Benutzerprofile erzeugen lassen. Jeder Seitenaufruf kann im Werbenetzwerk dem Profil zugeordnet werden; mit der Zeit lassen sich aus dem Profil werberelevante Informationen extrahieren (insbesondere Interessen oder demographische Merkmale wie Alter, Geschlecht, Nationalität, etc.). Diese Informationen werden genutzt, um die Art der Werbeanzeigen, die an den Benutzer ausgeliefert werden, zu optimieren. Dabei wird beispielsweise jemandem, der sich zuletzt auf einer Hobbyseite, die Werbung eingebunden hat, zum Thema Fische informiert hat, auf der nächsten Seite (die wiederum nicht mit der zuerst genannten Hobbyseite in Verbindung steht) Werbung zu Fischfutter oder Fischbörsen angezeigt werden. Beim Thema Fische möge der ein oder andere noch darüber hinweg sehen, dass andere wissen, dass er an Fischen interessiert ist. Wenn es jedoch um intimere und persönlichere Themen wie der sexuellen Orientierung, Krankheiten oder ähnlichem geht, wird dies aller Wahrscheinlichkeit nach in einem anderen Licht gesehen.

Es gibt nun verschiedene Ansätze, wie man diesem Problem des Verfolgens (Tracking) Herr wird:

  • Do Not Track (DNT) ist eine Erweiterung des HTTP-Protokolls, das über einen speziellen Hinweis in der Anfrage jedem Server mitteilt, dass der Benutzer kein Tracking wünscht. Dies verhindert zwar nicht die Auslieferung von Werbung, jedoch kann es die Profilbildung verhindern. DNT ist (noch) nicht verbindlich für Werbenetzwerke (im US-Kongress wird dies wohl aktuell diskutiert). Es kann jedoch in keinem Fall schaden, DNT zu aktivieren (siehe Teil 2 meiner Blogpostreihe).

  • Cookies aktiv verwalten, bedeutet: Nur Cookies von Seiten zulassen, denen man Vertrauen entgegen bringt und bei denen Cookies zum Betrieb der Seite notwendig sind (bei einer Communityseite ist dies aus oben genannten Gründen der Fall; bei einer reinen Newsseite ohne Anmeldung nicht). Tools hierfür werde ich im Teil 2 vorstellen.

Cookies haben regelmäßig ein Verfallsdatum. Zum Beispiel können Sitzungscookies nur so lange gültig sein, bis der Browser geschlossen wurde. Nun gibt es jedoch auch “Local Shared Objects” (LSOs). Dies sind Cookie-ähnliche Objekte, die über ein Browser-Plugin auf dem Computer abgelegt werden und sich der Verwaltung durch den Browser entziehen. Das gängigste Beispiel hierfür ist das Plugin Flash. Auch wenn es eigentlich eine Flash-Eigenheit ist und im unteren Plugins-Teil meines Blogposts erörtert werden müsste, gehört es dennoch thematisch zu den Cookies. Daher ziehe ich das Thema vor.

LSOs haben kein Verfallsdatum und können von einer Flash-Anwendung jederzeit geschrieben und gelesen werden. Damit sind sie besonders interessant für Profilbildung und Identifikation des Benutzers (aufgrund der Langlebigkeit und schwierigen Kontrolle). Benutzer, die sich um ihre Privatsphäre sorgen und deshalb regelmäßig Cookies im Browser löschen, können aufgrund der LSOs dennoch identifiziert werden. Eine Wiederherstellung der Browser-Cookies (mit den ursprünglichen Profilnummern) auf Basis der LSOs (und auch auf Basis des im Bereich “JavaScript” von mir angesprochenen WebStorages) ist ebenso möglich und wird/wurde praktiziert. Derlei resistente User-Tracking-Verfahren zeigen, wie viele Möglichkeiten existieren, um einen Benutzer eindeutig zu identifizieren. Es existieren Verfahren und Möglichkeiten, um LSOs regelmäßig (zum Beispiel beim Beenden vom Browser) zu entfernen oder das Anlegen von LSOs gänzlich zu verhindern - mehr dazu in Teil 2.

Ein Praxisbeispiel. Zuletzt hat Facebook mit seinen Cookies für Aufsehen gesorgt: Nachdem auf sehr vielen Webseiten die “Like”-Buttons integriert sind, ermöglichen auch diese - genauso wie bei großen Werbenetzwerken - eine umfangreiche Profilbildung. Ein Facebook-Benutzer, der bislang angenommen hat, dass er nicht weiter verfolgt werden kann (bzw. seine Webseitenbesuche nicht mit seinem Facebook-Zugang verknüpft werden können), wenn er sich bei Facebook abmeldet (“Logout”), irrte: Facebook hat beim Logout die Cookies (insbesondere die Benutzer-ID) nicht gelöscht sondern nur im Cookie ein “Logout” mit neuem Ablaufdatum vermerkt. Die entsprechenden Cookies (insbesondere die Benutzer-ID) wurden bei Besuch von Seiten, auf denen der “Like”-Button eingebunden war, weiterhin an Facebook übermittelt. Facebook hat dieses Verfahren mittlerweile nach öffentlicher Kritik eingestellt und auf einen Fehler im System zurückgeführt.

JavaScript

JavaScript ist eine browserseitig interpretierte Skriptsprache für Webseiten. Sie erlaubt es, interaktive (und damit komforterhöhende) Webseiten zu gestalten und zum Beispiel auf Aktionen der Besucher zu reagieren. Nahezu jede moderne Webseite nutzt JavaScript sehr ausführlich, hierzu gehören nicht zuletzt prominente Beispiele wie Google oder Facebook.

Mit der Sprache ist es beispielsweise möglich, den aktuellen Seiteninhalt lokal zu modifizieren (im Fachjargon: DOM-Manipulation; zum Beispiel lässt sich beim Klicken auf einen Link die Textfarbe eines anderen Textes auf derselben Seite verändern). Insbesondere im Zuge der Entwicklung des Web 2.0, bei dem sich Webseiten bezüglich Aufmachung und Verhalten dem von Desktop-Applikationen annäherten, wurde JavaScript in Verbindung mit Ajax besonders populär. Ajax (Asynchronous JavaScript and XML) erweitert JavaScript um die Funktionalität, (a)synchron strukturierte Daten zwischen der Webseite und dem Server, auf dem die Webseite hinterlegt ist, in beide Richtungen auszutauschen, ohne die Webseite neu laden zu müssen. Selbst-aktualisierende Live-Ticker (Börsenticker, Live-Ergebnisse von Sportveranstaltungen, automatische Aktualisierung der Timeline einer Community, etc.) sind typische Anwendungszwecke dafür. Der Komfortgewinn liegt auf der Hand. Oftmals sind entsprechende Server-Anwendungen notwendig, die Ajax unterstützen. Man spricht vom gesamten Verbund Webseite (als Client) und der Server-Anwendung daher auch oftmals von einer Web-Anwendung (vielleicht ein interessantes Detail, das weitere Risiken eröffnet: wird so eine Web-Anwendung als “Komplettangebot” und Dienstleistung gewerblich angeboten mit dem Service, dass der Kunde keinen eigenen Server einrichten und vorhalten muss, spricht man von Software as a Service (SaaS). Zur Datenschutzproblematik von SaaS finden sich bei Wikipedia ein paar Informationen).

Im Zuge der Entwicklung des HTML 5-Standards erfuhr/erfährt auch JavaScript besondere Neuerungen:

  • Der Weg für hardwarebeschleunigte 3D-Animationen (zum Beispiel für Spiele) im Browser wurde geebnet. JavaScript-Skripte haben nun in Verbindung mit WebGL die Möglichkeit, direkt auf die Hardware zuzugreifen und diese zu nutzen - ohne eine zusätzliche Erweiterung im Browser.

  • Mit Aufkommen der Web-Anwendungen wurde auch der Bedarf der Möglichkeit einer lokaler Sicherung von Informationen durch die Anwendung größer. Diesem Umstand wurde durch den WebStorage Rechnung getragen; Web-Anwendungen erhalten nun mittels JavaScript die Möglichkeit, abhängig vom Browser zwischen derzeit 5 und 10 MB Daten je Domain im Browser abzulegen.

JavaScript wird auch für folgende Anwendungszwecke genutzt:

  • Steuern der Browserfensteraktivität (Öffnen, Schließen und Steuern von Browserfenstern [um ein unangenehmes Beispiel zu nennen: Werbe-Popups])
  • Einblenden von Dialogen
  • Validieren von Eingabeformularen (Beispiel: Eingabe prüfen auf korrektes Format einer E-Mail-Adresse)
  • u. v. m.

Wenn man über die Sicherheit von JavaScript spricht, ist insbesondere der folgende Punkt hervorzuheben:

Das Skript (also dasjenige Programm, das der Webseitenprogrammierer in JavaScript entwickelt hat; eine ähnliche Funktionsweise von Skripten findet sich in der Windows-/Office-Welt unter dem Namen Makro) wird ausschließlich im Webbrowser (also z. B. Firefox) ausgeführt. Alle Änderungen, die ein Skript an der Webseite vornimmt, gelten nur im Kontext der aufgerufenen Webseite und nur lokal für den Moment des Seitenbesuches (außer das Skript speichert die Informationen irgendwo ab, siehe dazu oben und später mehr; für den Punkt der lokalen Ausführung zunächst nicht weiter relevant). Andere Webseitenbesucher würden die Veränderungen nicht zu Gesicht bekommen; außer sie erhielten (physischen) Zugriff auf den Browser oder das Skript würde mittels Ajax (siehe oben) die Änderungen an den Server zurücksenden (was je nach Anwendungszweck sogar gemacht wird; typische Beispiele hierfür sind kollaborative Anwendungen wie ein gemeinsames Whiteboard). Insgesamt bleibt festzuhalten: Das Skript wird lokal im Browser ausgeführt.

JavaScript ist eine mächtige Sprache für interaktive Webanwendungen und birgt - oftmals in Kombination mit anderen Techniken - gewisse Gefahren für die Privatsphäre und die Computersicherheit.

Ein potentielles Sicherheitsrisiko entsteht - unabhängig vom Einsatz weiterer Techniken - dadurch, dass JavaScript lokal auf dem eigenen Rechner im eigenen Browser ausgeführt wird (siehe oben). Um einen gewissen Grad an Sicherheit gewährleisten zu können, haben die Browserhersteller diverse Sicherheitsmaßnahmen ergriffen, um die Risiken zu minimieren:

  • Alle Skripte laufen in einer so genannten Sandbox; einer abgesicherten Umgebung, die von der eigentlichen Systemumgebung abstrahieren soll. So sollen unter anderem unkontrollierte Zugriffe auf das Dateisystem oder auf den Arbeitsspeicher unterbunden werden.

  • JavaScript-Programme aus Webseiten haben jeweils nur Zugriff auf ihren jeweiligen Kontext, also auf die Seite, in der sie aufgerufen werden. Übergriffe auf andere (zum Beispiel geöffnete) Webseiten sind untersagt.

  • maximale Ausführungszeiten schützen die Reaktionsfähigkeit des Browsers vor Skripten, die bewusst (oder auch unbewusst) eine Endlosschleife provozieren oder eine zu rechenintensive Arbeit mit zu langer Laufzeit verursachen.

  • Wer nicht erst seit Kurzem im Netz surft, kennt vermutlich auch noch die lästigen Werbepopups - sich automatisch öffnende Fenster, die sich entweder vor oder hinter das aktuelle Browserfenster geschoben haben und aufdringliche Werbung enthielten. Die Browserhersteller haben diesem Vorgehen einige Steine in den Weg gelegt: So ist es in der Regel nur noch möglich neue Fenster per JavaScript zu öffnen, wenn der Benutzer dies auch wirklich beabsichtigt. Dies geschieht entweder per Whitelisting, also einer expliziten Liste von Webseiten, die automatisch Fenster öffnen dürfen, oder über die Erkennung, welches Ereignis vom Benutzer explizit eigenständig ausgelöst und damit potentiell gewollt wird. Das automatische Öffnen von Webseiten ist zunächst ein Problem der Privatsphäre und informationellen Selbstbestimmung (und korreliert damit mit dem Problem aus meinem oben erwähnten Blogpost “Die Falle des prefetching”). Es kann jedoch zu einem ausgewachsenen Problem für die eigene Computersicherheit heranreifen, wenn es in Kombination mit bösartigen Webseiten genutzt wird und die automatisch aufgerufene Webseite Sicherheitslücken im eigenen Browser oder in einem seiner Plugins ausnutzt (dazu später mehr).

  • Das “Problem” ist nicht sonderlich sicherheitsrelevant, zeigt jedoch, wie JavaScript auch missbraucht werden kann: Bis vor einigen Jahren konnte man sich mit dem Arbeitskollegen einen - arbeitsintensiven - Spaß erlauben, wenn man ihn auf eine Webseite schickte, die in einer Endlosschleife modale Dialoge geöffnet hat. Modale Fenster (und damit auch Dialoge) haben die Eigenschaft, dass nur sie zunächst den Fokus erhalten und das Programm solange nicht weiterarbeitet, bis das Fenster geschlossen wurde. Einmal auf die Webseite geleitet, konnte man sich dem Dilemma in der Regel nur noch entziehen, wenn man den gesamten Browserprozess getötet hat. Browserhersteller haben darauf reagiert und bieten nun, in der Regel ab dem zweiten oder dritten Dialogfenster, das durch eine Webseite innerhalb eines Zeitraumes geöffnet wurde, die Möglichkeit an, weitere Dialogfenster des Skripts temporär zu unterdrücken.

    Dialog

Ein mögliches Sicherheitsproblem, das erst vor kurzem mit Einführung von HTML 5 bekannt wurde, könnte in der oben erwähnten WebGL-Implementation und der damit verbundenen hardwareunterstützten Ausführung von Code zu finden sein. Skripte können mit WebGL speziellen Shader-Code direkt in dem Grafikkartenprozessor, der GPU, ausführen, um umfangreiche 3D-Animationen zu erzeugen (rendern). Dies birgt Missbrauchspotential (zum Beispiel durch zu komplexe 3D-Animationen) in sich; eine Diskussion zum Thema findet derzeit statt.

Eindämmen kann man die Gefährdungen dadurch, indem man die Angriffspunkte reduziert und man daher gezielt nur für einzelne vertrauenswürdige Webseiten (wie oben schon bereits erwähnt, gemäß der Regel “Was nicht explizit erlaubt ist, ist verboten”) JavaScript zulässt. Add-Ons, die das bewerkstelligen, stelle ich im Teil 2 vor.

In Verbindung mit anderen Techniken oder Komponenten entstehen Risiken, die ich auch kurz aufzeigen möchte. Als wichtigen Vertreter für diese Problemklasse werde ich XSS (Cross Site Scripting) erläutern.

XSS-Angriffe zeichnen sich dadurch aus, dass schädlicher JavaScript-Code in einer anderen Umgebung (zum Beispiel in einer anderen Webseite) ausgeführt wird. Ziel kann es sein, Session-Cookies zu stehlen und diese an den Angreifer zu übermitteln (sogenanntes Session-Hijacking).

Ein aufmerksamer Leser ;-) würde sich jetzt fragen: Wie kann ein JavaScript-Code in der Umgebung einer anderen Webseite (zum Beispiel einer Bankseite) ausgeführt werden, obwohl die Browser entsprechende Gegenmaßnahmen (Abschottung der einzelnen Ausführungskontexte, siehe oben) getroffen haben?

Die Antwort darauf: Der Schadcode (also das schädliche JavaScript-Programm) wird direkt in die Webseite von Außerhalb eingeschleust. Hierzu wird zum Beispiel eine bestehende Schwachstelle in einer Webanwendung ausgenutzt, die folgendermaßen aussehen könnte: Ein Forum bietet eine Suchfunktion an; auf der Ergebnisseite, die angenommen über die Adresse http://www.mycommunity.tld/results?query=Fische erreichbar ist, wird der gesuchte Begriff eingebettet (“Sie suchten nach ‘Fische’.”). Wird der Suchbegriff nur unzureichend auf Seiten der Web-Anwendung (serverseitig) geprüft, kann ein Angreifer ein JavaScript-Programm in die Seite einbetten (für technisch Interessierte ein einfaches Skript, aber für die weiteren Ausführungen nicht relevant: <script>alert('Hallo von außerhalb!');</script>). Diese Einbettung führt dazu, dass das Skript im Kontext der Community-Seite (auf der Ergebnisseite) ausgeführt wird. Das Skript könnte die Cookies, die die Community-Seite gesetzt hat (zum Beispiel Session-Cookies, die dafür sorgen, dass man auf der Seite angemeldet ist und bleibt), auslesen und an den Angreifer übermitteln. Der Angreifer kann seinerseits mittels den Cookies, über die sich der legitime Benutzer bislang gegenüber der Webanwendung identifiziert hat, nutzen, um sich als dieser Benutzer auszugeben und in seinem Namen Funktionen der Community auszuführen (zum Beispiel Beiträge veröffentlichen, Freunde löschen, etc.).

Den Angriff kann man gezielt gegen einen Benutzer durchführen, wenn man ihn dazu bringt, auf eine manipulierte Adresse zu klicken. So eine Adresse könnte in Anlehnung an die obige URL der Ergebnisseite folgende Form aufweisen: http://www.mycommunity.tld/results?query=<script>....</script>. Verschleiern lässt sich dies wunderbar mit einem der üblichen URL-Shortener. Einen guten Schutz gegen diese Angriffsform erreicht man mit einer gesunden Vorsicht vor unbekannten URLs (insbesondere vor Short-URLs; kein “blindes Anklicken”) und einem technischen Hilfsmittel (zum Beispiel einem Add-On für den Browser), das sich vor den Aufrufbefehl von Webseiten einklinkt und Adressen auf sogenannte Metazeichen (Zeichen, die zum Beispiel für ein JavaScript-Skript charakteristisch sind, wie < und >) prüft. Wird ein solches Zeichen oder Muster gefunden, kann ein Aufruf unterbunden oder zumindest angeprangert werden. Ein geeignetes Add-On für diesen Zweck stelle ich im zweiten Teil meiner Blogpostreihe vor.

Zum Thema Banken und Cross-Site-Scripting berichtete heise security (mit Screenshots) über die klaffenden Sicherheitslücken.

Die eben vorgestellte Variante wird als nicht-persistente (also flüchtige) Form des Cross-Site-Scriptings verstanden, da das Schadprogramm bei einem normalen Aufruf der Webseite (Ergebnisseite aus dem Beispiel) nicht vorhanden wäre. Ein prominentes Beispiel für einen solchen Angriff konnte man zuletzt erst vor wenigen Monaten der Fachpresse entnehmen. Dabei wurden Cookies von eBay-Usern gestohlen und an einen Angreifer übermittelt.

Problematisch sind jedoch auch persistente Cross-Site-Scripting-Angriffe, bei denen Schadcode dauerhaft auf einer Webseite hinterlegt wird und mit jedem normalen Aufruf der Seite ausgeliefert wird. Dies könnte zum Beispiel durch eine unzureichende Überprüfung der Eingabewerte in einem Internet-Gästebuch erfolgen (die Seite der Gästebucheinträge enthält dann den Schadcode dauerhaft). Derlei Lücken werden gerne ausgenutzt, um 0day-Attacken (siehe oben; auch andere aktuelle Sicherheitslücken in Browsern) durchzuführen und möglichst viele Besucher mit schadhafter Software (Viren, Trojaner, Würmer, etc.) zu infizieren. Ebenso ist jedoch auch das systematische Stehlen von vielen Benutzerzugängen der manipulierten Seite möglich.

Gegen derlei Angriffe hilft eine Prüfung der Adresse auf Metazeichen oder andere Muster nicht mehr, da die Adresse keinen Schadcode enthält sondern “sauber” ist. Da das schadhafte persistente JavaScript-Skript oftmals noch von einem fremden Server weiteren Schadcode nachlädt (oder eine Verbindung zu dem Server des Angreifers benötigt, wenn das Skript die Cookies stehlen und übertragen möchte), hilft hier eine Kontrolle der Anfragen, die eine Seite stellt (zum Beispiel beim Nachladen von weiteren Elementen der Seite, wie Bilder, Skripte, Videos, etc.). Als zumindest beobachtungswürdig können zunächst alle Zugriffe einer Webseite betrachtet werden, die nicht auf die eigene Domain (zum Beispiel mycommunity.tld) gerichtet sind. Gemäß der oben getroffenen Verhaltensregel (“Es ist alles verboten, was nicht explizit erlaubt ist”) werden zunächst alle Anfragen an Webseiten außerhalb der Webseitendomain blockiert und nur individuell freigeschaltet. Dies verhindert sowohl das Nachladen von weiterem Schadcode als auch das Übertragen von Cookies zum Server des Angreifers. Auch diese Funktion kann durch ein Add-On übernommen werden. Mehr Informationen hierzu im Teil 2.

Inlineframes (iframes)

iframes stellen eine Technik dar, um beliebige andere Webseiten in eine eigene Webseite zu integrieren und darzustellen (gerne auch, oft mit böswilligen Hintergedanken, in einem für den Besucher unsichtbaren iframe). Die Technik wird zusehends seltener legitim eingesetzt, da mit Ajax (siehe oben) eine wesentlich elegantere Methode existiert, Inhalte in eine Webseite dynamisch einzubetten. Probleme ergeben sich zum Beispiel durch Seitenaufrufe, die man selber nicht erwünscht hat und deshalb unangenehme Konsequenzen nach sich ziehen oder die Systemsicherheit wegen existierenden Sicherheitslücken gefährden. Das Problem korreliert mit denen des prefetching oder denen der persistenten Cross-Site-Scripting-Attacken. Entgegnen kann man ihnen mit denselben Mitteln: Aktives Verwalten der ausgehenden Anfragen einer Webseite, wenn diese außerhalb der Webseitendomain erfolgen sollen. Wie und mit welchen Add-Ons dies bewerkstelligt werden kann, erkläre ich in Teil 2.

Verschlüsselte Verbindungen (https)

Daten, die zwischen einem Browser und einem Server mittels HTTP (siehe oben) ausgetauscht werden, werden zunächst unverschlüsselt über verschiedene Knotenpunkte im Internet übertragen (selbiges trifft natürlich auch auf andere Daten außerhalb des Browsers zu). Das Internet besteht aus einem großen Verbund von Netzwerken, einem vermaschten Netzwerk. Üblicherweise finden sich viele Knotenpunkte zwischen beiden Enden. Ein Beispiel für eine Route von meinem Rechner zu Google:

 1  fritz.box (192.168.178.1)
 2  217.0.119.70 (217.0.119.70) 
 3  217.0.76.242 (217.0.76.242)
 4  b-ea6-i.B.DE.NET.DTAG.DE (62.154.47.66)
 5  194.25.211.30 (194.25.211.30)
 6  209.85.249.182 (209.85.249.182)
 7  216.239.48.4 (216.239.48.4)
 8  216.239.48.10 (216.239.48.10)
 9  209.85.254.114 (209.85.254.114)
10  fx-in-f147.1e100.net (74.125.39.147)

Jeder Eintrag stellt einen Knotenpunkt dar, den meine Daten passieren müssen. An jeder Stelle könnten meine Daten, wären sie nicht verschlüsselt, abgegriffen und gelesen werden. Da das Spionieren in der Regel ein passiver Angriff ist, bekommt der Angegriffene hiervon oft nichts mit. Besonders deutlich wird das Problem, wenn man sich als ersten Knotenpunkt ein offenes WLAN in einem Restaurant vorstellt. Jeder in Reichweite des WLANs hat die Möglichkeit, unverschlüsselte Daten mitzuschneiden und für seine Zwecke zu missbrauchen. Denkbar wäre hier zum Beispiel ein Angriff auf Session-Cookies (siehe oben).

Aus der Praxis: Vor ein paar Monaten wurde ein Add-On für Firefox veröffentlicht, das automatisch den umliegenden Datentransfer anderer mitgeschnitten und auf Session-Cookies untersucht hat. So war es möglich, sich “per Mausklick” in die Sitzung (zum Beispiel von Facebook) eines Dritten einzuklinken. Viele große Seiten haben innerhalb kürzester Zeit ihre Systeme um eine Ende-zu-Ende-Verschlüsselung aufgerüstet. Facebook und auch zum Beispiel Google Mail lassen sich mittlerweile über eine verschlüsselte Verbindung besuchen.

Eine verschlüsselte Ende-zu-Ende-Verbindung wird mit SSL (Secure Socket Layer), oder neuer: Transport Layer Security (TLS), erreicht. SSL/TLS stellen eine Möglichkeit dar, beliebige Protokolle um eine Verschlüsselung zu ergänzen. HTTP ergänzt um SSL wird HTTPS genannt (zu finden auch in Adressen von verschlüsselten Verbindungen: https://www.myshop.tld/).

Die Vertrauenswürdigkeit und Authentizität zwischen Kommunikationspartnern unter Verwendung von SSL wird mittels sogenannter Zertifikate hergestellt. Zertifikate stellen die digitalen Personalausweise der Server (für Clients, also Browser, wären Zertifikate auch möglich, finden in der Praxis jedoch seltener eine Anwendung) dar und sollen helfen zu verifizieren, dass eine Kommunikation mit dem richtigen Partner stattfindet. Gäbe es solche Verifzierungsmöglichkeiten nicht wäre es problemlos möglich (da man die Identität seines Gegenüber nicht zweifelsfrei klären kann), durch einen “zwischengeschalteten Dritten” die Kommunikation abzuhören, indem dieser dem Browser vorschwindelt, er sei der Server und dem Server vorschwindelt, er sei der Browser. Jeglicher Datenverkehr ist dann zwar zwischen Browser und Drittem sowie Drittem und Server verschlüsselt, verläuft jedoch im Klartext über den Dritten, der die Daten für seine Zwecke missbrauchen kann. Das Verfahren wird als “man-in-the-middle-attack” bezeichnet. Es ist daher beim Einsatz von verschlüsselten Verbindungen wichtig, die Zertifikate auf ihre Gültigkeit/Echtheit zu kontrollieren.

Um diese Kontrolle zu unterstützen, wurden zertifizierende Stellen (CA, Certificate Authority) geschaffen. Diese Zertifizierungsstellen (zum Beispiel VeriSign) stellen ein Zertifikat für eine Domain nur dann aus, wenn sich diese über die Identität des Webseitenbetreibers im Klaren sind. Der Aufwand so einer Prüfung kann von sehr gering (nur die E-Mail-Adresse auf dieser Domain prüfen) bis zu sehr hoch (persönliches Erscheinen mit Ausweispapieren bei der CA) reichen.

Alle Browser enthalten eine Liste aller - so möchte man meinen - vertrauenswürdigen Zertifizierungsstellen. Dass nicht alle gleichermaßen vertrauenswürdig sind und viel Kritik zu dem System der CAs geübt wird, zeigt nicht zuletzt der aktuelle Fall um DigiNotar, bei dem sich ein Hacker hunderte Zertifikate für Domains großer Unternehmen ausstellen konnte (Google, Facebook, etc.). Solch ein Einbruch in eine CA und das Ausstellen von vertrauenswürdigen Zertifikaten ermöglicht den oben beschriebenen Fall eines man-in-the-middle-Angriffs.

Der Browser prüft beim Aufbau einer SSL-Verbindung, ob das Zertifikat von einer vertrauenswürdigen CA ausgestellt wurde und der Domainname zum Zertifikat passt (geprüft werden außerdem noch ein paar weitere Informationen wie Gültigkeitsdatum oder Einträge in einer sogenannten Sperrliste, der Certificate Revocation List (CLR). Dies ist jedoch für das Verständnis von Zertifikaten erst einmal nebensächlich.). Ist dem so, baut der Browser die verschlüsselte Verbindung auf. Konnte das Zertifikat nicht verifiziert werden, zum Beispiel weil der Domainname des Zertifikats nicht mit dem aufgerufenen Domainnamen übereinstimmt oder ein Browserhersteller (oder der Browsernutzer) einer CA das Vertrauen entzogen hat (alle großen Browserhersteller haben im Fall DigiNotar relativ rasch reagiert und der CA das Vertrauen entzogen), wird die Verbindung nicht aufgebaut. Stattdessen wird eine Warnmeldung angezeigt.

Insgesamt kann man festhalten, dass man unbedingt - wann immer möglich - auf eine verschlüsselte Kommunikation setzen sollte. SSL gibt es nicht nur im Browser, sondern auch im Mailprogramm (hier ist das Ziel umso mehr, seine persönliche Kommunikation und Zugangsdaten geheim zu halten). Add-Ons unterstützen den Benutzer aktiv dabei, HTTPS für Webseiten, die es anbieten, automatisch zu aktivieren. Ein Firefox Add-On werde ich in Teil 2 vorstellen.

Plugins

Was Plugins sind, wieso man grundsätzlich die meisten Plugins deaktiviert haben und nur bei Bedarf notwendige Plugins aktivieren sollte, habe ich bereits oben erläutert (in “Warum Techniken einschränken?”). Im Teil 2 werde ich konkret zeigen, wie man in Firefox Plugins grundsätzlich deaktivieren und nur bei Bedarf aktivieren kann.

In diesem Abschnitt soll es darum gehen zwei bekannte Plugins als Beispiel für eine mögliche Gefährdung vorzustellen. Die mitunter am verbreitetsten Plugins dürften der Adobe Flash Player und Java sein.

Vor allem Flash (das zum Beispiel für das Abspielen von YouTube-Videos genutzt wird) zeichnet sich durch seine Komplexität und der damit verbundenen Anfälligkeit für Sicherheitslücken aus. Fast in regelmäßigen Abständen werden Updates auf weltweit allen Computern notwendig, um Sicherheitslücken zu schließen. Flash ist wegen seiner großen Verbreitung ein beliebtes Angriffsziel von Hackern und sollte daher restriktiv im Browser eingesetzt werden. Dank dem aufkommenden HTML5-Standard und der Implementierung in den Browsern wird es zusehendes möglich, das Abspielen von Videos direkt nativ im Browser - ganz ohne Plugin wie Flash oder ein ähnliches - zu ermöglichen. Auch Animationen können in HTML 5 entwickelt werden, sodass Flash - hoffentlich - in absehbarer Zeit an Marktanteilen verlieren wird. Bereits jetzt unterstützen große Portale wie YouTube das Anzeigen von Videos mittels HTML 5, ganz ohne Flash.

Das Java-Plugin wird benötigt, um sogenannte Java-Applets (kleine in der Programmiersprache Java geschriebene Miniprogramme) im Browser anzeigen zu lassen. Java wird meiner Meinung nach kaum noch im Netz (außer an ganz fachspezifischen bestimmten Stellen, zum Beispiel auf wissenschaftlichen Seiten) genutzt, weshalb man durchaus die Meinung vertreten kann, dass das Java-Plugin im Browser vollständig deaktiviert werden sollte. Auch Java ist bekannt dafür, regelmäßig weitere Sicherheitslücken in den Browser zu reißen. Wie Java vollständig deaktiviert werden kann, zeige in Teil 2 meiner Blogpostreihe.

Geschafft…

… bis hier hin! Vielen Dank für deine Aufmerksamkeit! Ich hoffe, dass ich dir einen ersten Einblick in die Gefahren und Probleme, aber auch in die Problemlösungsansätze, geben konnte, die im Netz auf jeden Surfer warten. Mit den geeigneten Hilfsmitteln und mit Brain 2.0 (also dem Surfen im Netz mit Verstand!) kann man jedoch die Vorzüge des Netz’ problem- und sorgenloser genießen. :-)

Ich freue mich natürlich über jeglichen Kommentar, Verbesserungsvorschläge oder Fragen zum Thema.

Explizite Umsetzungen der Problemlösungsansätze (insbesondere in Add-Ons für Firefox) werde ich in Kürze im zweiten Teil meiner Blogpostreihe vorstellen. Bis bald!


New comment

Comments are moderated and therefore are not published instantly.





Comments

No comments yet. Be the first! :-)