Tauri-Fallstricke: 5 häufige Sicherheitsfehlkonfigurationen, die standardmäßig ausgeliefert werden

Ein Sicherheitsmodell ist nur so stark wie seine Standardeinstellungen. Tauri positioniert sich als sicherheitsbewusste Alternative zu Electron für die Entwicklung von Desktop-Anwendungen. Die Architektur teilt das Vertrauen zwischen einem Rust-Backend („Core“) und einem webbasierten Frontend („Renderer“); eine IPC-Schicht vermittelt den Zugriff.

Auf dem Papier ist das eine deutliche Verbesserung gegenüber dem früheren Modell von Electron, bei dem Node.js direkt im Renderer-Prozess ausgeführt wurde. (Heutzutage sind im Electron-Renderer allerdings standardmäßig bereits Context Isolation und Sandboxing aktiviert, sodass nur der Hauptprozess direkten Zugriff auf Node.js hat.) Im Vergleich zu Electron kann Tauri außerdem schlanker sein und bietet den Vorteil, dass sich mehrere Backend-Frameworks einfach integrieren lassen, um eine funktionsfähige Desktop-App zu erstellen.

Bei der Untersuchung der Konfigurationsmöglichkeiten von Tauri haben wir fünf häufige Fehlkonfigurationen identifiziert. Einige davon sind Standardeinstellungen oder finden sich in offiziellen Beispielen. Sie können die Sicherheitsgarantien des Frameworks unbemerkt aushebeln.

1. Wildcard im Asset-Protokoll: Wenn „/**/*“ die gesamte Festplatte umfasst

Das Asset-Protokoll in Tauri ermöglicht es Ihrem Frontend, lokale Dateien zu laden. Es ist nützlich, um Bilder darzustellen, lokale Daten zu laden oder statische Inhalte bereitzustellen. Problematisch wird es, wenn der Geltungsbereich mit einer Wildcard wie /**/* konfiguriert ist:

// src-tauri/tauri.conf.json
{
  "security": {
    "assetProtocol": {
      "enable": true,
      "scope": ["/**/*"]
    }
  }
}

Mit dieser Konfiguration kann beliebiges JavaScript in jedem Renderer-Fenster fetch("asset://localhost/etc/passwd") aufrufen und beliebige Dateien lesen, auf die der App-Prozess zugreifen kann. Eine Nutzeraktion, ein Bestätigungsdialog oder eine zusätzliche Berechtigungsprüfung sind nicht erforderlich.

Die Bedrohung geht über Ihren eigenen Code hinaus. Eine einzige XSS-Schwachstelle, eine kompromittierte npm-Abhängigkeit oder sogar ein über eine WebView eingeschleustes bösartiges Skript erhält Lesezugriff auf das lokale Dateisystem. Damit wird der Renderer praktisch zu einem Tool, mit dem sich lokale Dateien exfiltrieren lassen.

Was Sie tun sollten: Beschränken Sie das Asset-Protokoll auf bestimmte Verzeichnisse, die Ihre App tatsächlich benötigt. Verwenden Sie /**/* niemals in der Produktion. Wenn Sie das Asset-Protokoll nicht benötigen, deaktivieren Sie es vollständig.

2. Ein leerer Command-Geltungsbereich erlaubt alles

Das Berechtigungssystem von Tauri ermöglicht es Entwicklern, Command-Geltungsbereiche festzulegen und so einzuschränken, welche Eingaben akzeptiert werden. Ist für einen Command jedoch keine ACL konfiguriert, gibt der Code einen leeren CommandScope zurück, statt den Zugriff zu verweigern.

Das ist kontraintuitiv. Entwickler könnten vernünftigerweise erwarten, dass ein nicht konfigurierter Command standardmäßig alle Vorgänge verweigert (eine „Deny-by-default“-Sicherheitsstrategie). Stattdessen gibt die Methode matches() bei einem leeren Geltungsbereich für alle Eingaben true zurück.

// Developer expects this to be restrictive, but it allows everything
fn handle_command(scope: CommandScope<MyArgs>) {
    if scope.matches(&user_input) {
        // This always passes when scope is empty
        execute(user_input);
    }
}

Um tatsächlich ein Deny-by-default-Verhalten umzusetzen, müssen Entwickler manuell scope.allows().is_empty() prüfen und diesen Fall selbst behandeln.

In Verbindung mit Fallstrick Nr. 1 bedeutet das: Entwickler, die keine Geltungsbereiche explizit für ihre Commands konfiguriert haben, legen möglicherweise unwissentlich weitreichende Zugriffsrechte für jedes Renderer-Skript offen.

Was Sie tun sollten: Definieren Sie für jeden von Ihrer App bereitgestellten Command explizite zulässige Geltungsbereiche. Betrachten Sie leere Geltungsbereiche als Sicherheitsfehler. Erwägen Sie, die Prüfungen der Geltungsbereiche mit einer Hilfsfunktion zu kapseln, die eine Deny-by-default-Logik erzwingt.

3. Prototype Pollution durch nicht eingefrorene Objekte

Standardmäßig friert Tauri Object.prototype im Renderer-Kontext nicht ein. Die Option freezePrototype ist verfügbar, hat aber standardmäßig den Wert false.

Das ist relevant, weil der IPC-Mechanismus von Tauri über JavaScript läuft. Gelingt es einem Angreifer, eine Prototype Pollution zu erreichen (eine gut dokumentierte Angriffsklasse in JavaScript), kann er IPC-Aufrufe möglicherweise kapern, indem er Prototypen verändert, auf die die Tauri-Bridge angewiesen ist.

