Entwicklerrichtlinien und Sicherheitsrichtlinien

Simon Hangl

Demián Renzulli

Isolierte Web-Apps (IWAs) bieten ein Sicherheitsmodell, das Webanwendungen den Zugriff auf leistungsstarke Funktionen wie Direct Sockets und Controlled Frame ermöglicht, die im Standard-Web normalerweise eingeschränkt sind. Da IWAs in einer Umgebung mit hohem Vertrauen ausgeführt werden, müssen sie strenge Sicherheits- und Datenschutzrichtlinien einhalten. Diese Richtlinien sollen dafür sorgen, dass Nutzer geschützt bleiben und die Integrität der Browserumgebung gewahrt wird, wenn die Webplattform leistungsfähiger wird.

Das IWA-Vertrauensmodell

Das Herzstück der IWA-Plattform sind strenge technische Richtlinien, die Entwickler dazu zwingen, ein hohes Sicherheitsniveau aufrechtzuerhalten. Während Standard-Web-Apps auf einem flexiblen Berechtigungsmodell basieren, werden installierbare Web-Apps kryptografisch signiert und über Web Bundles bereitgestellt, was die Überprüfung ihrer Herkunft und Integrität ermöglicht.

Im Gegenzug für diese bestätigte Identität erhalten IWAs Zugriff auf privilegierte APIs. Um dieses Vertrauen aufrechtzuerhalten, müssen Entwickler einen sicherheitsorientierten Ansatz verfolgen und strengere Richtlinien einhalten, darunter eine robuste Content Security Policy (CSP) und Trusted Types, die die Sicherheit der Nutzer auch bei Verwendung leistungsstarker Funktionen gewährleisten. Das bedeutet:

• Transparenz:Nutzer sollten niemals von der Verwendung privilegierter APIs durch eine Anwendung überrascht werden.
• Prinzip der geringsten Berechtigung:Apps sollten nur die spezifischen Funktionen anfordern und verwenden, die für den angegebenen Zweck erforderlich sind.
• Statische Integrität:Die gesamte ausführbare Logik muss im App-Paket enthalten sein, um Sicherheitsprüfungen zu ermöglichen und das Sideloading von schädlichem Code zu verhindern.

IWAs bieten zwar einen robusten integrierten Schutz, z. B. durch eine strenge Content Security Policy (CSP), die die Ausführung externer Skripts verhindert. Technische Einschränkungen allein können jedoch nicht jedes Risiko mindern. Selbst in einer Umgebung mit hohem Vertrauen können bestimmte Implementierungsmuster oder Entwicklerentscheidungen versehentlich die Sicherheit oder den Datenschutz der Nutzer gefährden. In diesem Leitfaden werden diese eingeschränkten Szenarien und die Richtlinien für die Verwendung privilegierter APIs beschrieben.

Warum diese Richtlinien wichtig sind

Die Einhaltung dieser Richtlinien ist nicht nur eine Frage der Compliance, sondern auch eine Voraussetzung für den Aufbau eines nachhaltigen Ökosystems für fortschrittliche Webanwendungen. Wenn Sie diese Richtlinien einhalten, stellen Sie sicher, dass Ihre Anwendung

• Sicherheitsregressionen vermeiden:Durch die in sich geschlossene Logik werden Sicherheitslücken wie Cross-Site-Scripting (XSS) und die Ausführung von Remote-Code verhindert.
• Datenschutz für Nutzer:Sensible Daten und der Zugriff auf Hardware werden nur mit ausdrücklicher Nutzerabsicht und Transparenz gehandhabt.
• Sorgt für eine lange Lebensdauer der Plattform:Trägt dazu bei, die hohen Sicherheitsstandards aufrechtzuerhalten, die erforderlich sind, damit die IWA-Plattform ihre Funktionen weiter ausbauen kann.

Grundprinzipien

Transparenz und Nutzerabsicht

Die wichtigste Regel lautet: Überraschen Sie den Nutzer nicht. Das Verhalten Ihrer Anwendung muss mit dem angegebenen Zweck und den Erwartungen der Nutzer übereinstimmen.

• Im Rahmen bleiben: Implementieren Sie keine Funktionen, die über den klaren Zweck Ihrer Anwendung hinausgehen.
• Minimale API-Nutzung:Fordern Sie nur die spezifischen IWA-APIs an und verwenden Sie sie nur, die für die Hauptfunktion Ihrer App erforderlich sind.

Kein Sideloading von dynamischem Code

Das IWA-Sicherheitsmodell hängt davon ab, dass Administratoren oder der Browseranbieter alle ausführbaren Logiken überprüfen können. Daher muss Ihr IWA-Paket in sich geschlossen sein. Die Plattform erzwingt dies durch eine strenge Content Security Policy (CSP), die die stringbasierte Ausführung wie eval() und new Function() blockiert:

script-src 'self' 'wasm-unsafe-eval';
require-trusted-types-for 'script';

