In diesem Leitfaden für Einsteiger beleuchten wir die Funktionsweise von Portabilitäts- und Sicherheitsmodellen bei WebAssembly (WASM).
Beide Themen sind für fortgeschrittene WebAssembly-Kenner relevant. Wir empfehlen Ihnen daher, zunächst die vorherigen Teile unserer WebAssembly-Reihe für Anfänger zu studieren.
Legen wir los!
WebAssembly Portabilität
Die Portabilität von WebAssembly ist ein Schlüsselfaktor für seine Eignung für das Web. WASM kann als eine Art portable Sandbox-Plattform betrachtet werden.
Sein Binärformat erlaubt die Ausführung auf verschiedenen Befehlssatzarchitekturen und Betriebssystemen. Das bedeutet, dass WASM nicht nur im Web, sondern auch außerhalb davon eingesetzt werden kann.
Um die Portabilität von WASM besser zu verstehen, werden wir folgende Punkte erörtern:
- Lokale, begrenzte und nichtdeterministische Umgebung.
- Besondere Merkmale der Ausführungsumgebung
- WASM Portabilität im Web und außerhalb
Lokal, begrenzt und nichtdeterministisch
WASM erfordert eine effiziente Ausführung und geeignete Umgebungen, die lokal, begrenzt und nichtdeterministisch sind. Nichtdeterminismus bezeichnet in der Informatik, dass ein Algorithmus, Compiler oder eine Umgebung selbst bei identischen Eingaben unterschiedliche Ergebnisse oder Verhaltensweisen zeigen kann. Dies steht im Gegensatz zu deterministischen Algorithmen.
Die beiden anderen Aspekte, „begrenzt“ und „lokal“, stehen in Verbindung mit der nichtdeterministischen Ausführung. Damit nichtdeterministische Ausführung funktioniert, sind klar definierte Anwendungsfälle erforderlich, die „begrenzt“ sind.
Zudem sind diese Ausführungen „lokal“, das heißt, ohne Auswirkungen außerhalb der Umgebung. Für eine genauere Erläuterung des Nichtdeterminismus lesen Sie das offizielle WebAssembly-Dokument.
Besondere Merkmale der Ausführungsumgebung
Damit WebAssembly portabel ist, wird von der Ausführungsumgebung erwartet, dass sie folgende Eigenschaften aufweist:
- Byte-Speicheradressierbarkeit mit 8-Bit-Bytes.
- 32-Bit-Zweierkomplement-Ganzzahlen mit Vorzeichen. Optional 64 Bit.
- Softwareemulation von nicht ausgerichteten Speicherzugriffen oder sicheres Trapping.
- Unterstützung für 32-Bit- und 64-Bit-Gleitkommazahlen gemäß IEEE 754-2008.
- Sicherstellung des Fortschritts aller Threads.
- Für 64-Bit-Zugriffe sollte wasm64 lock-freie atomare Speicheroperationen bereitstellen.
- Lock-freie atomare Speicheroperationen umfassen 8-, 16- und 32-Bit-Zugriffe.
- wasm64 unterstützt linearen Speicher über 4 GiB mit 64-Bit-Indizes oder -Pointern.
- Little-Endian-Byte-Reihenfolge.
Alle gängigen Browser, wie Chrome, Edge, Firefox und WebKit, unterstützen diese Umgebungsanforderungen.
WebAssembly entwickelt sich ständig weiter. Die WASM Community Group und die W3C WebAssembly Working Group arbeiten an der Standardisierung. Daher können sich einige dieser Anforderungen zukünftig ändern.
WASM Portabilität im Web und außerhalb
Das Hauptziel von WebAssembly ist die Bereitstellung von Portabilität und nativer Leistung sowohl im Web als auch außerhalb. Dieser Abschnitt erläutert, wie WASM dies erreicht.
#1. Web-Integration
WASM integriert sich gut in das Web-Ökosystem, einschließlich des Sicherheitsmodells des Webs, der Webportabilität und der Web-APIs. Es muss außerdem ausreichend Raum für zukünftige kreative Entwicklungen lassen (siehe WebAssembly für Anfänger – Teil 2, um die Ziele zu verstehen).
Wie erreicht WASM die Kompatibilität mit dem Web? Es nutzt JavaScript-APIs, die es Entwicklern erlauben, JavaScript für die einfache Kompilierung von WebAssembly-Modulen zu verwenden. Diese APIs kümmern sich um das Speichern und Abrufen von kompilierten Modulen, das Verwalten von Importen aus kompilierten Modulen und die Speicherverwaltung.
Erfahren Sie mehr über die Webkompatibilität von WASM: Web-Integration – WebAssembly.
#2. Integration außerhalb des Webs
Wie bereits erwähnt, funktioniert WASM auch in Nicht-Web-Umgebungen. Entwickler und Unternehmen können damit leistungsstarke Anwendungen entwickeln oder Teile ihrer Anwendungen schreiben, die eine Leistungsoptimierung erfordern. Beispiele sind IoT-Geräte, Rechenzentrumsserver und Desktop- oder mobile Apps.
Da Nicht-Web-Anwendungen keine Web-APIs verwenden können, ist WASM auf die dynamische Verknüpfung angewiesen. Außerdem ist Feature-Testing notwendig, ein Softwareentwicklungsprozess, der die verschiedenen Variationen von Features testet, um die beste Benutzererfahrung zu erzielen. Entwickler können JavaScript-VMs verwenden, um die Integration außerhalb des Webs zu vereinfachen oder ihre Apps ohne sie zu entwickeln.
Für mehr Informationen lesen Sie: Integration außerhalb des Webs – WebAssembly.
WebAssembly Sicherheit
WebAssembly ist eine Lösung im Binärformat, die native Leistung ermöglicht. Sie funktioniert gut im Web, kann aber auch für Nicht-Web-Integrationen optimiert werden. Dies macht WASM für eine Vielzahl von Diensten, Lösungen und Prozessen nutzbar. Es bedeutet aber auch erhöhte Sicherheitsanforderungen.
WASM Sicherheitsherausforderungen und -risiken
Obwohl WebAssembly als sicher und effizient gilt, birgt es verschiedene Sicherheitsrisiken, darunter:
- WebAssembly Sandbox
- Speicherverwaltung
- Code-Verschleierung
- Integritätsprüfungen
#1. WebAssembly Sandbox
WASM wird, wie JavaScript, im Webbrowser ausgeführt und verwendet die gleiche virtuelle Maschine (VM). Die Sandbox bietet eine sichere Ausführungsumgebung und verbirgt die inneren Abläufe.
Wenn also der JavaScript- oder WebAssembly-Code schädlichen Code enthält, ist es schwierig, diesen zu erkennen, da es sich um eine Blackbox handelt. Zudem liegt der WASM-Code im Binärformat vor, läuft schneller, was es Antiviren-Lösungen erschwert, nach Schadcode zu suchen. Dieser Code könnte zum Beispiel unerwünschte Werbung enthalten oder Benutzer auf Malware-Websites umleiten.
Die starke Abhängigkeit von WebAssembly von JavaScript für die Ausführung im Web führt außerdem dazu, dass es JavaScript-Schwachstellen erbt. Daher müssen Entwickler beim Programmieren von WASM die Sicherheitsvorkehrungen und -maßnahmen von JavaScript befolgen.
#2. Speicherverwaltung
Die Speicherverwaltung in WASM ist eine Herausforderung. Erstens greift WASM nicht direkt auf den physischen Speicher zu, wenn es innerhalb der VM ausgeführt wird. Es nutzt den Speicher des Hostcomputers.
Zweitens ist ein expliziter Prozess erforderlich, um den Speicher in WASM zu bereinigen, während JavaScript dies selbstständig erledigt.
Wenn eine WASM-Funktion eine Ausgabe an JavaScript zurückgibt, gibt sie einen Pointer auf die Speicherposition im zugewiesenen WASM-Bereich zurück. Wenn der deklarierte Speicher also voll wird, kann das WASM-Programm abstürzen und die Benutzererfahrung beeinträchtigen. Um dies zu vermeiden, können Programmierer Desinfektionsmittel zur Fehlersuche nutzen oder Toolchains wie Emscripten verwenden.
#3. Code-Verschleierung
Die Sandbox-Ausführung von WASM verschleiert den Code. Zudem ist das WASM-Binärformat nicht menschenlesbar, was das Reverse Engineering, das zur Identifizierung von Schadcode notwendig ist, erschwert.
Dies erschwert die Fehlersuche in WebAssembly-Code, da kein menschenlesbares Format vorhanden ist. Dies öffnet Sicherheitslücken, zum Beispiel können Hacker Code verstecken, der sensible Informationen stiehlt, oder Code injizieren, um den Hostrechner zu übernehmen.
#4. Integritätsprüfungen
Alle über das Internet übertragenen Daten sind anfällig für Manipulation. Hacker könnten zum Beispiel einen Man-in-the-Middle-Angriff ausführen, um Daten zu verändern. Dies ist ein Problem für WASM, da es keine geeignete Möglichkeit bietet, Integritätsprüfungen durchzuführen.
Es kann jedoch mit JavaScript zusammenarbeiten, um Integritätsprüfungen durchzuführen. Eine andere Möglichkeit, potenzielle Schwachstellen im WASM-Code zu erkennen, ist der Einsatz von Integrationstools wie Jit. Dies hilft sicherzustellen, dass der Code frei von bösartigen Akteuren ist und sich nicht auf Anwendungen oder die umgebende Cloud-Infrastruktur auswirkt.
Das WASM-Sicherheitsmodell verstehen
WebAssembly nimmt Sicherheit ernst. Laut offiziellen WASM-Dokumenten verfolgt das Sicherheitsmodell zwei Hauptziele:
- Sicherstellen, dass fehlerhafte oder bösartige Module keine Auswirkungen auf die Nutzer haben.
- Sicherstellen, dass Entwickler alle Sicherheitsrisiken minimieren und sichere Anwendungen erstellen können, wobei Punkt 1 immer eingehalten wird.
Das WASM-Sicherheitsmodell beruht darauf, dass WebAssembly-Anwendungen unabhängig laufen und die Sandbox-Umgebung nicht verlassen können. APIs können jedoch eine Möglichkeit darstellen, die Hostumgebung anzugreifen.
Eine weitere fehlertolerante Technik ist die deterministische Ausführung von Anwendungen mit begrenzten Erwartungen. Werden diese beiden Bedingungen erfüllt, gelten die meisten App-Ausführungen als sicher.
Zur Verbesserung der Sicherheit sollten Entwickler die Same-Origin-Richtlinie für den Informationsfluss beachten. Für Nicht-Web-Entwicklungen ist das POSIX-Sicherheitsmodell zu verwenden. Weitere Informationen zum Sicherheitsmodell finden Sie unter: Sicherheit – WebAssembly.
Die WebAssembly System Interface (WASI)
WASI (The WebAssembly System Interface) spielt auch eine wichtige Rolle bei der Nicht-Web-Integration von WASM, da es die Sicherheit erhöht. Es ist eine modulare Systemschnittstelle, die herausragende Sicherheitseigenschaften und Portabilität bietet.
WASI ist nun Teil der WebAssembly System Interface Subgroup Charter und damit standardisiert. WASI hat zur Verbreitung von WASM in verschiedenen Edge- und Server-Computing-Bereichen beigetragen. Es erleichtert außerdem die Sicherheit beim Wechsel von einer Web- zu einer Nicht-Web-Integration.
Schlussbemerkung
Portabilität und Sicherheit sind zwei große Themen bei WebAssembly. In Teil 3 der WebAssembly-Reihe für Anfänger haben wir versucht, diese besonders für Einsteiger zu vereinfachen.
Als nächstes empfehlen wir Ihnen, sich die JavaScript-Spickzettel für Entwickler und Lernende anzusehen.