nicht angemeldet
Hallo,
Zusätzliche Sicherheit gäbe es tatsächlich erst, wenn lokale Scripte unter Generalverdacht stünden. Eine Art MOTW könnte beim Speichern aus dem Intert höchstens in Form einer kryptographischen Signatur eingefügt werden, zusätzlich ein Dateiattribut, das die Herkunft anzeigt. Zudem dürften solche Scripte keinen Zugriff auf lokale Dateien bzw. Scripte im Internet haben.
Das würde aber bewirken, daß HTML-Seiten mit Javascipt ggfls. nicht mehr lokal nutzbar sind - also z.B. die Offline-Suche von SELFHTML nicht mehr funktionieren würde.
Das wäre zunächst einmal nicht schlimm, denn es ginge darum, dass der Anwender die Attribute manuell zurücksetzen müsste. Er müsste dazu gebracht werden, die Vertrauenswürdigkeit zu prüfen. Am besten ohne den Code selbst überprüfen zu müssen.
Bei einem Download von SELFHTML sollte z.B. die Hash-Summe des Archivs und eventuell eine kryptographische Signatur überprüft werden. Letzteres könnte ein Browser auch automatisch bei jedem HTML-Dokument tun, sofern dieses eine Signatur enthält.
(Ich setze bei diesen Annahmen ein funktionierendes »Web of Trust« voraus. Wenn es ein solches gibt, könnte Windows anzeigen: SELFHTML hat soundsoviel Vertrauenspunkte, daher kann Scripten aus dieser Quelle vertraut werden. Microsoft nutzt Signaturen meines Wissens bereits, nur halt zentralisiert und nur für ausführbare Dateien.)
Der richtige Weg wäre ein anderer: Das Auslesen lokaler Daten ist doch überhaupt nicht sicherheitsrelevant, sondern lediglich die Kommunikation eines lokalen Scripts mit dem Internet - _diese_ müßte reglementiert werden (ganz untersagt oder mit einer Warnmeldung versehen, die der IE jetzt bereits beim Seitenaufruf ausgibt).
Darüber habe ich auch nachgedacht. Die Frage ist, wo man ansetzen will. Sicherheitskritisch wären folgende Vorgänge:
- Eine Änderung der gegenwärtigen lokalen Adresse auf eine Remote-Adresse (location.href und Co., Hyperlinks, Meta-Weiterleitungen, synthetische Events, die entsprechendes ausführen) sowie das Öffnen von neuen Fenstern mit Remote-Adressen
- Das Einfügen von Remote-Ressourcen in Form von Objekten wie object, iframe, img, script und Äquivalente wie new Image()
- Ein Absenden von Formularen zu Remote-Adressen (durch Benutzereingabe oder simulierte Benutzereingabe
Soweit, so gut. Jeder mit JavaScript erzeugte bzw. manipulierte Hyperlink mit Remote-Ziel wird zu einem potenziellen Risiko, weil er zur Kommunikation mit dem Internet dienen kann (wenn auch die in der URL kodierbaren Informationen eingeschränkt sind). Angenommen, der IE würde bei allen obigen potenziellen Schnittstellen zum Internet Warnmeldungen ausgeben, so wäre die Nutzung einer Offline-Dokumentation wie SELFHTML auch ziemlich eingeschränkt. Aber du hast recht, gegenüber dem standardmäßigen kompletten Verbieten des lokalen Lesens/Einbindens wäre das eine Verbesserung.
Mathias
Der Martin
Struppi