We need to reset HTML5 and start over.
Dieses Zitat von Douglas Crockford sollte in den vergangen Wochen an den meisten von uns ein- oder zweimal vorbeigescrollt sein. Egal ob auf Konferenzen oder im Interview, der Javascript-Altmeister wird nicht müde, zwar einige Ideen von HTML5 zu loben aber auch ganz klar zu sagen, dass es seiner Meinung nach ein Schritt in die falsche Richtung ist und eine Vollbremsung angebracht sei. Warum ist das so?
Das Problem, das HTML5 löst (nämlich dass bisherige Web-Technologien ein unzureichendes Rüstzeug für Webapps sind) ist laut Crockford nicht das Problem, das dem Web unter den Füßen brennt – vielmehr müsste Sicherheit die Top-Priorität genießen. Heutige Webbrowser machen es nämlich Übeltätern recht einfach: jedes Script, das auf einer Website läuft, darf alles – es darf Cookies setzen und auslesen, es darf die Website selbst verändern, es darf den User bitten sein Passwort einzugeben und vieles mehr. Sobald es einem Angreifer also irgendwie gelingt, einen <script>
-Schnipsel irgendwo auf einer Website einzuschleusen (z.B. auf einer Profilseite in einem sozialen Netzwerk), kann er den Browser eines jeden Besuchers dieser Seite übernehmen. Das nennt man Cross-Site-Scripting (XSS).
XSS ist eine der größten Sicherheitslücken des Webs und gleichzeitig auch eins seiner besten Features, denn erst die umfassenden Privilegien für Scripts machen es möglich, Dinge wie Google-Maps, Facebook-Buttons und Flattr-Widgets mit zwei Zeilen HTML (besagten <script>
-Schnipseln) einzubauen. Die Scripts dürfen die Seite selbst verändern um ihre Buttons und Bilder zu platzieren, was man ja Google, Facebook und Flattr durchaus gerne erlauben, Datendieben aber gerne untersagen würde. So einfach ist es aber nun eben nicht und HTML5 verändert an diesem Zustand nichts – im Gegenteil, Technologien wie Offline-Speicher eröffnen interessierten Kriminellen neue, attraktive Angriffsziele.
Douglas Crockford vertritt die Auffassung, dass Sicherheit wichtiger als neue HTML-Elemente sei. Seiner Ansicht nach gehört die HTML5-Entwicklung gestoppt bis ein besseres Sicherheitsmodell für den Browser erdacht und implementiert wurde. Danach sollen die Einzelteile von HTML5 Stück für Stück den neuen Sicherheitsvorgaben angepasst und re-implementiert werden. Alles andere verschlimmere nur die XSS-Problematik, die ohne Änderungen am Browser selbst nicht in den Griff zu kriegen sei.
Ich persönlich tu mich mit diesem Ansatz schwer, gleichwohl an der Diagnose, dass XSS ein Problem ist, natürlich nicht zu rütteln ist. Aber man muss auch sehen, dass dass das Kind HTML5 bereits in den Brunnen gefallen und auf dem Weg nach unten mindestens schon zum nervigen Teenager herangewachsen ist. Es ist schwer vorstellbar, dass da noch irgendeine Form von Reset möglich sein soll, zumal bekannt ist, wie lange es dauert, bis sich eine Technologie in wirklich allen Browsern auf breiter Front etabliert hat. Außerdem ist nicht zu vergessen, dass HTML5 ja selbst das Ergebnis eine geplanten Web-Resets, nämlich XHTML 2 ist – das Web ist eben nicht die Bühne für Resets oder Revolutionen, sondern viel mehr ein Ort der graduellen Veränderungsprozesse. Vor diesem Hintergrund habe ich so meine Probleme damit, We need to reset HTML5 and start over
als einen ernst gemeinten, konstruktiven Vorschlag anzusehen. XSS reparieren, gerne – aber dafür HTML5 stoppen, das wird schon sehr schwierig.
Kommentare (27)
Chris ¶
13. Juli 2010, 10:08 Uhr
"Aber man muss auch sejhen, dass dass das Kind HTML5 "
nett :D
schöner Artikel und der Herr Crockford hat da meine vollste Zustimmung.
Gruß
Chris
Björn ¶
13. Juli 2010, 10:15 Uhr
Mir erschließt sich der Zusammenhang auch nicht ganz. Sicherheit ist immer wichtig. Beides muss vorangetrieben werden. Sicherheit und HTML5. Aber auch ganz andere Themen. Qualität und Usability z.B. Davon abgesehen muss man sich als Webdesigner und -entwickler nicht auch mit Themen auseinandersetzen, für die andere zuständig sind. Sicherheit gehört wenn dann nur indirekt zu Dingen, mit denen ich mich befassen muss.
Peter ¶
13. Juli 2010, 10:30 Uhr
Zitat Chris:
Ups. Fixed, danke!
Sir John ¶
13. Juli 2010, 11:26 Uhr
"XSS ist eine der größten Sicherheitslücken des Webs und gleichzeitig auch eins seiner besten Features, denn erst die umfassenden Privilegien für Scripts machen es möglich, Dinge wie Google-Maps, Facebook-Buttons und Flattr-Widgets mit zwei Zeilen HTML (besagten -Schnipseln) einzubauen."
Dann sollte man das externe Zeug beispielsweise Serverseitig verarbeiten und keine Fremdscripts einbauen! Das war im Grunde schon immer ein "NO GO".
Aber das ist eben wie mit dem Iran&Uran: manchen Leuten sollte man solch ein gefährliches Zeug wie HTML5 nicht in die Hände geben, denn: Sie wissen zu oft nicht was sie tun. <;)
Peter ¶
13. Juli 2010, 11:32 Uhr
Zitat Sir John:
Ich glaube das ist bei allem, was komplexer als ein Facebook-Button ist, nicht wirklich praktikabel. Und gerade für Nichtnerds ist es doch ein Segen, so einfach Ads, Analytics und Maps und was nicht alles einbauen zu können.
Sir John ¶
13. Juli 2010, 11:35 Uhr
Zitat Björn:
Nichts für ungut aber: da fällt mir nur eins ein: EPIC FAIL. Designern würde ich das gerade noch durchgehen lassen aber für einen Entwickler ist sowas wohl mehr als ein Armutszeugniss.
Sir John ¶
13. Juli 2010, 11:39 Uhr
Zitat Peter:
Nichtnerds bauen auch (hoffentlich, glücklicherweise,...?) keine Sicherheitsrelevanten Seiten. MySpace ist da der richtige Tummelplatz.
Alles andere sollte man dann doch den Nerds überlassen. ;)
Peter ¶
13. Juli 2010, 11:39 Uhr
Zitat Sir John:
Meinst du nicht das hängt davon ab, was man entwickelt? Soll ja Leute geben die vorrangig/ausschließlich das Frontend beackern...
Sir John ¶
13. Juli 2010, 11:46 Uhr
Gibt es 'n Wordpress-Plugin zum gezielten Aussperren einzelner Kommentar-Trolle?
less than 10 seconds ago via Gwibber
Ufff, so trollig war das gar nicht gemeint. Tschuldigung!
Dann eben keine Diskussion über HTML5&Sicherheit, schade.
Björn ¶
13. Juli 2010, 11:50 Uhr
Zitat Sir John:
Der legendäre Webmaster kann natürlich alles ;-)
Peter ¶
13. Juli 2010, 11:50 Uhr
Zitat Sir John:
Dann verstehe ich nicht ganz worauf du hinaus willst. Sind JS-Widgets nun in den Händen von Nichtnerds böse oder nicht? Wieso sind MySpace und Co nicht sicherheitsrelevant? Gerade da gab es doch früher allerlei recht erfolgreiche XSS-Angriffe? Ich kann dir nicht wirklich folgen.
Du warst gar nicht speziell gemeint damit :)
Sir John ¶
13. Juli 2010, 11:50 Uhr
Zitat Peter:
Ja, schon... aber wenn die Frontentackerer das Backend aufreissen und zwielichtigen Gestalten Tür&Tor öffnen sollte man wenigstens ab und zu mal einen Sicherheitsnerd danebensetzen bzw. das Ganze validieren lassen.
Es ging mir bei dem Kommentar auch nur um den Unterton "Ich bin Designer...und natürlich auch Entwickler. Sicherheit geht mich nichts an... hauptsache schön bunt".
Das ist leider in der Branche sehr weit verbreitet. Wollte damit niemandem ans Bein pinkeln sondern nur einen Missstand ansprechen.
Sir John ¶
13. Juli 2010, 11:53 Uhr
Zitat Björn:
Nein, kann er nicht. Er sollte nur ein Auge und Erfahrung für Sicherheitsrelevante Themen haben und ab und an mal einfach "die Nerds" befragen.
Niemand kann alles wissen aber das Netz ist gross... Netzwerken fetzt und zusammen ist man stark. :)
Sir John ¶
13. Juli 2010, 11:58 Uhr
Zitat Peter:
Du hast Recht: jede Seite, die Personenbezogene Daten enthält, und wenn esn ur ein paar Bilder und die Emailaddy sind sollten 100%ig XSS-Proof sein... das es oft anders ist sah man z.B. vor ein paar tagen bei youTube und...und...und...
Die Hacker schlafen eben leider auch nicht. Da gibts nur eins: informieren und sich und seine Produkte ständig hinterfragen und verbessern.
micha ¶
13. Juli 2010, 12:15 Uhr
"was man ja Google, Facebook und Flattr durchaus gerne erlauben, Datendieben aber gerne untersagen würde"
öhmm, das ist aber für viele (verständlicher- und berechtigterweise) dasselbe ...
Sir John ¶
13. Juli 2010, 12:23 Uhr
Zitat micha:
Hehe, der war gut! :D
Obwohl ich da bei den dreien nicht ganz so schizophren rangehen würde.
Bei einem "Süsses Tamagotchiviech"-Widget das von einem *.ru Server kommt sieht die Sache schon ganz anders aus. Leider können viele "Nichtnerds" (s.o.) gut nicht von böse unterscheiden.
micha ¶
13. Juli 2010, 12:25 Uhr
Zitat Sir John:
achja? und woran will "der nerd" denn erkennen, was da im hintergrund verhökert wird bei google, facebook und konsorten? wo machst du denn da den strich? merkst selber, nä? :-)
Sir John ¶
13. Juli 2010, 12:38 Uhr
Zitat micha:
Nicht wirklich: die Leute verdienen mit Nutzerbezogener Werbung ihr Geld. Ganz legal und ganz offen. Es gibt nicht viele Firmen denen ich ein "Don't be evil" abnehme aber wenn man immer nur böses in den Menschen sieht sollte man den Computer besser gleich ausgeschaltet lassen und sich ein BILD-Abo besorgen. Die sagen wenigstens immer die Wahrheit und man bekommt keine XSS-Bömbchen untergeschoben. ^^
Im Grunde hat meiner Meinung nach diese ganze "Google, Facebook, Apple sind sooo böse"-Diskussion die im Netz gerade umgeht nur einen Grund: NEID
micha ¶
13. Juli 2010, 12:55 Uhr
Zitat Sir John:
na da fehlt ja nur noch ein Auto-/Hitler-Vergleich ... nee, so wird das nix mit dem Nerd sein. da sollte man schon in der lage sein, ein paar sachverhalte anzuerkennen.
NEID - ich fassesnicht m(
Sir John ¶
13. Juli 2010, 13:03 Uhr
"in der lage sein sachverhalte anzuerkennen"
schon klar... zum Glück haben wir ja den absoluten Insider hier.
Dank' dir!
Ich weiss schon wo das endet:
"Nein, du" "Immer 2x mehr als du" "Das ist so, weil es alle sagen"... das ist mir echt zu doof.
und ausserdem: Godwin’s law... you asked for it... end of discussion
Paul ¶
13. Juli 2010, 14:23 Uhr
Für manche mag Facebook einen Nutzen haben, aber wenn es mir nun ungefragt von jeder x-beliebigen Seite aus auflauert und nachspioniert, muss ich es leider für einen Datendieb halten. :-)
Es bleibt nur die Frage, ob es Ziel von HTML 5 sein kann, so etwas zu unterbinden. Wo soll denn ein Standard da den Strich ziehen? Schließlich ist es doch dynamisch erstellter HTML-Code, der dafür sorgt, dass XSS ermöglicht wird. XSS zu verhindern ist somit eher das Problem der CMS und -Frameworks als des HTML-Standards.
molily ¶
13. Juli 2010, 15:30 Uhr
Guter Artikel, aber da gäbe es noch viel mehr anzumerken.
Man sollte vielleicht erklären, aus welcher Perspektive Crockford diese Kritik äußert. Er arbeitet für Yahoo, also einen Betreiber eines Werbenetzwerks und Anbieter von Widgets. Wie du auch schreibst, funktionieren Werbung und Widgets über gewolltes XSS. Für solche Anbieter besteht das Problem, dass sie unzählige Server betreiben und dass sie die Inhalte v.a. bei Werbung meist selbst nicht unter Kontrolle haben. Es gibt tausende Werbetreibende und Widget-Entwickler, deren Code Yahoo und Co. ausliefern. Das Sicherheitsproblem, an dem Crockford arbeitet, ist nicht allein »böses« XSS durch Script-Injection-Lücken in Websites. Es ist vielmehr die Herausforderung, dass gewollte Mashups sicher sein müssen.
Zum einen sollen Werbung und Widgets interaktiv sein - die meisten Flash-Banner sind es bereits. Das muss auch mit JavaScript möglich sein. Es ist derzeit nicht sicher möglich, weil dieses JavaScript nicht in einer Sandbox läuft. Es ist schwierig, automatisiert die Sicherheit solcher Scripte zu prüfen bzw. zu gewährleisten.
Zum anderen muss ein Widget-/Werbenetzwerk-Betreiber davon ausgehen, dass einer von der unzähligen Proxies kompromittiert wird und Schadcode ausliefert. Das kann immer passieren, und trotzdem sollte das eingebundene Script keinen Zugriff auf die Daten der Seite haben, in die es eingebunden wird.
Deshalb hat Crockford an AdSafe (http://www.adsafe.org/) gearbeitet. Ein ähnliches Projekt ist Google Caja. Da ging es weniger darum, wie einzelne Website-Betreiber ihre Site vor Script Injection schützen, sondern darum, wie Widget-/Werbe-Anbieter garantieren können, dass die von ihnen eingebundenen Scripte dynamisch und multimedial sein können, jedoch keinen Schaden anrichten können.
Viele dieser Ideen sind in den ECMAScript 5 Strict Mode geflossen. Crockford hat schon recht damit, dass sich in HTML5 währenddessen so gut wie nichts tut, um das XSS-Problem zu lösen. Die HTML5-Community hat sich dieses Problems nicht angenommen - daher tat es die ECMAScript-Community. Der ES5 Strict Mode ist nur ein Feigenblatt, denn die gegenwärtigen Webstandards und insbesondere HTML5 erzeugen das Problem erst, anstatt es zu verhindern. Daher träumt Crockford von einem »Safe Mode«, der nicht nur JavaScript, sondern den gesamten Browser umfasst.
Eine Ausnahme ist etwa das neue sandbox-Attribut bei iframe: http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox - Das ist aber alles weit von dem Object-Capability-System entfernt, welches sich Crockford für die Browser vorstellt.
Paul ¶
13. Juli 2010, 19:59 Uhr
Danke für die detaillierte Aufklärung.
ChrisB ¶
13. Juli 2010, 22:18 Uhr
Erst mal muss man, wie schon gesagt wurde, zwischen dem „gewollten“ und dem unbeabsichtigten XSS unterscheiden.
Letzteres ist eigentlich kein Problem, wenn die Leute, die vor allem die serverseitige Logik programmieren, Ahnung von dem haben, was sie tun. (Dass es damit in der Praxis doch ein Problem ist, weil heutzutage jedes Kind nach dem Ausprobieren des “hello world”-Beispiels im Handbuch von Programmiersprache XY meint, es könne jetzt Programmieren und müsse sein eigenes CMS/Forum/Social Network schreiben, ist eine andere Geschichte.)
Und was das „gewollte“ XSS angeht, das Einbinden von Widgets/Mashups/etc. - da gibt's ja schon brauchbare Ansätze einer ausbalancierteren Lösung als strikter SOP auf der einen und „alles ist erlaubt“ auf der anderen Seite. Cross-Domain XMLHttpRequest sei hier nur mal als Beispiel genannt (das läuft über HTTP-Header wie Origin und Access-Control-Allow-Origin).
Allerdings tue ich mich auch schwer damit, diese Problematik überhaupt im Zuständigkeitsbereich von HTML5 zu sehen.
Mario Fink ¶
14. Juli 2010, 07:59 Uhr
Ich denke, Crockford wollte mit seiner Aussage bewusst provozieren.
Hätte er anstatt,
"We need to reset HTML5 and start over"
etwa behauptet,
"HTML5 is great, but we need to take care of some security issues",
dann hätte es diese Diskussion hier wohl nie gegeben.
Robert Agthe ¶
14. Juli 2010, 11:31 Uhr
Ich finde, um etwas generischer zu werden hier, das ja das Internet wie kein zweites Medium, wünsche nach paradoxen laut werden lässt. Die Unsicherheit von JavaScript ist glaube ich gleichzeitig der Grund seines Erfolges. Genau wie die mp3 das "stehlen" von Musik erlaubt hat.
Ich finde es auch ein bisschen Quatsch "Standards" im Netz zu schaffen. Ich glaube sowas bildet sich von ganz alleine. Man sollte das offen halten und evtl. nur von Features reden. Das würde auch dem html5 Standard gerechter, der wohl nie wirklich endgültig verabschiedet wird.
Was man von welchen Standard benutzt und wie, hängt nicht vom Standard ab, sondern vom Browser. Solange Browser bestimmen, was im Netz verwendet werden darf und was nicht, sind Standards im Netz meiner Meinung nach überflüssig.
Ich träume ja ein bisschen von einer art thin client, wo die rendering engine aus dem netz geladen wird und nicht mit dem browser ausgeliefert wird. oder ähnliches.
Hab ich jetzt am Thema vorbeigeredet? Egal. Ich finde target="_blank" super.
molily ¶
15. Juli 2010, 09:26 Uhr
Zitat Mario Fink:
Er hat dies nicht gesagt, weil er das nicht meint. Seine Kritik setzt an der Wurzel an. Es sind nicht »some security issues«, Sicherheit lässt sich nicht in Version 2.0 nachträglich dranheften. Dem Mashup-Web fehlt, wie Crockford fundiert belegt, ein grundlegendes Sicherheitsmodell. Same-Origin Policy, Cross-Origin Resource Sharing usw. sind nicht genug.
Wenn man sich die Philosophie des ES5 Strict Modes zu Gemüte führt, erkennt man, was er meint: Dieser deaktiviert unsichere Features, beschränkt sich auf die »Good Parts«. Das heißt natürlich nicht Stagnation, bei ES5 sind natürlich viele Features hinzugekommen - unter der Prämisse, gewisse Fehler nicht zu wiederholen und die Sicherheit zu verbessern (z.B. durch property descriptors, seal, freeze).
Dass Crockfords Rhetorik so scharf klingt, ist also einerseits sachlich gegeben. Andererseits liegt es daran, dass die HTML5-Community sich völlig unbeeindruckt von der Kritik zeigt, die Crockford mittlerweile seit Jahren äußert.