Der CSP erlaubt zwar, dass 'wasm-unsafe-eval' WebAssembly unterstützt, Sie dürfen jedoch nicht gegen den Geist dieser Sicherheitsgrenze verstoßen.

Strengstens verbotene Praktiken

• Versenden von Interpretern für Remote-Code:Sie dürfen keinen Code-Interpreter (z. B. Python oder Lua, kompiliert zu WASM) einbinden, um externe Skripts über privilegierten Netzwerkzugriff wie Direct Sockets herunterzuladen und auszuführen.
• Remote geladene Logik:Verwenden Sie keine Service Worker, um remote geladenen Code in den IWA-Ursprung einzubetten.
• Code im Vergleich zu Daten:Das Herunterladen von Daten wie JSON ist zulässig, das Herunterladen von Code, der interpretiert oder ausgeführt werden soll, stellt jedoch einen direkten Richtlinienverstoß dar.

Prinzip der geringsten Berechtigung

Verwenden Sie immer die API mit der geringsten Leistung, die für eine Aufgabe erforderlich ist. Privilegierte IWA-spezifische APIs dürfen niemals als Abkürzung verwendet werden, um die Sicherheitsbeschränkungen oder Nutzeraufforderungen von Standard-Web-APIs zu umgehen. In der folgenden Tabelle sind häufige Anwendungsfälle aufgeführt, die Ihnen bei der Entscheidung helfen, wann herkömmliche Web-APIs und wann IWA-spezifische Funktionen verwendet werden sollten:

API-spezifische Richtlinien

IWA-APIs bieten leistungsstarke Funktionen, die im Browser normalerweise eingeschränkt sind. Die allgemeine Empfehlung lautet, diese privilegierten Funktionen niemals so zu verwenden, dass Nutzer überrascht werden oder ihr Vertrauen und ihre Daten gefährdet werden.

Direct Sockets API

Die Direct Sockets API gewährt rohen TCP- und UDP-Zugriff, einschließlich Multicast- und lokaler Netzwerkzugriff.

Zulässig

• Unterstützung benutzerdefinierter Protokolle:Verbindung zu Remote-Servern herstellen, die benutzerdefinierte Protokolle verwenden, für die derzeit keine Web-API auf höherer Ebene vorhanden ist.
• Back-End-Dienste verwalten:Verbindung zu einem vordefinierten, fest codierten Server herstellen, der speziell für die Back-End-Dienste Ihrer Anwendung verwendet wird.
• Erkennen wichtiger Hardware:Zugriff auf das lokale Netzwerk oder Verwendung von Multicast zum Erkennen bestimmter, zugehöriger Hardware, die für die Funktion der App erforderlich ist (z. B. eine Videobearbeitungs-App, die ein NAS-Gerät findet).

Nicht zulässig

• Nutzer überraschen:Netzwerkzugriff implementieren, der nicht eindeutig durch die primäre Funktion der App gerechtfertigt ist, z. B. wenn ein Texteditor mit Geräten im lokalen Netzwerk kommuniziert.
• Beliebiges Scannen von Netzwerken:Durchführung umfassender Scans des lokalen Netzwerks des Nutzers (z. B. Port-Scanning von 192.168.1.0/24), um ein Profil des Nutzers zu erstellen oder nicht verwandte Geräte zu ermitteln.
• Angriff auf lokale Geräte: Der Versuch, andere Geräte im lokalen Netzwerk zu untersuchen, neu zu konfigurieren oder anzugreifen, ist streng verboten.

Controlled Frame API

Das Element <controlledframe> ermöglicht das Einbetten und Ändern von ursprungsübergreifenden Inhalten, einschließlich Skripteinschleusung und Headeränderung.

Zulässig

• Benutzeroberflächen optimieren:Einbettung eines Drittanbieterdienstes und Einfügen von CSS, um irrelevante UI-Elemente auszublenden oder eine einheitlichere Darstellung zu ermöglichen.
• Vermittlung sicherer Kommunikation:Die Funktion dient als Gatekeeper, indem sie Anfragen von der eingebetteten Seite mit postMessage empfängt und nur bereinigte, erforderliche Daten zurückgibt, die über privilegierte APIs abgerufen wurden.

Nicht zulässig

• Stehlen von Anmeldedaten:Es werden Skripts eingefügt, um Passwörter, Sitzungscookies oder andere vertrauliche Nutzerdaten aus den eingebetteten Inhalten zu erfassen.
• Verstoß gegen die Nutzungsbedingungen: Eingebettete Plattformen werden so verändert, dass gegen die Nutzungsbedingungen verstoßen wird, z. B. durch programmatisches Klicken auf Anzeigen oder unbefugtes Scraping.
• Proxying von privilegiertem Zugriff:Erstellen eines Pass-throughs, der nicht vertrauenswürdigen, eingebetteten Inhalten direkten oder unkontrollierten Zugriff auf eine privilegierte IWA-API ermöglicht.
• Implementierung unkontrollierter KI:Aktionen im Namen eines angemeldeten Nutzers über KI ohne spezifische, transparente Anwendungsfallbeschränkungen ausführen.

