JavaScript war ursprünglich eine reine Browser-Sprache. Sie sorgt für interaktive Webseiten und dynamische Inhalte. Mit Node.js begann JavaScript jedoch auch auf Servern zu laufen. „Deno und Node.js sind sogenannte Laufzeitumgebungen. Vereinfacht gesagt stellen sie die Funktionen bereit, die ein Programm braucht, um außerhalb des Browsers zu laufen: Zugriff auf Dateien, Netzwerkverbindungen oder bestimmte Systeminformationen“, erklärt CISPA-Forscher Abdullah Alhamdan. Genau hier entstehen neue Sicherheitsfragen. Denn ein Programm, das auf einem Server läuft, kann erheblich mehr Schaden anrichten als ein Skript im Browser.
Das Sicherheitsversprechen von Deno
Deno setzt an mehreren Punkten an. Es wurde in Rust geschrieben, einer Programmiersprache, die typische Speicherfehler verhindert. Zudem führt Deno ein strenges Berechtigungssystem ein. Programme werden standardmäßig in einer Art Sandbox ausgeführt, das heißt sie sind isoliert und haben zunächst keinen Zugriff auf Dateien, Netzwerk oder Systemfunktionen. Jede sensible Aktion muss explizit erlaubt werden. Das Prinzip ähnelt den Berechtigungssystemen von Smartphones: Eine App kann auch nur auf Kamera, Mikrofon oder Adressbuch zugreifen, wenn die Nutzer:innen es erlauben. „Deno wird häufig als ‚secure by default‘ dargestellt“, erklärt Alhamdan. „Aber seine neuen Sicherheitsmechanismen lösen nicht alle grundlegenden Probleme mit JavaScript.“
Kleinere Angriffsfläche, aber nicht unangreifbar
Alhamdans Studie zeigt, dass Deno die Angriffsfläche im Vergleich zu Node.js erheblich reduziert. Bestimmte Schwachstellen, etwa Installations-Skripte, die beim Node-Paketmanager npm oft manipuliert werden und Schadcode enthalten können, gibt es in dieser Form nicht mehr. Auch Speicherfehler sind durch die Programmiersprache Rust, in der Deno geschrieben ist, deutlich unwahrscheinlicher. Dennoch bleiben Risiken durch bestimmte Angriffsklassen bestehen. „Dazu gehören ReDoS-Angriffe, bei denen Programme durch gezielt konstruierte Eingaben blockiert oder stark verlangsamt werden. Auch das in JavaScript verbreitete Problem der Prototype Chain Pollution wird nicht vollständig verhindert“, so der Forscher. Bei der Prototype Chain Pollution manipulieren Angreifer:innen eine gemeinsame Vorlage, von der viele Objekte im Programm Eigenschaften erben. Das ist, als würde jemand heimlich die Bauanleitung einer Fabrik austauschen und plötzlich produzieren alle Maschinen falsche Teile.
Sicherheit ist eine Frage der Konfiguration
Das größte Problem liegt jedoch im Berechtigungssystem von Deno selbst. Theoretisch reduziert es die Risiken deutlich. In der Praxis hängt die tatsächliche Wirkmacht aber davon ab, wie Entwickler:innen es einsetzen. Viele vergeben aus Bequemlichkeit sehr grobe Rechte, zum Beispiel „darf alle Dateien lesen“ oder „darf überall schreiben“. Solche pauschalen Berechtigungen können mehr Zugriff ermöglichen als erwartet. Laut Alhamdans Studie kann ein Programm damit beispielsweise sensible Systeminformationen auslesen oder Dateien verändern, die später außerhalb der Deno-Sandbox ausgeführt werden. Die Schutzmechanismen greifen zwar formal, verlieren aber praktisch ihre Wirkung. Die Forschenden sprechen in diesem Zusammenhang von „Shadow Permissions“: Berechtigungen, die indirekt weitere Möglichkeiten eröffnen. Sie empfehlen, Rechte gezielter zu erteilen und bestimmte Dateien oder Adressen explizit auszuschließen.
Neue Angriffswege durch URL-Importe
Ein zweites zentrales Deno-Merkmal betrifft die Einbindung von Drittanbieter-Code. Anders als Node.js mit seinem zentralen Paketmanager npm erlaubt Deno, Drittanbieter-Code direkt über Webadressen einzubinden. Das soll Transparenz schaffen und die Abhängigkeit von einer einzigen Plattform reduzieren. Doch diese Dezentralisierung bringt neue Herausforderungen. Die Untersuchung des Deno-Ökosystems zeigt: Code wird von zahlreichen Domains nachgeladen – teils über unsichere Protokolle, teils von instabilen oder sogar frei registrierbaren Adressen. Hinzu kommt: Nicht alle Plattformen garantieren, dass einmal veröffentlichter Code unverändert bleibt. Damit hängt die Sicherheit des gesamten Systems vom schwächsten Glied in der Kette ab. Supply-Chain-Angriffe bleiben somit auch in Deno realistisch. Alhamdan empfiehlt sogenannte Spiegel- oder Sicherungslösungen für externe Abhängigkeiten. Dabei speichern Entwickler:innen externen Code als geprüfte Kopie, statt ihn bei jeder Ausführung neu aus dem Internet zu laden, um Änderungen oder Ausfälle zu vermeiden. So können sie sicherstellen, dass er sich nicht unbemerkt ändert oder verschwindet.
Technische Lücken in der Durchsetzung
Die Studie identifiziert zudem konkrete technische Schwächen. So lassen sich feingranulare Dateiberechtigungen unter bestimmten Bedingungen umgehen, etwa durch symbolische Links, die aus einem erlaubten Ordner auf andere Bereiche des Systems verweisen. „Dieses Problem lässt sich nur durch konsequente technische Durchsetzung der Rechte lösen“, sagt Alhamdan. Auch der Importmechanismus für externen Code selbst war zeitweise nicht vollständig in das Berechtigungssystem eingebunden. Die Forschenden meldeten diese Probleme verantwortungsvoll an den Hersteller. Zwei Sicherheitswarnungen wurden veröffentlicht und der Importmechanismus angepasst.
Was heißt das für „secure by default“?
Deno ist ein klarer Fortschritt gegenüber Node.js. Die Angriffsfläche ist kleiner, viele Risiken sind reduziert. Doch Sicherheit entsteht nicht allein durch gute Voreinstellungen. Sie hängt von mehreren Faktoren ab, zum Beispiel: Wie präzise Entwickler:innen Berechtigungen vergeben, ob sie Drittanbieter-Code prüfen und Abhängigkeiten technisch absichern. „Sicherheit bedeutet nicht, Angriffe vollständig zu verhindern, sondern sie so schwer wie möglich zu machen“, sagt Alhamdan. „Sichere Runtimes sind eine wichtige Schutzschicht, aber sie ersetzen keine sichere Softwareentwicklung.“ Deno ist also ein Schritt in die richtige Richtung. Aber auch hier gilt: „Secure by Default“ heißt nicht automatisch sicher.
