nicht angemeldet
Hi,
- Ich kenne kein anderes Programm als einen Browser, in dem man einfach so das Design desjenigen verstellen kann, der das Programm, oder den Informationsinhalt, gestaltet hat.
Beide Textverarbeitungssysteme, die ich auf dem Rechner habe (AmiPro und WinWord), haben einen Zoom-Modus.
-warum kann man überhaupt Javascript im Browser deaktivieren, wenn jeder sagt, dass es kein Sicherheitsrisiko dabei gibt. Oder gibt es eins?
Es gibt sogar zwei.
1. Beabsichtigte Sicherheitsrisiken.
So nenne ich Designentscheidungen, die in JavaScript Dinge eingeführt haben, die zu bedenklichen Aktionen genutzt werden können.
Beispiel dafür: Die Lesezugriffsmöglichkeit per JavaScript auf die Browser-History.
Es ist möglich (wenn auch unüblich), daß URLs als Parameter sicherheitsrelevante Informationen (Passworte) enthalten.
Und ein Anwender ist sich möglicherweise gar nicht bewußt, ob er im WWW mit einer Anwendung arbeitet, die bezüglich solcher Angriffe verwundbar ist: Eine Online-Banking-Oberfläche mit Framesets zeigt mir in der Adreßzeile nur den URL des Einstiegspunkts, die URLs der Sub-Frames sind womöglich selbst durch Drüberfahren per Maus nicht sichtbar, wenn der Seitenanbieter per JavaScript-Eventbehandlung in meiner Statuszeile herumpfuscht.
Um einer Anwendung ein potentielles Sicherheitsrisiko ansehen zu können, muß der Anwender also den Quelltext dieser Anwendung lesen und *analysieren*! Wie viele Anwender können das? JavaScript abschalten (zumindest direkt nachdem ich die Online-Banking-Anwendung verlassen habe) geht viel einfacher. Oder zwei Browser benutzen, einen mit JavaScript an für wenige 'vertrauenswürdige' Sites, den anderen ohne JavaScript zum Surfen.
In jedem Fall enthält die History Deine Browsing-Geschichte. Wenn jemand per JavaScript die History ausspähen und per URL-Konstruktion an einen eigenen Server senden und damit protokollieren kann, dann empfinde ich das zumindest als unerwünscht. Daß JavaScript in Mails (die z. B. mit Netscape auch ein Browser lesen kann) auch Spam eintragen kann, darauf hat Wolfgang Wiese erst neulich hingewiesen. Und um dies zu entsprechend zu konfigurieren, muß der DAU-Besucher immerhin JavaScript von JavaScript unterscheiden können.
2. Unbeabsichtigte Sicherheitsrisiken
Selbst wenn ein Konzept so spezifiziert ist, daß es bei korrekter Implementierung kein Sicherheitsrisiko darstellt, wer sagt Dir, daß *jeder* Browser es korrekt interpretiert?
Klar, es gibt beispielsweise das Konzept der "sand box", durch welches Java und JavaScript zwar lokal Daten halten, nicht aber beliebige Dateien der eigenen Festplatte verändern können sollen. Aber laß das von einem Browser-Programmierer einfach nur falsch implementiert werden, und schon ist das Loch da.
Je komplexer die Browser werden, und je mehr Sonder-Features in ihnen verfügbar sind, desto leichter können Fehler entstehen. Der M$IE erlaubt beispielsweise *bestimmten* JavaScript-Anwendungen (HTA, z. B. dem Self-Browser) sehr wohl, aus der Sandbox heraus auf die Festplatte zu schreiben. Dies kann mehrere Probleme auslösen:
a) Der Anwender muß erneut zwischen JavaScript und JavaScript differenzieren und kann dabei Fehler machen, d. h. potentiellen Angreifern Zugriffe auf seinen Rechner erlauben, weil er sie nicht von der 'ungefährlichen' JavaScript-Variante unterscheiden kann.
b) Der Programmierer wird nicht zwei komplette JavaScript-Engines implementieren, sondern eine einzige und in dieser an beliebig vielen Stellen Abfragen einbauen, welche Variante gerade vorliegt. Laß ihn auch nur eine einzige falsche Abfrage einbauen oder eine vergessen, und das Sicherheitsloch ist da.
De facto sind immer wieder in verschiedensten Browser-Implementierungen Sicherheitsprobleme gefunden worden. Wer von seinem Besucher erwartet, JavaScript bedenkenlos angeschaltet zu haben, der verlangt von ihm, diese Probleme entweder sehr genau zu verstehen (z. B. nachzuprüfen, welche davon in seinem konkreten Browser auftreten können und welche nicht) oder sie einfach zu ignorieren.
Viele Grüße
Michael