Ich verwende auf diversen Seiten Flowplayer, um ganz einfach Videos (encoded in H.264) mit pseudo-streaming (genauer: Progressive download) einzubinden und abzuspielen.
Unter Mac habe ich beim Export stets ein weboptimiertes Profil mit Streaming-Funktionalität (Schnellstart) ausgewählt, um mein Ziel zu erreichen. Seit meinem Wechsel zu Linux fehlte mir (beim Export in OpenShot) diese Option (zunächst) mit der Folge, dass der Flowplayer das ganze File (also zum Beispiel volle 200 MB Video) heruntergeladen hat, bevor er mit dem Abspielen begann.
Um dem Flowplayer alle nötigen Informationen zum Video (zum Beispiel zur Struktur) zukommen zu lassen, die er zum vorzeitigen Abspielen benötigt, kann das Tool qt-faststart genutzt werden. Dabei kopiert qt-faststart das so genannte moov atom an den Anfang der Datei (das die genannten Informationen enthält) und hängt den vollständigen Videostream an die neu erstellte Datei an. Der Vorgang dauert nur wenige Sekunden.
Die Nachbehandlung meines exportierten Files mit qt-faststart bringt den gewünschten pseudo-streaming-Effekt zurück. :-)
Samstag, 26. November 2011
Dienstag, 25. Oktober 2011
Ubuntu: Firefox als unterschiedliche User starten
Kurzer Tipp für Ubuntu/Linux-User: Wenn Bedarf besteht, einen zweiten
Firefox-Prozess (oder natürlich jede andere Software auch) unter einem anderen User zu starten (zum Beispiel, um
unbekannte Software/Plugins unter einem speziell angelegten
"untrusted"-User zu testen und nicht gleich Zugriff auf ~ zu erlauben),
kann folgendermaßen vorgegangen werden:
user:~$ xhost + (um untrusted zu erlauben, Fenster in der aktuellen X-Sitzung zu öffnen)Et voilà!
user:~$ sudo su - untrusted (sicherer Wechsel zum untrusted-User)
untrusted:~$ firefox -no-remote (-no-remote ist wichtig, da es sonst passieren kann, dass Firefox für den aktuell laufenden Prozess schlicht ein neues Browserfenster unter dem eigenen User öffnet statt einen neuen Prozess unter untrusted zu starten)
Freitag, 30. September 2011
Sicherheit im Internet - Teil 1
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:
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:
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:
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:
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:
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!
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:
- Benutzer surft http://www.mycommunity.tld/login an. Per HTTP werden alle benötigten Inhalte vom Server an den Benutzer übertragen.
- 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.
- 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.
- 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.
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.
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.
- 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.
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.
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)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).
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)
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!
Freitag, 23. September 2011
Die Falle des prefetching
Es scheint zur Unsitte geworden zu sein, die Kontrolle darüber, welche Seiten der heimische Browser aufrufen soll, weg von der Macht des Nutzers hin zum einfältigen Algorithmus' des Browsers verlagern zu wollen. Das ist den großen Browserherstellern (zumindest was Firefox und Chrome angeht, aber ich befürchte, dass der Internet Explorer in seiner aktuellen Version dem Trend des Millisekundeneinsparens hinterher gedackelt ist) auch gut gelungen.
Ich beziehe mich hier zunächst auf die Situation bei Firefox, die von Chrome ist vergleichbar. Unterschiede zwischen Firefox und Chrome stelle ich im Verlauf heraus.
Firefox hat standardmäßig das sogenannte "prefetching" aktiviert - sowohl für Webseiten (HTTP-Requests) als auch für DNS-Requests (d.h. das Auflösen von Domainnamen zu ihren zugehörigen IP-Adressen).
Beliebige Webseiten können kontrollieren, welche Webseiten oder DNS-Namen der Browser vorladen bzw. auflösen soll, in der Regel deshalb, weil der Betreiber der Meinung ist, dass der Besucher sehr wahrscheinlich auf einen dieser Links klicken wird.
Der Vorteil: Der Browser konnte, während der Besucher sich noch auf der ersten Seite aufhält, im Hintergrund den DNS-Namen sowie ggf. den Seiteninhalt der vermeintlich "nächsten" Seite herunterladen und für den Besuch vorbereiten. Dadurch wird die Ladezeit und der Seitenaufbau durchaus im messbaren (aber nicht unbedingt fühlbaren) Bereich verkürzt - mit fatalen Folgen für den Datenschutz und die Sicherheit beim Browsen durch's Netz.
Das Problem: Entweder man möchte die Seite gar nicht besuchen, weil man schlicht kein Interesse an ihr hat. Dann hat man im einfachsten Fall etwas Bandbreite verschwendet (zu Ungunsten des Webseitenbetreibers). In Zeiten von DSL und Flatrates kein besonders großes Problem (wenn man mal von mobilen Endgeräten absieht, bei denen das sehr wohl noch problematisch ist). Viel schwerwiegender ist jedoch, dass der Webseitenbetreiber bestimmen darf, welche Seite der Browser herunterladen soll - egal ob man es möchte, oder nicht. Und der Browser für einen entscheidet, welche DNS-Namen aufgelöst werden sollen, und welche nicht. Im schlimmsten Fall lässt sich das prefetching für illegale Zwecke mißbrauchen. Zum Beispiel, um den Browser anzuweisen Webseiten herunterzuladen, die man normalerweise nie besuchen würde - weil sie suspekt sind und/oder der Besuch unter Umständen unangenehme Konsequenzen nach sich ziehen würde.
Firefox vs. Chrome: Während Firefox "nur" den Seitenquelltext vorlädt (und auch nur dann, wenn der Webseitenbetreiber eine zu ladende Adresse vorgibt!), geht Chrome einen Schritt weiter: Chrome lädt ganze Webseiten samt Medieninhalten herunter ("Instant Pages") - und zwar eigenständig, so wie es Chrome passt; und wie es sich für einen Browser gehört, werden diese Webseiteninhalte (Bilder, etc.) üblicherweise im Cache zwischengespeichert. Das bedeutet im Klartext: Werden unerwünschte Seiten automatisch besucht, landen unter Umständen Bilder und andere Inhalte gegen den Willen des Benutzers auf der Festplatte. Google selber beschreibt die Funktion medienwirksam folgendermaßen in ihrem Blog:
Die Lösung: Prefetching lässt sich glücklicherweise noch in beiden Browsern abschalten - wenngleich es, insbesondere bei Firefox, für Otto-Normal nicht mehr auf normalem Wege zu bewerkstelligen ist.
In Firefox kann über die Eingabe von "about:config" in die Adresszeile ein Konfigurationseditor aufgerufen werden, über den viele weitere Einstellungen zu Firefox vorgenommen werden können. Über den Filter kann nach "prefetch" gesucht werden; die für die oben genannten Techniken relevanten und zu ändernden Einträge lauten
In Chrome findet sich die erste zu ändernde Einstellung in den Einstellungen unter dem Reiter "Details". Hier sollte das Häkchen bei "Netzwerkaktionen vorhersagen, um die Seitenladeleistung zu verbessern" (das ist DNS-Prefetching) entfernt werden. Die zweite Änderung sollte man in den Grundeinstellungen im Bereich "Suche" vornehmen: Hier sollte das Häkchen bei "Google Instant für schnelleres Suchen und Browsen aktivieren" (Instant Pages) entfernt werden.
Die Konsequenz: Ja, der Seitenaufbau könnte sich um wenige Millisekunden (aus eigener Erfahrung im nicht wirklich relevanten Bereich) verzögern. Aber der Rückgewinn an Entscheidungsfreiheit beim Browsen im Netz rechtfertigt die Veränderungen allemal.
Weitere Informationen:
Ich beziehe mich hier zunächst auf die Situation bei Firefox, die von Chrome ist vergleichbar. Unterschiede zwischen Firefox und Chrome stelle ich im Verlauf heraus.
Firefox hat standardmäßig das sogenannte "prefetching" aktiviert - sowohl für Webseiten (HTTP-Requests) als auch für DNS-Requests (d.h. das Auflösen von Domainnamen zu ihren zugehörigen IP-Adressen).
Beliebige Webseiten können kontrollieren, welche Webseiten oder DNS-Namen der Browser vorladen bzw. auflösen soll, in der Regel deshalb, weil der Betreiber der Meinung ist, dass der Besucher sehr wahrscheinlich auf einen dieser Links klicken wird.
Der Vorteil: Der Browser konnte, während der Besucher sich noch auf der ersten Seite aufhält, im Hintergrund den DNS-Namen sowie ggf. den Seiteninhalt der vermeintlich "nächsten" Seite herunterladen und für den Besuch vorbereiten. Dadurch wird die Ladezeit und der Seitenaufbau durchaus im messbaren (aber nicht unbedingt fühlbaren) Bereich verkürzt - mit fatalen Folgen für den Datenschutz und die Sicherheit beim Browsen durch's Netz.
Das Problem: Entweder man möchte die Seite gar nicht besuchen, weil man schlicht kein Interesse an ihr hat. Dann hat man im einfachsten Fall etwas Bandbreite verschwendet (zu Ungunsten des Webseitenbetreibers). In Zeiten von DSL und Flatrates kein besonders großes Problem (wenn man mal von mobilen Endgeräten absieht, bei denen das sehr wohl noch problematisch ist). Viel schwerwiegender ist jedoch, dass der Webseitenbetreiber bestimmen darf, welche Seite der Browser herunterladen soll - egal ob man es möchte, oder nicht. Und der Browser für einen entscheidet, welche DNS-Namen aufgelöst werden sollen, und welche nicht. Im schlimmsten Fall lässt sich das prefetching für illegale Zwecke mißbrauchen. Zum Beispiel, um den Browser anzuweisen Webseiten herunterzuladen, die man normalerweise nie besuchen würde - weil sie suspekt sind und/oder der Besuch unter Umständen unangenehme Konsequenzen nach sich ziehen würde.
Firefox vs. Chrome: Während Firefox "nur" den Seitenquelltext vorlädt (und auch nur dann, wenn der Webseitenbetreiber eine zu ladende Adresse vorgibt!), geht Chrome einen Schritt weiter: Chrome lädt ganze Webseiten samt Medieninhalten herunter ("Instant Pages") - und zwar eigenständig, so wie es Chrome passt; und wie es sich für einen Browser gehört, werden diese Webseiteninhalte (Bilder, etc.) üblicherweise im Cache zwischengespeichert. Das bedeutet im Klartext: Werden unerwünschte Seiten automatisch besucht, landen unter Umständen Bilder und andere Inhalte gegen den Willen des Benutzers auf der Festplatte. Google selber beschreibt die Funktion medienwirksam folgendermaßen in ihrem Blog:
Instant Pages can get the top search result ready in the background while you’re choosing which link to click, saving you yet another two to five seconds on typical searches. [Quelle]Erscheint in den Suchergebnissen einmal eine Seite, die man unter keinen Umständen hätte angeklickt, kann es mit dem Prefetching schon zu spät sein.
Die Lösung: Prefetching lässt sich glücklicherweise noch in beiden Browsern abschalten - wenngleich es, insbesondere bei Firefox, für Otto-Normal nicht mehr auf normalem Wege zu bewerkstelligen ist.
In Firefox kann über die Eingabe von "about:config" in die Adresszeile ein Konfigurationseditor aufgerufen werden, über den viele weitere Einstellungen zu Firefox vorgenommen werden können. Über den Filter kann nach "prefetch" gesucht werden; die für die oben genannten Techniken relevanten und zu ändernden Einträge lauten
- network.dns.disablePrefetch (standardmäßig auf false, zum Deaktivieren von DNS-Prefetching auf true setzen)
- network.prefetch-next (standardmäßig auf true, zum Deaktivieren auf false setzen)
 |
