WebAssembly für Anfänger, Teil 3: Wie WASM-Portabilität und -Sicherheit funktionieren

Veröffentlicht: 2023-01-05

Sehen Sie sich in diesem Anfängerleitfaden an, wie Portabilitäts- und Sicherheitsmodelle von WebAssembly (WASM) funktionieren.

Beides sind Themen für fortgeschrittene WebAssembly (WASM). Wir empfehlen Ihnen, die beiden vorherigen Themen in unserer WebAssembly-Reihe für Anfänger zu lesen.

  • WebAssembly für Anfänger – Teil 1: Eine Einführung in WASM
  • WebAssembly für Anfänger – Teil 2: Ziele, Schlüsselkonzepte und Anwendungsfälle

Lass uns anfangen.

WebAssembly-Portabilität

Die Portabilität von WebAssembly macht es bereit für das Web. Tatsächlich können Sie WASM als tragbare Sandbox-Plattform definieren.

Darüber hinaus ermöglicht es sein Binärformat, auf verschiedenen Befehlssatzarchitekturen und Betriebssystemen ausgeführt zu werden. Das bedeutet, dass Sie WASM nicht nur im Web, sondern auch außerhalb des Webs verwenden können.

Um die WASM-Portabilität zu verstehen, werden wir Folgendes besprechen:

  • Lokale, begrenzte und nicht deterministische Umgebung.
  • Spezifische Merkmale der Ausführungsumgebung
  • WASM Web- und Nicht-Web-Portabilität

Lokal, begrenzt und nicht deterministisch

WASM benötigt eine effiziente Ausführung und geeignete Umgebungen, die lokal, begrenzt und nicht deterministisch sind. Nichtdeterminismus ist eine Berechnung, die angibt, dass ein Algorithmus/Compiler/eine Umgebung selbst für dieselbe Eingabe unterschiedliche Verhaltensweisen oder Ergebnisse ausgibt. Es ist das Gegenteil eines deterministischen Algorithmus.

Die beiden anderen Aspekte, begrenzt und lokal , sind mit nichtdeterministischer Ausführung verbunden. Damit die nichtdeterministische Ausführung funktioniert, benötigen Sie gut definierte Anwendungsfälle, die „ begrenzt “ sind.

Außerdem sind diese Hinrichtungen „ lokal “ ohne Wirkung außerhalb der Umgebung. Lesen Sie ihren offiziellen Nichtdeterminismus im WebAssembly-Dokument, um mehr darüber zu erfahren.

Spezifische Merkmale der Ausführungsumgebung

Um WebAssembly portabel zu machen, wird davon ausgegangen, dass die Ausführungsumgebung die folgenden Eigenschaften bietet:

  • Bytespeicher-Granularitätsadressierbarkeit und 8-Bit-Bytes.
  • 32-Bit-Zweierkomplement-Ganzzahlen mit Vorzeichen. Optional 64 Bit.
  • Software-Emulation ist über nicht ausgerichtete Speicherzugriffe oder zuverlässiges Trapping möglich.
  • Unterstützung für 32-Bit- und 64-Bit-Gleitkommazahlen gemäß Definition in IEEE 754-2008.
  • Garantiert die Ausführung aller Threads mit Vorwärtsfortschritt.
  • Für den 64-Bit-Zugriff sollte wasm64 lock-freie atomare Speicheroperatoren bereitstellen.
  • Die lock-freien atomaren Speicheroperatoren umfassen 8-, 16- und 32-Bit-Zugriffe.
  • wasm64 unterstützt linearen Speicher von mehr als 4 GiB mit 64-Bit-Indizes oder -Zeigern.
  • Little-Endian-Byte-Reihenfolge.

Alle gängigen Browser, einschließlich Chrome, Edge, Firefox und WebKit, unterstützen alle diese Umgebungsanforderungen.

Darüber hinaus entwickelt sich WebAssembly rasant weiter. Die WASM Community Group und die W3C WebAssembly Working Group arbeiten an ihrer Standardisierung. Das bedeutet, dass sich jede dieser Anforderungen in Zukunft ändern kann.

WASM Web- und Nicht-Web-Portabilität

Der Hauptzweck von WebAssembly besteht darin, Portabilität und native Leistung im Web und außerhalb des Webs bereitzustellen. In diesem Abschnitt sehen wir uns an, wie WASM dies erreicht.

#1. Web-Einbettung