// tauri.conf.json — not enabled by default
{
  "app": {
    "security": {
      "freezePrototype": true
    }
  }
}

Prototype Pollution ist ein bekanntes Risiko in Webanwendungen. Im Kontext einer Desktop-App mit IPC-Zugriff auf das lokale System steigt die Auswirkung jedoch erheblich. Ein manipulierter Prototyp könnte IPC-Aufrufe umleiten, Command-Argumente ändern oder Antworten abfangen.

Was Sie tun sollten: Setzen Sie in Ihrer Tauri-Konfiguration freezePrototype: true. Diese Änderung umfasst nur eine Zeile und wirkt sich kaum auf legitimen Code aus.

4. Wildcard bei den Window-Capabilities

Mit dem Capability-System von Tauri können Entwickler bestimmten Fenstern Berechtigungen zuweisen. Eine Wildcard für die Fenster-ID gewährt die Capability jedoch jedem Fenster der Anwendung:

{
  "identifier": "my-capability",
  "windows": ["*"],
  "permissions": ["fs:allow-read-text-file"]
}

Dieses Muster gilt für alle Fenster, auch für dynamisch erstellte, neue Browserfenster oder Fenster, die ein bösartiges Skript öffnen könnte. Wird ein Fenster kompromittiert, muss der Angreifer nicht auf andere Fenster übergreifen, da dort bereits dieselben Berechtigungen gelten.

In der Praxis wurde dies bei einer Tauri-basierten App demonstriert, die Fenstern übermäßig weitreichende Berechtigungen gewährte und so das Containment-Modell schwächte, das die Capabilities eigentlich bieten sollen.

Was Sie tun sollten: Geben Sie Fenster-IDs immer explizit an. Prüfen Sie Ihre Capability-Konfiguration, um sicherzustellen, dass Berechtigungen auf die kleinstmögliche Anzahl der tatsächlich benötigten Fenster beschränkt sind.

5. Zu permissive Standardnavigation

Das Standardverhalten der Navigation in Tauri erlaubt der WebView, beliebige URLs aufzurufen. Eine integrierte Allowlist gibt es nicht. Entwickler müssen selbst explizite Navigationsbeschränkungen implementieren.

Für sich genommen stellt dies ein mittleres Risiko dar: Ein XSS-Angriff könnte die WebView auf eine Phishing-Website umleiten oder Downloads auslösen. In Kombination mit der Wildcard bei den Window-Capabilities (Fallstrick Nr. 4) und schwachen IPC-Ursprungsbeschränkungen wird daraus jedoch ein Angriffsvektor zur Rechteausweitung.

So läuft die Angriffskette ab: Ein Angreifer navigiert ein privilegiertes Fenster zu einem von ihm kontrollierten Ursprung und ruft dann aus diesem Kontext Tauri-IPC-Commands auf. Verwendet die Window-Capability "*", erhält der Ursprung des Angreifers alle Berechtigungen, die dieser Capability zugewiesen sind.

Was Sie tun sollten: Implementieren Sie einen Navigations-Handler, der zulässige Ursprünge einschränkt. Erlauben Sie die Navigation nur zu Domains, die Ihre Anwendung ausdrücklich laden muss.

Die kumulative Wirkung

Jedes dieser Probleme ist einzeln dokumentiert; für einige gibt es sogar zugehörige CVEs, etwa CVE-2024-35222 für die Umgehung der IPC-Zugriffskontrolle und CVE-2022-39215 für die Umgehung von Geltungsbereichen über Symlinks. Das eigentliche Risiko entsteht jedoch durch ihr Zusammenspiel.

Eine einzige XSS-Schwachstelle in einer Tauri-App mit Standardkonfiguration könnte mehrere Probleme verketten: nicht eingefrorene Prototypen zum Kapern von IPC, Wildcard-Geltungsbereiche für den Zugriff auf beliebige Commands, Wildcards im Asset-Protokoll zum Auslesen des Dateisystems und eine permissive Navigation zum Exfiltrieren von Daten an einen vom Angreifer kontrollierten Ursprung.

Das Sicherheitsmodell von Tauri ähnelt in seiner Architektur dem von Electron. Doch eine Architektur allein sorgt nicht für sichere Software. Entscheidend sind die Standardeinstellungen – und derzeit stehen einige davon bei Tauri den Sicherheitsgarantien entgegen, die das Framework eigentlich bieten soll.

Empfohlene Maßnahmen

1. Prüfen Sie Ihre tauri.conf.json und Capability-Dateien anhand aller oben aufgeführten Fallstricke

2. Setzen Sie freezePrototype: true

3. Ersetzen Sie alle Wildcard-Geltungsbereiche (/**/*, *) durch explizite Pfade und Fenster-IDs

4. Implementieren Sie eine Navigations-Allowlist

5. Fügen Sie jedem bereitgestellten Command explizite Zulassungs- und Verweigerungsbereiche hinzu

6. Verwenden Sie Snyk, um die Rust- und JavaScript-Abhängigkeiten Ihrer Tauri-Anwendung auf bekannte Schwachstellen zu untersuchen

Sind Ihre Desktop-Apps vor solchen verketteten Fehlkonfigurationen geschützt, die einen einzelnen Fehler zur vollständigen Kompromittierung des Systems ausweiten können? Laden Sie das Whitepaper The AI Security Crisis in Your Python Environment herunter, um zu erfahren, wie moderne Teams die KI-gestützte Entwicklung über verschiedene Programmiersprachen und Frameworks hinweg absichern.