„Browserhersteller müssen einen goldenen Weg zwischen Sicherheit, Performance und Featurereichtum wählen.“

Interview mit Mario Heiderich über die Sicherheit von HTML5, JavaScript und Co
Kommentare

Wenn eines sicher ist, dann die Tatsache, dass sich Technologien im Web in einer atemberaubenden Geschwindigkeit weiterentwickeln. Doch wie steht es in Zeiten von HTML5, ECMAScript 6 und verwandten Technologien eigentlich um das Thema Sicherheit?

Darüber sprachen wir mit dem Berliner Sicherheitsexperten Mario Heiderich, der sich auf den HTML5 Days in Berlin mit genau diesem Thema beschäftigen wird. In diesem Interview geht um die Weiterentwicklung von Webtechnologien, die Fragen nach Schuld der Browserhersteller und danach, ob moderne Frameworks wie AngularJS alles einfacher machen. Außerdem gehen wir der Sache auf den Grund, warum sich JavaScript in der öffentlichen Wahrnehmung in den letzten Jahren so gewandelt hat.

Viel Spaß also bei interessanten Ein- und Ausblicken.

Herr Heiderich, Sie gelten als einer der führenden Sicherheitsexperten im Webumfeld. Wie sehen Sie ganz allgemein die Entwicklungen der Webtechnologien in den letzten Jahren?

Ist das wirklich Feature-Altruismus, um das Web „nach vorne“ zu bringen?

Mario Heiderich: Kommt drauf an, wo wir zeitlich ansetzen. Wenn wir als Ausgangspunkt mal die Zeit betrachten, in der AJAX und JavaScript populär wurden, dann kann man nur sagen, dass sich ein exponentielles Featurewachstum bemerkbar gemacht hat. Zumindest wahrgenommen – viele der coolen Features, die heute verwendet werden können oder noch in den Spezifikations-Drafts vor sich hin köcheln, gab es ja schon im Internet Explorer 5.5 (Video, Audio, Vektorgrafiken, Templates, Komponenten, XHR etc. etc.). Nur wollte das damals keiner so richtig haben – und stabil, geschweige denn sicher, war das ganze auch nicht. Viele der kritischen, in den letzten Monaten aufgetauchten Browser-Bugs und Exploits kamen tatsächlich durch Features aus diesen alten Tagen zustande – siehe z. B. VML. Jetzt wird das ganze nochmal neu aufgelegt und die Webplattform wird langsam aber sicher auf ein Level gehievt, in dem Webapplikation einer Desktopapplikation in fast nichts mehr nachstehen muss. Schade ist da oft, dass trotz Bestrebungen nach gemeinsamer Arbeit die Browserhersteller doch immer und immer wieder ihre eigenen Süppchen kochen – teils auch sehr aggressiv. Man sehe sich zum Beispiel mal Shadow DOM, das zugehörige CSS, HTML Imports, Custom Elements und so weiter an. Da gab es einiges an Theater auf den Mailinglisten, da bestimmte Vendors ihre eigenen Webapplikationen besser machen, in dem sie den eigenen Browser spezifisch anreichern. Wie bei vielen anderen Dingen muss man sich auch hier fragen: Wer hat eigentlich was davon? Ist das wirklich Feature-Altruismus, um das Web „nach vorne“ zu bringen?

Wir alle erinnern uns an Zeiten, in denen JavaScript als das ultimativ Böse betrachtet und geraten wurde, es zu deaktivieren. Wieso hat sich das in der allgemeinen Wahrnehmung geändert?

Heiderich: Genau das gleiche haben wir über Cookies gedacht. Und es wurde als gute Idee angesehen, die Session-ID über den URL zu transportieren.

Was kann da schon schief gehen, nicht wahr? Im Falle JavaScript hat aber auch der Drift von Webseite zur Webapplikation mit geholfen. Man erinnere sich an die ersten Hotmail-Versionen – der Mailer im Browser.