WASM lässt sich gut in das Webökosystem integrieren, einschließlich des Sicherheitsmodells des Webs, der Webportabilität und der Web-APIs. Darüber hinaus muss es genügend Raum für die spätere kreative Entwicklung haben (lesen Sie WebAssembly für Anfänger – Teil 2, um seine Ziele zu verstehen).

Wie erreicht WASM also die Kompatibilität mit dem Web? Es verwendet JavaScript-APIs, die es Entwicklern ermöglichen, JavaScript für die einfache Kompilierung von WebAssembly-Modulen zu verwenden. Es kümmert sich auch um das Speichern und Abrufen von Compilermodulen, das Verwalten von Importen aus Compilermodulen, das Verwalten des Speichers und so weiter.

Um mehr darüber zu erfahren, wie WASM Webkompatibilität auf hohem Niveau erreicht, lesen Sie Folgendes: Webeinbettung – WebAssembly.

#2. Nicht-Web-Einbettung

Wie bereits erwähnt, funktioniert WASM auch mit Nicht-Web-Umgebungen. Als Entwickler oder Unternehmen können Sie Hochleistungsanwendungen erstellen oder Abschnitte Ihrer App schreiben, die eine Leistungsoptimierung erfordern. Sie können es beispielsweise auf IoT-Geräten, Rechenzentrumsservern und Desktop-/mobilen Apps verwenden.

Da Nicht-Webanwendungen keine Web-APIs verwenden können, verlassen sie sich auf die dynamische Verknüpfung von WASM. Sie müssen auch Feature-Tests verwenden, einen Softwareentwicklungsprozess, der die verschiedenen Variationen von Features testet, um zu sehen, was für die Benutzererfahrung am besten ist. Darüber hinaus können Entwickler JavaScript-VMs verwenden, um die Nicht-Web-Einbettung zu vereinfachen oder ihre Apps ohne sie zu entwickeln.

Um mehr zu erfahren, lesen Sie Nicht-Web-Einbettungen – WebAssembly.

WebAssembly-Sicherheit

WebAssembly ist eine Lösung im Binärformat, die eine native Leistung bietet. Es funktioniert hervorragend im Web, kann aber auch für Nicht-Web-Einbettungen optimiert werden. Dadurch wird WASM für Dienste, Lösungen und Prozesse weithin verfügbar. Dies bedeutet jedoch mehr Sicherheitsherausforderungen.

WASM-Sicherheitsherausforderungen und -risiken

Obwohl WebAssembly als sicher und effizient gilt, birgt es mehrere Sicherheitsrisiken, darunter:

  • WebAssembly-Sandbox
  • Speicherverwaltung
  • Code-Verschleierung
  • Integritätsprüfungen

#1. WebAssembly-Sandbox

WASM wird genau wie JavaScript im Webbrowser ausgeführt. Es verwendet dieselbe virtuelle Maschine (VM) wie JavaScript. Die Sandbox bietet effektiv eine sichere Ausführungsumgebung und behindert, was unter der Haube läuft.

Wenn also der JavaScript-/WebAssembly-Code bösartigen Code enthält, ist er schwer zu erkennen, da es sich um eine Blackbox handelt. Außerdem liegt der WASM-Code im betriebsbereiten Binärformat vor; es läuft schneller, was es Antivirus-Lösungen erschwert, nach bösartigem Code zu suchen. Der Code kann beispielsweise unerwünschte Werbung oder die Möglichkeit enthalten, Benutzer auf unerwünschte Malware-Websites umzuleiten.

Browser-Krypto-Mining-WASM infizieren

Darüber hinaus bedeutet die übermäßige Abhängigkeit von WebAssembly von JavaScript zur Ausführung im Web auch, dass es JavaScript-Schwachstellen erbt. Aus diesem Grund müssen Sie als Entwickler beim Codieren von WASM die Sicherheitsvorkehrungen und -maßnahmen von JavaScript befolgen.

#2. Speicherverwaltung

Die Speicherverwaltung in WASM ist schwierig. Erstens greift es nicht direkt auf den physischen Speicher zu, wenn es innerhalb der VM ausgeführt wird. Aus diesem Grund verwendet es den Speicher des Hostcomputers.

Zweitens erfordert das Reinigen des Speichers in WASM einen expliziten Prozess, während sich JavaScript im Vergleich dazu selbst bereinigt.