| datenschutztechnisch optimale Einstellung in Firefox |
Die Konsequenz: Ja, der Seitenaufbau könnte sich um wenige Millisekunden (aus eigener Erfahrung im nicht wirklich relevanten Bereich) verzögern. Aber der Rückgewinn an Entscheidungsfreiheit beim Browsen im Netz rechtfertigt die Veränderungen allemal.
Weitere Informationen:
Montag, 19. September 2011
Meine Projekte
Ich habe rechts im Blog einen neuen Menüeintrag "Projekte" ergänzt. Auf der Seite werde ich künftig übersichtlich meine aktuellen Projekte kurz vorstellen (einige habe ich schon hinzugefügt), wenn vorhanden mit Link zu Code und Demo. Viel Spaß!
Windows 8 Developer Preview unter Linux mit KVM/QEMU
Kurze Durchsage, da das meiste zu Windows 8 sowieso schon geschrieben ist: Die Developer Preview bootet unter VirtualBox und, was ich besonders interessant finde, unter KVM/QEMU. In Verbindung mit libvirt und Virt-Manager ist das schon sehr schick. Läuft zwar erwartungsgemäß nicht absolut flüssig (insbesondere mangels Client-Side Extensions), aber immerhin läuft es und lässt sich ausprobieren. Virt-Manager ist übrigens eine Empfehlung von mir, wenn es um die Verwaltung von virtuellen Maschinen (mittels libvirt) geht; sehr schöne übersichtliche und komfortable GUI. Der Rest auf Screenshots.
Übrigens: Man darf die ISO von Windows 8 tatsächlich ohne Live-Klimmbimm, vorherigem Registrieren oder Java Download-Manager direkt per HTTP herunterladen - nicht schlecht!
Übrigens: Man darf die ISO von Windows 8 tatsächlich ohne Live-Klimmbimm, vorherigem Registrieren oder Java Download-Manager direkt per HTTP herunterladen - nicht schlecht!
 |