Aufgrund dieser Webapplikation wurden viele Browserfeatures erst erschaffen. Und da ging nichts ohne JavaScript. Für Anwender wurde ersichtlich, dass Webapplikationen, die sich fast wie echte Desktopsoftware verhalten, grundlegend erst einmal möglich sind. Und außerdem noch ungemein bequem: Gmail ist dann wenige Jahre später eingeschlagen wie eine Bombe. Leute haben stundenlang reglos fasziniert vor dem Gmail-Fenster gesessen und die eingehenden Mails bewundert. Webapplikationen wurden also zugänglicher für eine breitere Masse, einige JavaScript-Gegner sind konvertiert, und viele neue Nutzer sind hinzugekommen, denen die Risiken von JavaScript im Browser völlig egal waren. Wir können also, denke ich, festhalten, dass Bequemlichkeit, Produktivität und Komfort oft größere Anziehung ausüben und die Abschreckungskraft der möglichen Risiken überwiegen. Macht ja auch nichts, bei zu viel Risikobewusstsein schränkt man sich die Möglichkeiten auch oft viel zu stark ein.

JavaScript kann gerne noch viel mächtiger werden.

JavaScript selbst wurde über die Zeit immer mächtiger und schneller, was Dinge wie Pixel-Perfect-Timing-Attacken oder Rowhammer-Angriffe ermöglichte. Was also stimmt nicht mit JavaScript?

Heiderich: Mit JavaScript an sich ist alles in Ordnung. ECMA Script 6 ist zwar etwas kühn was neue Syntaxkonstrukte angeht (Computed Properties, Template Strings, Arrow Functions), läutet aber für sich alleine stehend keine gravierenden Sicherheitsrisiken ein. Interessant wird es erst dann, wenn neue Sprachkonstrukte mit existierenden Technologien zusammentreffen und daraus eine neue Angriffsoberfläche entsteht. JavaScript + DOM, ES6 auf dem Server, neue Syntax und XSS-Filter/-Firewalls. Bislang war es beispielsweise in Flash als sicher angesehen, bei Callback-Parametern schlicht darauf zu achten, dass keine Klammern oder andere JavaScript-typischen Sonderzeichen vorkommen. Dank ES6 ist das aber nicht mehr der Fall – denn jetzt kann der Callback auch alert`1` benannt werden, und nicht nur alert(1).

Damit kommt man also an vielen bestehenden Filtern vorbei. Es „knallt“.

Also immer dann, wenn von einer beteiligten Seite Innovationen eingeläutet werden und die anderen Seiten nicht schnell genug mithalten können – oder den Zusammenhang gar nicht erst erkennen.

JavaScript kann also gerne noch viel mächtiger werden. Wichtig ist, dass verknüpfte Technologien das mitbekommen, Risiken erkennen und sinnvoll reagieren.

Mehr zum Thema verrät Mario Heiderich auf den HTML5 Days 2015 in Berlin. Das Trainingsevent findet vom 5. bis 7. Oktober statt und umfasst zusammen mit den parallel laufenden JavaScript Days und AngularJS Days 30 halbtägige Workshops mit 20 Sprechern.

Weitere Programminfos unter: www.html5-days.de

    

 
Wie viel Schuld ist dabei bei Browserherstellern zu suchen?

Sehen wir also den Browser nicht mehr als warmherziges Geschenk an die Menschheit sondern als ein ökonomisches Werkzeug zum Generieren von Profit.

Heiderich: Alle und keine. Wie immer müssen auch die Browserhersteller einen goldenen Weg zwischen Sicherheit, Performance und Featurereichtum wählen. Und ein Browser ist als unendlich mächtiges Werkzeug niemals komplett sicher. Irgendeinen Exploit gibt es immer. Wenn nicht sogar dutzende und mehr. Das wird sich nie ändern, selbst wenn die Hersteller noch so oft behaupten, der eigene Browser wäre sicher. Die Hersteller kämpfen wiederum natürlich um Marktanteile. Durch Features wie das kleine Suchfenster in Firefox und andere Browser ist der Marktanteil bare Münze und muss um jeden Preis ausgebaut werden.

Speziell wenn bestimmten Herstellern Webapplikation, Suchmaschine und Browser gleichzeitig gehören. Und das Betriebssystem noch dazu. Eben sprach ich schon den Feature-Altruismus an. Gibt es den wirklich? Vor Kurzem gab es einen interessanten Post auf quirksmode.org über die rasant Entwicklung des Webs; und dass man doch bitte mal für die Dauer eines Jahres einen Feature-Freeze verhängen sollte. Von bestimmten Browserherstellern kam da natürlich ein klares Kontra.

Das kann man ähnlich auslegen wie die Meinung der National Rifle Association zum Thema Schusswaffenkontrolle. Sehen wir also den Browser nicht mehr als warmherziges Geschenk an die Menschheit sondern als ein ökonomisches Werkzeug zum Generieren von Profit.