Uneingeschränkte Bildschirmaufzeichnung

Ermöglicht Bildschirmaufnahmen ohne die wiederholten Aufforderungen zur Nutzerberechtigung, die im Standardweb auftreten.

Zulässig

• Bereitstellung von Hauptfunktionen:Die Bildschirmaufzeichnung ist ein offensichtlicher Teil des Dienstes der App, z. B. bei Funktionen für virtuelle Meetings oder Tutorialaufzeichnungen.
• Nutzer informieren:Nutzer müssen vor der Nutzung der App klar darüber informiert werden, dass Aufzeichnungen erfolgen können.

Nicht zulässig

• Heimliche Aufzeichnung:Der Bildschirm des Nutzers wird ohne dessen ausdrückliche, vorherige Kenntnis und Einwilligung aufgezeichnet.
• Verstoß gegen Datenschutzbestimmungen:Aufzeichnen von Inhalten, die gegen lokale oder internationale Datenschutzgesetze verstoßen.

Uneingeschränktes WebUSB

Uneingeschränkte WebUSB umgeht die standardmäßige WebUSB-Sperrliste, um eine Interaktion auf niedriger Ebene mit Geräten zu ermöglichen.

Zulässig

• Unterstützung proprietärer Hardware:Interaktion mit spezieller oder älterer Hardware, für die keine Web-API auf hoher Ebene vorhanden ist, z. B. industrielle Controller.

Jetzt erlaubt

• Umgehen von dedizierten APIs:WebUSB für Geräte verwenden, die eine spezifischere, eingeschränkte API haben, z. B. Smartcards (Smart Card API verwenden) oder externer Speicher (File System Access API verwenden).

Fensterverwaltung (window.open und window.focus)

IWAs können Pop-ups und Fokusfenster erstellen, ohne dass die vom Standardweb erforderliche Nutzeraktion erforderlich ist.

Zulässig

• Benachrichtigung über den Abschluss von Aufgaben:Das App-Fenster wird in den Vordergrund gerückt, wenn eine wichtige, vom Nutzer initiierte Hintergrundaufgabe wie das Rendern eines Videos abgeschlossen ist.

Nicht zulässig

• Spamming:Den Nutzer mit mehreren unerwünschten Fenstern überhäufen.
• Phishing:Öffnen von Fenstern, die Systemdialogfelder imitieren oder den Nutzer täuschen sollen.
• Fokusdiebstahl:Nutzer werden durch das Stehlen des Fokus von anderen Anwendungen für nicht kritische Ereignisse unterbrochen.

Fazit

Die Sicherheitsarchitektur von Isolated Web Apps wurde entwickelt, um Entwickler zu unterstützen und gleichzeitig eine Umgebung mit hohem Vertrauen für Nutzer zu schaffen. Wenn Sie diese Richtlinien einhalten, sorgen Sie dafür, dass Ihre Anwendung ein verantwortungsbewusster Teil des IWA-Ökosystems bleibt. Die wichtigsten Erkenntnisse aus diesem Leitfaden:

• Transparenz hat Priorität:Das Verhalten Ihrer Anwendung sollte immer mit dem angegebenen Zweck übereinstimmen. Implementieren Sie niemals Funktionen, die den Nutzer überraschen oder täuschen.
• Paketintegrität erzwingen:Die gesamte ausführbare Logik muss in Ihrem IWA-Bundle enthalten sein, damit eine statische Überprüfung möglich ist. Das Umgehen des Sicherheitsmodells durch dynamisches Sideloading von Code oder Remote-Interpreter ist streng verboten.
• Prinzip der geringsten Berechtigung einhalten:Wählen Sie für eine bestimmte Aufgabe immer die am stärksten eingeschränkte verfügbare API aus. Privilegierte IWA-APIs sollten nur verwendet werden, wenn Standard-Web-APIs für die Hauptfunktion der Anwendung nicht ausreichen.
• Als Gatekeeper fungieren:Wenn Sie leistungsstarke Tools wie <controlledframe> verwenden, muss Ihre IWA als sicherer Vermittler und nicht als transparenter Proxy für nicht vertrauenswürdige Inhalte fungieren.

Bevor Sie Ihre IWA veröffentlichen, sollten Sie Ihre Implementierung noch einmal überprüfen und sich Folgendes fragen:

1. Verwende ich die einfachste und am stärksten eingeschränkte API, die für diese Aufgabe möglich ist?
2. Wäre ein Nutzer überrascht oder würde er sich betrogen fühlen, wenn er wüsste, was meine App tut?

Wenn die Antwort auf die erste Frage „Nein“ oder die Antwort auf die zweite Frage „Ja“ lautet, verstößt Ihre Anwendung wahrscheinlich gegen die Sicherheitsrichtlinien für IWA und wird möglicherweise entfernt.