| GUI von Virt-Manager |
 |
| Die neue Oberfläche "Metro" |
 |
| Visual Studio 2011 Express startet |
 |
| Auch Netzwerk geht unter KVM/QEMU und Windows 8 |
 |
| Metro-Apps werden in JavaScript und HTML/CSS geschrieben. |
 |
| ... und tschüss! |
Lecker Pizza selbstgemacht
Das folgende Rezept habe ich vor einiger Zeit auf Facebook "Notizen" (mangels eigener Seite) veröffentlicht. Da ich doch des öfteren immer mal wieder danach gefragt habe, hier nun also auch in meinem neuen Blog:
Ich habe mittlerweile schon des öfteren Pizzen selber gebacken und mich (teils stundenlang) in einschlägigen Kochforen getummelt, um auch noch die letzte Geschmacksknospe mit Freude zu erfüllen oder der Pizza den letzten Feinschliff zu verpassen. Alle diese Tipps versuche ich in meiner Anleitung unterzubringen. Wenn ihr eine Frage habt, fragt! und ich ergänze die FAQ (s. u.). Auch für Anregungen bin ich dankbar. :)
Das Rezept ist für 5-6 normale Pizzen (Durchmesser 28 cm) ausgelegt; der Teig lässt sich wunderbar einfrieren, wenn ihr also zu viel über habt, weil ihr euch an den Mengen aus meinem Rezept orientiert habt, macht das gar nix. Lest dazu unten mehr.
Die gesamte Arbeitszeit beläuft sich für geübte Hobbyköche auf ca. 20 - 30 Minuten. Wartezeit leider etwas länger, wenn ihr keine tiefgefrorenen Teiglinge habt. Aber das kann sich ja schnell ändern. :)
Also, bevor wir starten, zunächst einmal die Materialliste:
... für den Teig:
Beginnen wir also damit, den Teig vorzubereiten (Arbeitszeit ca. 15 Minuten). Da er nach dem Kneten optimalerweise ca. zwei Stunden ruhen sollte, ist er als erster an der Reihe.
Holt eure große Schüssel und gebt das Mehl hinein; in das zweite Gefäß, in der sich das lauwarme Wasser (wichtig: lauwarm meint lauwarm, und nicht heiß oder heißer, denn sonst stirbt euch die Hefe weg und euer Teig geht nicht auf!) befindet, bröselt ihr den Block Hefe, gebt das Olivenöl und das Salz hinein. Es ist eine Glaubensfrage, ob noch eine Prise Zucker hinzugetan wird; ich lass ihn üblicherweise weg. Er soll (angeblich) den Teig noch besser aufgehen lassen (weil Hefe zum Arbeiten Kohlenhydrate benötigt, der im Zucker enthalten ist); für meinen Teil reichen die Kohlenhydrate aus dem Mehl, der Teig geht immer bombig auf. :)
Rührt das lauwarme Wasser samt den Zutaten fleißig um, bis sich alles aufgelöst hat. Gebt die Brühe zum Mehl und knetet das Mehl nun ca. 5 - 10 Minuten. Das Ziel ist es, dass sich der Teig schön elastisch anfühlt, keine Blasen o. ä. mehr zu sehen sind und vor allem nicht mehr an den Händen klebt.
Da sind wir nun auch schon beim Nachteil des Knetens von Hand: Der Teig klebt wie Sau - anfänglich. Keine Angst, das gibt sich mit zunehmendem Kneten. Erinnert ihr euch an die verbliebenden 75g Mehl aus einem Kilo (ihr habt ja nur 925g Mehl für den Teig genutzt)? Ihr dürft davon ca. 1/3 peu à peu benutzen, um den Teig etwas zu "entkleben". Das lohnt sich aber erst frühestens nach ca. 3-4 Minuten - vorher müsst ihr da durch. Je besser ihr knetet, desto besser wird der Teig und geht dementsprechend auf.
Deckt den Teig mit einem Küchentuch gut ab (damit der Teig keine unschöne Haut bildet) und stellt ihn in seiner Schale an einen warmen Ort (bitte nicht auf die Idee kommen den Ofen anzuschmeissen und ihm "Feuer" zu geben - das bringt nix, außer Kummer). Euer Teig sollte sich nach einer zweistündigen Ruhepause locker verdoppeln, wenn nicht gar verdreifachen. In der Zwischenzeit könnt ihr euch der Grundsoße widmen (und davon naschen... jedoch nicht zu viel!).
An diejenigen, die besonders großen Hunger haben: Ihr könnt von eurem aufgegangenen Teig bereits nach ca. einer
Stunde den ersten Teigling (Menge s. u.) abnehmen und für eine Pizza
benutzen - kein Problem! Es könnte sein, dass die Pizza nur 95% fluffig
ist ;) Die letzten 5% erreichen wir mit der zweiten Stunde.
Also, zur Grundsoße (Arbeitszeit ca. 5 Minuten):
Die Soße ist schnell gemacht; einfach alle Zutaten in eine Schale geben, bei den Gewürzen mengenmäßig einfach so würzen, wie euch es am besten schmeckt (Zutaten habt ihr ja in der Zutatenliste). Fertig? Gut. Dann zückt den Stabmixer und mixt alles gut durch (Achtung: Spritzgefahr!). Soße fertig, ggfs. nochmal abschmecken!
... zwei Stunden sind vergangen; der Teig ist explodiert (Arbeitszeit für Belegen ca. 5 Minuten):
Erstaunlich,
was Hefe anrichten kann, nicht wahr? Bereitet eure Arbeitsfläche vor
und holt die Zutaten für den Belag aus dem Kühlschrank. Schmeisst auch
schonmal den Ofen auf die höchste Stufe an (Oberhitze), die er zu bieten
hat (bei mir sind's 260°C). Das dauert ein wenig, bis der Ofen heiß
ist. Wir brauchen später nur die mittlere Schiene, am besten nehmt ihr
für's Backen ein Gitterblech (Gitterblech nur dann, wenn ihr ein eigenes Pizzablech habt! Ansonsten natürlich ein normales nehmen).
Für die Pizza an sich empfehle ich ein Pizzablech. Die Teile lohnen sich wirklich (bitte jedoch keine beschichteten, sondern z. B. welche aus Blaublech - wie bei den Profis! ;)..). Auf dem Foto seht ihr meines von GRÄWE 28 cm Durchmesser - Kostenpunkt: 6,90 € bei Amazon. Das sieht nicht nur cool und professionell aus, sondern macht auch noch Spaß und ist handlich beim "Ausrollen" und Belegen des Teiges.
Ölt
zunächst das Blech ein (dann klebt der Teig später beim Entnehmen nicht
am Blech - wäre ja ärgerlich, wenn man die Pizza vom Blech essen
müsste). Dann entnehmt ihr für so ein Pizzablech von eurem Teig
ungefähr einen eine Faust großen Teigling und beginnt, ihn von
der Mitte des Bleches aus mit kreisenden Bewegungen in die Breite zu
zerren/drücken (ich drücke immer mit der ganzen Handfläche, später mit
beiden auf den Teig und presse/ziehe ihn so an die Seiten). Es kann
passieren, dass der Teig sich (vor allem, weil es so rutschig ist ;)..)
etwas zurückzieht oder - wenn ihr zu sehr zerrt - reißt, dann müsst ihr
euch einfach etwas mehr Mühe geben - kleine Löcher ggfs. einfach
stopfen. ;) Klappt es nicht auf Anhieb und ihr seid die Versuche leid,
könnt ihr den Teigling auch schon einmal mit dem Nudelholz "vorrollen"
und dann nur noch auf dem Backblech in die Ecken drücken.
Gebt dann eine gute Kelle von eurer Soße in die Mitte des Teiges und verteilt sie mit der Kelle von innen nach außen über die gesamte Pizza. Streut ein gutes Stück Streukäse über die Pizza und belegt sie nach herzenslust (siehe in der Zutatenliste für Belagbeispiele).
Bevor
die fast fertige Pizza in den Ofen wandert, streut ihr etwas Oregano
über die Pizza. Das gibt ihr den gewissen Kick! Ich packe den frischen
Basilikum übrigens oft vor dem Backen auf die Pizza; man kann ihn aber
auch genauso gut erst nach dem Backen auf die Pizza tun. So geht er
nicht ein und es sieht optisch ansprechender aus.
Die Pizza wandert nun für 5 bis 6 Minuten in den Ofen. Ab rein, Klappe zu, wir haben Hunger! Habt ab der 4. Minute ruhig einen ständigen Blick für eure Pizza; es gilt immernoch die alte Bäckerregel: Wenn (gold-)braun, dann fertig. Denkt dran: Mittlere Schiene, am besten mit Gitterblech (wenn mit Pizzablech gebacken, sonst normales Blech!).
Holt
sie nun raus und .. STOPP! - noch nicht essen. :) Erst befreit ihr sie
mit einem Schaber vorsichtig vom Blech und schiebt sie auf euren
Pizzateller. Geturtled (geschnitten) wird sie mit dem coolen
Pizzaschneider, alternativ gehen auch Messer und Gabel. Wenn ihr nicht
gerade auf Diät seid, könnt ihr auch noch ein paar Tropfen Olivenöl über
die Pizza träufeln - das macht's besonders lecker.
Ihr habt lange durchgehalten und solltet belohnt werden: Ihr dürft nun essen. :) Guten Appetit!
... eine kleine FAQ:
Was ist mit dem restlichen Teig?
Der Teig lässt sich wunderbar einfrieren! Am besten macht ihr einzelne Portionen und gebt sie je einzeln in Gefrierbeutel. Wenn ihr ein Nudelholz zur Hand habt, könnt ihr den Teigling im Gefrierbeutel bereits schön platt rollen. So braucht ihr beim nächsten Mal nur noch den Teigling aufs Blech schmeissen, belegen und fertig. :)
Alternative Brot: Du kannst den bloßen Teig übrigens für ca. drei Minuten (vorausgesetzt, der Teig ist genauso dünn wie eine Pizza; wenn du größere Laibe machst, dann natürlich mehr Backzeit) auf einem Backblech (bei selbiger Temperatur) backen; das so entstandene Brot schmeckt super zu Salaten oder als Beilage zu anderen Gerichten.
To be continued.
Ich habe mittlerweile schon des öfteren Pizzen selber gebacken und mich (teils stundenlang) in einschlägigen Kochforen getummelt, um auch noch die letzte Geschmacksknospe mit Freude zu erfüllen oder der Pizza den letzten Feinschliff zu verpassen. Alle diese Tipps versuche ich in meiner Anleitung unterzubringen. Wenn ihr eine Frage habt, fragt! und ich ergänze die FAQ (s. u.). Auch für Anregungen bin ich dankbar. :)
Das Rezept ist für 5-6 normale Pizzen (Durchmesser 28 cm) ausgelegt; der Teig lässt sich wunderbar einfrieren, wenn ihr also zu viel über habt, weil ihr euch an den Mengen aus meinem Rezept orientiert habt, macht das gar nix. Lest dazu unten mehr.
Die gesamte Arbeitszeit beläuft sich für geübte Hobbyköche auf ca. 20 - 30 Minuten. Wartezeit leider etwas länger, wenn ihr keine tiefgefrorenen Teiglinge habt. Aber das kann sich ja schnell ändern. :)
Also, bevor wir starten, zunächst einmal die Materialliste:
- Backblech (vorzugsweise Pizzablech, vor allem des coolness-Faktors wegen, s. u.)
- eine große Schale für den Teig, eine kleine Schale für die Tomatensoße
- ein Mixer (Stabmixer bevorzugt)
- eine Waage zum Abwiegen der Zutatenmengen (unter Umständen tut es auch die Briefwaage, wenn ihr eine habt - eine Anschaffung für die Küche lohnt sich aber auch, wenn ihr öfter mal backt/kocht...)
- optional, aber cool und eigentlich must-have: Pizzateller und Pizzaschneider
- optional: Gefrierbeutel (zum Einfrieren von Teig)
- optional: Nudelholz (vor allem, wenn man ein großes Blech backen möchte) - ansonsten tut's mit etwas Glück und Geschick auch die Hand :)
... für den Teig:
- 925 g Mehl (ein gutes 405er [405 ist der Typ, der auf dem Mehl draufsteht] ist vollkommen OK)
- Olivenöl (25 ml)
- Salz (20 g)
- lauwarmes Wasser (500 ml)
- 40g Frischhefe (findet ihr im Kühlregal; oftmals sind das 42g Blöcke mit begrenzter Haltbarkeit [ca. 2-4 Wochen]) .. da die nix kosten, kann man davon ruhig 2-3 Stück mitnehmen. Der nächste Pizzaheißhunger ist vorprogrammiert. :)
- optional: eine Prise Zucker
- eine Dose gehackte Tomaten
- 1/3 Tube Tomatenmark (dürften etwas um die 70 g sein)
- Salz
- Zucker (mengemäßig jedenfalls weniger als Salz :)..)
- Oregano
- Pfeffer
- mein persönlicher Favorit, weil ich es gerne etwas schärfer mag: Chiliflocken
- Streukäse (z. B. Emmentaler, um die 40-45% Fettgehalt)
- Oregano
- Olivenöl
- (milde) Peperoni
- frischer Basilikum
- für Pizza Mozzarella: dünne Tomaten- und Mozzarellascheiben
- für Pizza Salami: Salamischeiben (oh wunder)
- ... ansonsten seid kreativ und schaut ggfs., was der Kühlschrank noch so hergibt. Heute gab es bei mir auf der Pizza zum Beispiel noch Fetakäse; der verläuft auch gut und schmeckt spitze.
Beginnen wir also damit, den Teig vorzubereiten (Arbeitszeit ca. 15 Minuten). Da er nach dem Kneten optimalerweise ca. zwei Stunden ruhen sollte, ist er als erster an der Reihe.
Holt eure große Schüssel und gebt das Mehl hinein; in das zweite Gefäß, in der sich das lauwarme Wasser (wichtig: lauwarm meint lauwarm, und nicht heiß oder heißer, denn sonst stirbt euch die Hefe weg und euer Teig geht nicht auf!) befindet, bröselt ihr den Block Hefe, gebt das Olivenöl und das Salz hinein. Es ist eine Glaubensfrage, ob noch eine Prise Zucker hinzugetan wird; ich lass ihn üblicherweise weg. Er soll (angeblich) den Teig noch besser aufgehen lassen (weil Hefe zum Arbeiten Kohlenhydrate benötigt, der im Zucker enthalten ist); für meinen Teil reichen die Kohlenhydrate aus dem Mehl, der Teig geht immer bombig auf. :)
Rührt das lauwarme Wasser samt den Zutaten fleißig um, bis sich alles aufgelöst hat. Gebt die Brühe zum Mehl und knetet das Mehl nun ca. 5 - 10 Minuten. Das Ziel ist es, dass sich der Teig schön elastisch anfühlt, keine Blasen o. ä. mehr zu sehen sind und vor allem nicht mehr an den Händen klebt.
Da sind wir nun auch schon beim Nachteil des Knetens von Hand: Der Teig klebt wie Sau - anfänglich. Keine Angst, das gibt sich mit zunehmendem Kneten. Erinnert ihr euch an die verbliebenden 75g Mehl aus einem Kilo (ihr habt ja nur 925g Mehl für den Teig genutzt)? Ihr dürft davon ca. 1/3 peu à peu benutzen, um den Teig etwas zu "entkleben". Das lohnt sich aber erst frühestens nach ca. 3-4 Minuten - vorher müsst ihr da durch. Je besser ihr knetet, desto besser wird der Teig und geht dementsprechend auf.
Deckt den Teig mit einem Küchentuch gut ab (damit der Teig keine unschöne Haut bildet) und stellt ihn in seiner Schale an einen warmen Ort (bitte nicht auf die Idee kommen den Ofen anzuschmeissen und ihm "Feuer" zu geben - das bringt nix, außer Kummer). Euer Teig sollte sich nach einer zweistündigen Ruhepause locker verdoppeln, wenn nicht gar verdreifachen. In der Zwischenzeit könnt ihr euch der Grundsoße widmen (und davon naschen... jedoch nicht zu viel!).
 |