Wer die Frameworks richtig einsetzt, minimiert die Zahl der klassischen Sicherheitslücken.

Tragen Frameworks wie AngularJS und Co. dazu bei, die Gefahren zu minimieren? Oder schaffen sie nur neue Angriffsvektoren?

Heiderich: Beides. Wer die Frameworks richtig einsetzt, minimiert die Zahl der klassischen Sicherheitslücken wie XSS über GET- und POST-Parameter. Wer die Frameworks falsch einsetzt, vergrößert die Angriffsoberfläche dramatisch. Letzteres ist beispielsweise bei dem Hersteller einer Cloud-Management-Software mit Webinterface passiert. Die haben AngularJS falsch eingesetzt und sich dafür in kurzer Folge zwei kritische Sicherheitslücken eingefangen. Mittels dieser konnten wir dank AngularJS, HTML Canvas und ein wenig JavaScript-Magie über einen XSS-Exploit Zugriff auf virtuelle Maschinen in der Cloud erlangen, per SSH-im-Browser die Maschine neu starten, in den Single-User-Modus versetzen und somit Root-Rechte erlangen – ohne AngularJS wäre das nicht geglückt. Dann haben wir mal probiert, wie gut sich das AngularJS-Team mit XSS auskennt und ein Rogue-Ticket erstellt, das bei korrektem Fix einen Bypass im AngularJS-Sanitizer erzeugt. Der „Bug“ wurde tatsächlich gefixt, wir haben einen XSS erzeugt, keiner hat’s gemerkt. Logischerweise haben wir am selben Tag einen Report an das Google-Security-Team geschickt. Und einige Manager im Team waren über unseren Plan bereits informiert, und wir hatten Freigabe. Neutral betrachtet wird die Angriffsoberfläche also größer – aber Entwickler haben die Möglichkeit, ihre Webseiten auf Basis neuer Paradigmen zu bauen und können, so alles glatt läuft, mehr oder weniger nebenbei klassische Lücken wie XSS umschiffen, ohne es zu merken. Nur darf man sich auch nicht blind darauf verlassen, dass alle eingehenden Pull-Requests immer nett gemeint sind. Und je populärer die Library, desto mehr Aktivität und somit Risiko, dass etwas maliziöses übersehen wird.

In HTML5 gibt es viele neue (und wiederentdeckte – siehe SVG) Technologien, über die ebenfalls Angriffe möglich sind; einige davon werden Sie in Ihrem Workshop auf den HTML5 Days vorstellen. Wie schwer ist es, sich gegen Angreifer im Web zu wappnen?

Heiderich: Kommt drauf an. Wenn man schon auf einer riesigen Applikation sitzt, die seit Jahren vor sich hin wuchert, aber zumindest die klassischen Risiken weitgehend im Griff hat, dann entstehen durch die neuen Technologien durchaus neue Lücken. Man muss also fortwährend acht geben und patchen. Und fragen sie mal die Web Application Firewall, wie gut bereits gegen ES6, SVG und andere Angriffe geschützt wird.

Meist gar nicht. Hat man bereits eine sauber gebaute Applikation mit CSP und vernünftiger Implementierung moderner Frameworks, so werden die möglichen Bugs subtiler; daher im Großen und Ganzen etwas schwerer anzugreifen. So oder so, SVG ist noch immer der universelle Weg in viele Applikationen. Es vergeht kaum ein Pentest, bei dem wir nicht mindestens ein Ticket haben, bei dem SVG im Spiel ist. Das war damals eine historische Fehlentscheidung, und wir merken heute noch die Folgen. Faktisch kommt man nicht darum herum, die Browser genauestens zu kennen, um die Risiken abschätzen zu können und dann die Applikation sicher zu bauen. Und ganz wichtig: Code wird mit der Zeit nicht besser sondern zerfällt. Wenn nicht konstant nachgepflegt wird, ist Code, der heute als sicher gilt, schon morgen unsicher. Spätestens wenn neue Features bestehende Sicherheitsannahmen brechen. Stichwort Flash und ES6 Template Strings zum Beispiel.

Mario Heiderich

Mario Heiderich leitet Cure53, eine Sicherheitsfirma in Berlin, die unter anderem auf Angriffe und Verteidigung im Bereich moderner, JavaScript-lastiger Web-Applikationen spezialisiert ist.

 

 

 

Aufmacherbild: Drawing of a man in dangerous situation under threat von Shutterstock / Urheberrecht: Sergey Nivens

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -