Freitag, 30. Januar 2009
Golem-Leser Fragen - Ich Antworte I
Ich bin zwar nicht ganz sicher, ob es ein Trollversuch sein sollte, aber ich beantworte mal die Frage, die beim Artikel Microsoft gibt Web Sandbox als Open Source frei gestellt wurde:
Wäre es nicht sinnvoller eine solche Funktion direkt in die JavaScript Engine einzubauen? Das wäre doch mal was, womit der IE 8 glänzen könnte und alle anderen müssten mitziehen.
Die einfache Antwort: Es handelt sich um eine ganz andere Baustelle. Die Idee hinter Web Sandbox von Microsoft und das konkurrierende Google-Caja adressiert nicht den Schutz des Betriebssystem, des Dateisystems oder anderer Programme vor bösen Webseiten beziehungsweise Plug-Ins. Ziel ist die Verhinderung von Cross-Site-Scripting-Attacken über bewusst und freiwillig eingebunden Javascript-Code von Anderen.
Und Javascript wird immer häufiger eingebunden, in Form von Widgets im eigenen Blog oder Web-Apps auf MySpace und Facebook. Es haben nur wenige die Kenntnisse oder überhaupt den Willen, um den eingebunden Code darauf zu prüfen, ob er nicht böse Sachen mit der eigenen Webseite oder dem Profil anstellt.
Das Sicherheitsrisko entsteht, weil der Browser beim Javascript-Code nicht unterscheidet, woher er kommt. Auch der klassische Browserschutz, Code nicht von "fremden" Servern zu laden (Same-Site-Policy), hilft hier nicht weiter. Durch die Art der Einbindung wird diese häufig eben nicht verletzt.
Wenn aber Javascript-Code erstmal vom Browser geladen wurde und innerhalb eine Dokumentes ausgeführt wurde, dann darf er alles - unabhängig, ob er sich nun im Hauptdokument befindet oder irgendwo in einem IFrame innerhalb des Hauptdokumentes. Das ist im Grunde sogar gewünscht, andernfalls wären eine Vielzahl von Web 2.0-Features gar nicht denkbar, die OpenSocial-API erfordert es sogar.
Eine Änderung oder Ergänzung des Sicherheitsmodell im Browser bzw. innerhalb der Javascript-Engine würde uns schlagartig auf den Stand des letzten Jahrhunderts zurückkatapultieren. Also benötigt man einen anderen Weg.
Caja und Web Sandbox nähern sich dem Problem, in dem sie eine Zwischenebene einziehen. Im Wesentlichen implementieren sie eine Reihe von Makros bzw. Javascript-APIs und definieren eine Reihe von Regeln, welche Javascript-Aufrufe kritisch sind.
Es läuft nun wie folgt ab: Wer sicher gehen will, setzt nur Widgets ein, die auf Caja bzw. Web Sandbox aufsetzen. Dazu muss die jeweilige Webseite Caja und/oder Web Sandbox auch unterstützen. Bei MySpace zum Beispiel kann man für seine Apps Caja verwenden. Eine Blog-Plattform/-Software, die Caja oder Sandbox unterstützt, ist mir leider nicht bekannt.
Der Code für das Widget wird normal eingepflegt, bevor er aber tatsächlich ausgeführt bzw. aktiviert wird, durchläuft er einen Analyse-Funktion. Makros werden in realen Code inklusive Absicherungsfunktionen übersetzt und der Code auf kritische Elemente überprüft. Je nach Einstellung wird der Benutzer bei Problemen gewarnt oder gefragt, ob er die Aktion erlauben will; oder das Widget wird komplett deaktiviert und der Code verworfen.
Die Analyse kann serverseitig erfolgen, bei MySpace ist das der Fall, dann kommt beim Client tatsächlich der reale Code an. Das ist sinnvoll, wenn wie bei MySpace, Anwendungen von Dritten sowieso zentral verwaltet und geladen werden. Alternativ kann die Analyse auch rein clientseitig erfolgen. Das ist zwar langsamer, aber auch der einzige Weg, wenn Code während des Ladens einer Webseite von verschiedenen Quellen geladen wird - dem typischen Szenario für Widgets auf dem eigenen Blog.
Hunderprozentige Sicherheit gewährleistet dieser Weg zwar auch nicht. Aber er bringt uns schon mal ein ganzes Stück weiter.