Wenn eine WASM-Funktion eine Ausgabe an JavaScript zurückgibt, gibt sie außerdem einen Zeiger auf die Position innerhalb des zugewiesenen WASM-Speicherbereichs zurück. Wenn also der deklarierte Speicher voll wird, kann das WASM-Programm abstürzen und die Erfahrung des Benutzers ruinieren. Um dies zu verhindern, müssen Programmierer Desinfektionsmittel verwenden, um ihren Code zu debuggen, oder Toolchains wie emscripten verwenden.

Wasm-linearer-Speicher

#3. Code-Verschleierung

Durch die Sandbox-Ausführung von WASM wird der Code verschleiert. Darüber hinaus ist das WASM-Binärformat auch nicht für Menschen lesbar, was das Reverse Engineering erschwert, das zum Identifizieren von bösartigem Code erforderlich ist.

Diese erschweren das Debuggen von WebAssembly-Code, da kein für Menschen lesbares Format vorhanden ist. Dies öffnet viele Sicherheitslücken, einschließlich der Fähigkeit von Hackern, Code zu verbergen, der vertrauliche Informationen stiehlt, oder Code-Injektionen durchzuführen, um die Host-Maschine zu übernehmen.

#4. Integritätsprüfungen

Alle über das Internet übertragenen Daten sind anfällig für Datenmanipulation. Beispielsweise können Hacker einen Man-in-the-Middle-Angriff durchführen, um Datenwerte zu ändern. Dies ist ein Problem für WASM, da es keine ordnungsgemäße Möglichkeit zur Durchführung von Integritätsprüfungen bietet.

Es kann jedoch mit JavaScript zusammenarbeiten, um Integritätsprüfungen durchzuführen. Eine andere Möglichkeit, potenzielle Schwachstellen im WASM-Code zu identifizieren, ist die Verwendung von Integrationstools wie Jit. Es stellt sicher, dass der Code frei von böswilligen Akteuren ist und sich nicht auf Apps oder die umgebende Cloud-Infrastruktur auswirken kann.

Man-in-the-Middle-Angriff

Grundlegendes zum WASM-Sicherheitsmodell

WebAssembly nimmt Sicherheit ernst. Aus diesem Grund haben sie in den offiziellen WASM-Dokumenten erwähnt, dass ihr Sicherheitsmodell zwei wichtige Ziele verfolgt:

  1. Stellen Sie sicher, dass keine fehlerhaften oder schädlichen Module die Benutzer beeinträchtigen
  2. Stellen Sie sicher, dass Entwickler alle Sicherheitsrisiken mindern und sichere Anwendungen erstellen können, während Sie sicherstellen, dass Punkt 1 immer eingehalten wird.

Das WASM-Sicherheitsmodell weiß, dass WebAssembly-Apps unabhängig ausgeführt werden, ohne dass sie der Sandbox-Umgebung entkommen können. APIs können jedoch eine Möglichkeit eröffnen, die Hostumgebung anzugreifen.

Eine weitere fehlertolerante Technik umfasst die deterministische Ausführung von Apps mit begrenzten Erwartungen. Durch Sicherstellen beider Bedingungen gelten die meisten App-Ausführungen als sicher.

Um die Sicherheit zu verbessern, sollten Entwickler die Richtlinie des gleichen Ursprungs für den Informationsfluss durchsetzen. Wenn Sie für Nicht-Web entwickeln, müssen Sie das POSIX-Sicherheitsmodell verwenden. Wenn Sie mehr über das Sicherheitsmodell lesen möchten, lesen Sie: Sicherheit – WebAssembly.

Die WebAssembly-Systemschnittstelle (WASI)

WASI (The WebAssembly System Interface) spielt auch eine entscheidende Rolle bei der Nicht-Web-Einbettung von WASM, da es die Sicherheit verbessert. Es ist eine modulare Systemschnittstelle, die aufregende Sicherheitseigenschaften und Portabilität bietet.

Tatsächlich ist es jetzt Teil der WebAssembly System Interface Subgroup Charter und damit standardisiert. Aufgrund von WASI ist WASM in verschiedenen Edge-/Server-Computing-Bereichen weit verbreitet. Außerdem vereinfacht WASI die Sicherheit beim Wechsel von einer Web-Einbettungsumgebung zu einer Nicht-Web-Einbettung.

Letzte Worte

Portabilität und Sicherheit von WebAssembly sind zwei große Themen. In Teil 3 des WebAssembly für Anfänger haben wir versucht, es zu vereinfachen und aufzuschlüsseln, insbesondere für Anfänger.

Als Nächstes können Sie sich JavaScript-Spickzettel für Entwickler und Lernende ansehen.