| Teig nach einer Stunde Ruhezeit |
Die Soße ist schnell gemacht; einfach alle Zutaten in eine Schale geben, bei den Gewürzen mengenmäßig einfach so würzen, wie euch es am besten schmeckt (Zutaten habt ihr ja in der Zutatenliste). Fertig? Gut. Dann zückt den Stabmixer und mixt alles gut durch (Achtung: Spritzgefahr!). Soße fertig, ggfs. nochmal abschmecken!
 |
| fertig pürierte Soße |
Für die Pizza an sich empfehle ich ein Pizzablech. Die Teile lohnen sich wirklich (bitte jedoch keine beschichteten, sondern z. B. welche aus Blaublech - wie bei den Profis! ;)..). Auf dem Foto seht ihr meines von GRÄWE 28 cm Durchmesser - Kostenpunkt: 6,90 € bei Amazon. Das sieht nicht nur cool und professionell aus, sondern macht auch noch Spaß und ist handlich beim "Ausrollen" und Belegen des Teiges.
 |
| vorbereitete Belegfläche mit Pizzablech |
Gebt dann eine gute Kelle von eurer Soße in die Mitte des Teiges und verteilt sie mit der Kelle von innen nach außen über die gesamte Pizza. Streut ein gutes Stück Streukäse über die Pizza und belegt sie nach herzenslust (siehe in der Zutatenliste für Belagbeispiele).
 |
