© saicle/Shutterstock.com
PHP Magazin
Neue Besen kehren gut, sagt man. Aber sind sie auch sicher?

Wasm - Ist das sicher oder kann das weg?

Schon wieder eine neue Technologie für aktive Inhalte - muss das denn wirklich sein? Als hätten wir mit Flash und Java nicht schon genug Ärger gehabt. Beides wurde wahrscheinlich öfter für Angriffe als für wirklich nützliche Anwendungen verwendet.

Carsten Eilers


Jedenfalls wenn man mal von Spielen und in der Websteinzeit dem Wiedergeben von Videos durch Flash absieht. HTML5 und die dazugehörenden JavaScript APIs decken doch schon alle möglichen und unmöglichen Anwendungsfälle ab. Wieso also noch was Neues erfinden? Vor allem, wo doch jede neue Funktionalität immer auch die Angriffsfläche erhöht, die man doch eigentlich möglichst klein halten möchte. Die Antwort ist ganz einfach: Wieso nicht? Vielleicht ist das Neue ja besser als alles Alte.

Wichtig ist natürlich vor allem, dass es sicher ist. Nicht nur sicherer als Flash oder Java – das ist keine Kunst, so chronisch unsicher wie die sind. Sondern wirklich sicher, von Anfang an und ohne Kompromisse. Wobei Java in der Theorie auch sicher sein sollte, nur bei der Umsetzung, vor allem im Browser, hat es dann gewaltig gehakt. So sehr, dass Java im Browser inzwischen im Grunde tot ist.

Wie sieht es also mit der Sicherheit von WebAssembly (auch kurz „Wasm“ genannt) aus? Dazu schauen wir uns erst einmal an, was das überhaupt ist. Und zwar nur im Kontext von Webanwendungen und der Ausführung im Webbrowser, denn das ist der primäre Anwendungszweck. Dass WebAssembly auch in Nicht-Webumgebungen ausgeführt werden kann, ist laut den WebAssembly-Entwicklern zwar wünschenswert, aber kein zentrales Ziel der Entwicklung.

WebAssembly ganz einfach ...

Sehr vereinfacht gesagt ist WebAssembly ein Bytecode, der in einer Sandbox ausgeführt wird. Im Browser werden WebAssembly-Module in der JavaScript VM ausgeführt. Für den WebAssembly-Code gelten daher die gleichen Sicherheitsbeschränkungen wie für JavaScript-Code, insbesondere also die Same-Origin Policy. Hinzu kommt die zusätzliche Einschränkung, dass WebAssembly-Code nicht direkt auf das DOM der Seite zugreifen kann. Für Änderungen an der dargestellten Seite oder das Abfragen von Informationen daraus müssen JavaScript-Funktionen verwendet werden. Auch können die WebAssembly-Module nur dann auf die Hardware oder das Dateisystem zugreifen, wenn der Benutzer das in der Browserkonfiguration explizit erlaubt.

... und etwas formaler

Formal betrachtet ist WebAssembly die Spezifikation einer Instruction Set Architecture und eines Dateiformats. Die Instruction Set Architecture beschreibt einen (virtuellen) Rechner, und das Dateiformat legt den Aufbau von WebAssembly-Modulen fest. Der Browser lädt den WebAssembly-Binärcode in Form von Modulen und führt ihn aus.

Das ähnelt den bekannten Java-Applets, die zu Java-Bytecode kompiliert und in der Java Vi...

PHP Magazin
Neue Besen kehren gut, sagt man. Aber sind sie auch sicher?

Wasm - Ist das sicher oder kann das weg?

Schon wieder eine neue Technologie für aktive Inhalte - muss das denn wirklich sein? Als hätten wir mit Flash und Java nicht schon genug Ärger gehabt. Beides wurde wahrscheinlich öfter für Angriffe als für wirklich nützliche Anwendungen verwendet.

Carsten Eilers


Jedenfalls wenn man mal von Spielen und in der Websteinzeit dem Wiedergeben von Videos durch Flash absieht. HTML5 und die dazugehörenden JavaScript APIs decken doch schon alle möglichen und unmöglichen Anwendungsfälle ab. Wieso also noch was Neues erfinden? Vor allem, wo doch jede neue Funktionalität immer auch die Angriffsfläche erhöht, die man doch eigentlich möglichst klein halten möchte. Die Antwort ist ganz einfach: Wieso nicht? Vielleicht ist das Neue ja besser als alles Alte.

Wichtig ist natürlich vor allem, dass es sicher ist. Nicht nur sicherer als Flash oder Java – das ist keine Kunst, so chronisch unsicher wie die sind. Sondern wirklich sicher, von Anfang an und ohne Kompromisse. Wobei Java in der Theorie auch sicher sein sollte, nur bei der Umsetzung, vor allem im Browser, hat es dann gewaltig gehakt. So sehr, dass Java im Browser inzwischen im Grunde tot ist.

Wie sieht es also mit der Sicherheit von WebAssembly (auch kurz „Wasm“ genannt) aus? Dazu schauen wir uns erst einmal an, was das überhaupt ist. Und zwar nur im Kontext von Webanwendungen und der Ausführung im Webbrowser, denn das ist der primäre Anwendungszweck. Dass WebAssembly auch in Nicht-Webumgebungen ausgeführt werden kann, ist laut den WebAssembly-Entwicklern zwar wünschenswert, aber kein zentrales Ziel der Entwicklung.

WebAssembly ganz einfach ...

Sehr vereinfacht gesagt ist WebAssembly ein Bytecode, der in einer Sandbox ausgeführt wird. Im Browser werden WebAssembly-Module in der JavaScript VM ausgeführt. Für den WebAssembly-Code gelten daher die gleichen Sicherheitsbeschränkungen wie für JavaScript-Code, insbesondere also die Same-Origin Policy. Hinzu kommt die zusätzliche Einschränkung, dass WebAssembly-Code nicht direkt auf das DOM der Seite zugreifen kann. Für Änderungen an der dargestellten Seite oder das Abfragen von Informationen daraus müssen JavaScript-Funktionen verwendet werden. Auch können die WebAssembly-Module nur dann auf die Hardware oder das Dateisystem zugreifen, wenn der Benutzer das in der Browserkonfiguration explizit erlaubt.

... und etwas formaler

Formal betrachtet ist WebAssembly die Spezifikation einer Instruction Set Architecture und eines Dateiformats. Die Instruction Set Architecture beschreibt einen (virtuellen) Rechner, und das Dateiformat legt den Aufbau von WebAssembly-Modulen fest. Der Browser lädt den WebAssembly-Binärcode in Form von Modulen und führt ihn aus.

Das ähnelt den bekannten Java-Applets, die zu Java-Bytecode kompiliert und in der Java Vi...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang