Austausch von ServiceWorker absichern

[Michael_K]

Hallo Rolf,

Du schreibst mal Serviceworker und mal Webworker. Das sind zwei verschiedene Dinge. Ein Webworker dient zur asynchronen Verarbeitung von Aufgaben, und ein Serviceworker zur Unterstützung einer Seite im offline-Betrieb, indem die offline benötigten Ressourcen in einem Cache gehalten werden.

Das war ein Versehen, ich meine wirklich Service Worker. Die Applikation nutzt zwar auch web worker, aber die Fragestellung bezieht sich auf den Service Worker.

Du beschreibst hier das Standardverhalten für Serviceworker. Diese Network-First Regel hast Du nicht selbst erzeugt. Die ist im Browser eingebaut. Oder verstehe ich Dich miss?

Der fetch der serviceworker.js läuft aber nicht über den Serviceworker. Das täte mich zumindest sehr wundern. Der Serviceworker registriert sich ja nicht selbst als sein eigener Client. Des weiteren hast Du im Service-Worker - meine ich - auch keinen Zugriff auf die fetch-Inhalte. Du kannst im fetch-Event nur entscheiden, ob Du auf den Cache oder den Server gehst und eine Serverantwort in den Cache schieben. Oder irre ich mich?

Das werde ich mal testen, ich hatte nicht angenommen, dass der Service Worker unabhängig ist, d.h. dass man den Service Worker selbst auch cachen kann. Würde aber das Problem mitbringen, dass man sich selbst ausschliessen kann ;-)

Ich muss allerdings auch zugeben, dass ich mit Serviceworker-Updates bisher meine liebe Not hatte. Um sicher zu sein, dass ich eine geänderte .js Datei als Serviceworker lade, musste ich den Worker eigentlich immer manuell über die DevTools löschen - weil die neue Version ja erst aktiv wird, wenn keine Seiten mehr darauf zugreifen.

Dafür gibt es doch den Cache-Key. Der Austausch der versionierten Ressourcen funktioniert eigentlich ganz gut

Also das Szenario, dass jemand unbefugt Zugriff auf den Web Server hat und dort den Service Worker kompromitiert Dieses Szenario musst Du anders verhindern. Wenn Dir jemand auf dem Webserver Dateien austauschen kann, hast Du ganz andere Probleme.

Das ist mir bewusst und der Server ist schon ziemlich abgesichert (black carbon etc.) Aber es geht mir darum zu verstehen, ob man noch eine Schippe oben drauf legen kann.

Das Szenario, dass der Worker durch eine Man-in-the-Middle Attacke ersetzt wird, wird durch https (begrenzt) verhindert. Wenn auf deinem Client ein Zertifikat liegt, das das Zertifikat des Man-in-the-Middle vertrauenswürdig macht, ist https nur noch Augenwischerei? Gibt's nicht? Doch, schon. Vor allem in Firmen, die per HTTPS-Proxy sicherstellen, dass auf diesem Weg keine Malware hereinkommt und die Angestellten keine VPN Tunnel auf den Heim-PC bauen.

Ja, ja, ZScaler & Co ich weiss ,-) Aber Man-in-the-middle ist hier nicht das Scenario. Es geht eher darum, dass überprürt/ischergestellt werden kann, das keiner unbemerkt an der Applikation schraubt. Vermutlich ist wirklich die UpdateNotification, sobald der ServiceWorker sich inhaltlicjh ändert, der einzige sinnvolle Weg.

Gruss Michael