| Pizza im Rohzustand |
Die Pizza wandert nun für 5 bis 6 Minuten in den Ofen. Ab rein, Klappe zu, wir haben Hunger! Habt ab der 4. Minute ruhig einen ständigen Blick für eure Pizza; es gilt immernoch die alte Bäckerregel: Wenn (gold-)braun, dann fertig. Denkt dran: Mittlere Schiene, am besten mit Gitterblech (wenn mit Pizzablech gebacken, sonst normales Blech!).
 |
| Fertigungsprozess :) |
Ihr habt lange durchgehalten und solltet belohnt werden: Ihr dürft nun essen. :) Guten Appetit!
 |
| fertige Pizza mit Feta |
Was ist mit dem restlichen Teig?
Der Teig lässt sich wunderbar einfrieren! Am besten macht ihr einzelne Portionen und gebt sie je einzeln in Gefrierbeutel. Wenn ihr ein Nudelholz zur Hand habt, könnt ihr den Teigling im Gefrierbeutel bereits schön platt rollen. So braucht ihr beim nächsten Mal nur noch den Teigling aufs Blech schmeissen, belegen und fertig. :)
Alternative Brot: Du kannst den bloßen Teig übrigens für ca. drei Minuten (vorausgesetzt, der Teig ist genauso dünn wie eine Pizza; wenn du größere Laibe machst, dann natürlich mehr Backzeit) auf einem Backblech (bei selbiger Temperatur) backen; das so entstandene Brot schmeckt super zu Salaten oder als Beilage zu anderen Gerichten.
To be continued.
Abonnieren
Posts (Atom)