Supply-Chain-Angriffe sind ein großes Problem für das JavaScript-Ökosystem. In diesem kurzen Beitrag werde ich eine unkomplizierte Sicherheitsmaßnahme skizzieren, die von allen JavaScript-Laufzeiten implementiert werden kann, sowohl im Browser als auch außerhalb des Browsers. Dadurch werden die meisten Supply-Chain-Angriffe verhindert, die das JavaScript-Ökosystem heute plagen.
Problem: Berechtigungsvererbung
Hier ist ein aktueller Vorfall, bei dem Websites gehackt wurden:
- Forscher bringen den Polyfill-Lieferkettenangriff mit einem riesigen Netzwerk von Nachahmer-Glücksspielseiten in Verbindung
Der Kern des Problems besteht darin, dass JavaScript-Module die Berechtigungen der Anwendung oder des Moduls erben, die sie aufgerufen haben. Dies ist sowohl für Laufzeiten im Browser als auch für Laufzeiten außerhalb des Browsers ein Problem.
Dieses Problem wird noch dadurch verkompliziert, dass sich die Modulversion, von der eine Anwendung abhängt, ändern kann, ohne dass der Autor der Anwendung es weiß. Selbst wenn also die Codes aller Abhängigkeiten gründlich überprüft wurden (was an sich schon ein enormer Aufwand ist), ist dieser Aufwand vergeblich, wenn die Abhängigkeitsversionen nicht gesperrt wurden.
Warum nicht Versionen sperren und semantische Abhängigkeiten verwenden? Das liegt vor allem daran, dass es besser ist, den festen Code zu verwenden, wenn ein Modulherausgeber Fehlerbehebungen veröffentlicht. Und das ist einer der Hauptgründe, warum JavaScript-CDNs wie esm.sh Semvers unterstützen.
? Wie Websites betroffen sind
Webbrowser sind Sandbox-Ausführungsumgebungen, sodass ein von einer Website importiertes JavaScript-Modul (3JM) eines Drittanbieters keinen Schaden auf dem Gerät des Endbenutzers anrichten kann.
Trotzdem kann ein 3JM ohne Zustimmung der Website die Rechenressourcen des Geräts nutzen und Netzwerkanfragen für Bitcoin-Mining usw. stellen.
? Wie sich dies auf JavaScript-Anwendungen außerhalb des Browsers auswirkt
Einige Off-Browser-Laufzeitumgebungen wie Deno implementieren Maßnahmen, um die einer JavaScript-/TypeScript-Anwendung erteilten Berechtigungen einzuschränken. Diese Maßnahmen greifen jedoch aus folgenden Gründen zu kurz:
- Selbst wenn ein Berechtigungssystem wie das von Deno durchgesetzt wird, erlauben sie JS-Modulen dennoch, die Berechtigungen des Aufrufers ohne Einschränkungen zu erben. Das bedeutet, dass, wenn eine Anwendung über vollständige Schreibberechtigungen verfügt, ein E-Mail-Adressvalidator, der keinen Zugriff auf Ressourcen außer Rechenressourcen haben sollte, Benutzerdateien löschen kann, ohne dass der Betriebssystembenutzer es weiß.
- Anwendungen werden häufig mit den vollen Berechtigungen des Betriebssystembenutzers ausgeführt. Beispielsweise ist es für Code, der unter einem Tool wie MDRB ausgeführt wird, derzeit nicht möglich, Berechtigungen auf den ausgeführten Code zu beschränken.
Die aktuelle Lösung
Derzeit haben Sicherheitsteams automatisierte Prozesse zur Suche nach Schwachstellen in Modulen eingerichtet, die in bekannten Registern wie NPM veröffentlicht werden. Diese Sicherheitsmaßnahme weist mehrere Mängel auf:
- Das Scannen aller Versionen aller bekannten veröffentlichten Module ist unglaublich ressourcenintensiv.
- Es gibt keine Garantie dafür, dass alle verfügbaren Module gescannt wurden.
? Lösung: Berechtigungen pro Modul
Um diese Probleme zu beheben, schlage ich ein neues Berechtigungssystem pro Modul vor, das abwärtskompatibel mit der aktuellen Funktionsweise von JS/TS-Anwendungen ist.
Dabei handelt es sich um eine neue optionale Berechtigungskonfiguration, die jede Anwendung und jedes Modul in ihren Dateien deno.json / deno.jsonc / package.json deklarieren kann. Berechtigungen bestehen aus 2 Teilen:
-
Permissions.self – Hier deklariert die Anwendung oder das Modul die Berechtigungen, die sie und ihre Abhängigkeiten benötigen.
-
Berechtigungen.imports – Hier deklariert die Anwendung oder das Modul die Berechtigungen, die es seinen Abhängigkeiten zuweist. Dies ist eine Obermenge der Berechtigungen, die jede Abhängigkeit erfordern darf.
So würden Berechtigungen von der JS/TS-Laufzeit verwendet werden:
- Wenn eine Anwendung oder ein Modul ein Modul M importiert, prüft die Laufzeit, ob die Berechtigungen von M innerhalb der Grenzen liegen, die der Importer M. Der Import wirft einen Fehler (z. B. PermissionError), wenn dies nicht der Fall ist.
Ein Laufzeitfehler wird auch ausgelöst (z. B. PermissionError), wenn ein Modul oder eine Anwendung versucht, etwas zu tun, wozu es nicht berechtigt ist. Dieser Laufzeitfehler kann abgefangen und behandelt werden, ohne dass die Anwendung abgebrochen werden muss.-
Der Wert der Berechtigungen wäre etwa so:
{
"self": {
"read": {"allow": [], "deny": []},
"write": {"allow": [], "deny": []},
"net": {"allow": [], "deny": []},
"env": {"allow": [], "deny": []},
"run": {"allow": [], "deny": []}
},
"imports": {
"jsr:@org/module@1.0.0": {
"read": {"allow": [], "deny": []},
"write": {"allow": [], "deny": []},
"net": {"allow": [], "deny": []},
"env": {"allow": [], "deny": []},
"run": {"allow": [], "deny": []}
},
"https://cdn.example/org/module@1.0.0": {
"read": {"allow": [], "deny": []},
"write": {"allow": [], "deny": []},
"net": {"allow": [], "deny": []},
"env": {"allow": [], "deny": []},
"run": {"allow": [], "deny": []}
},
"[default]": {
"read": {"allow": [], "deny": []},
"write": {"allow": [], "deny": []},
"net": {"allow": [], "deny": []},
"env": {"allow": [], "deny": []},
"run": {"allow": [], "deny": []}
}
}
}
Nach dem Login kopieren
Im Vergleich zur aktuellen Lösung hat die von mir vorgeschlagene Lösung mehrere Vorteile:
-
Leichtgewicht – Veröffentlichte Module müssen nicht gescannt werden.
-
Gründlich – Berechtigungen werden zur Laufzeit erzwungen. Wenn also die richtige JS/TS-Engine verwendet wird, können selbst unbekannte Module nicht durchs Raster fallen.
Das scheint sehr einfach zu sein. An den JS/TS-Sprachen sind keine Änderungen erforderlich. Und wenn die Berechtigungskonfiguration fehlt, greifen wir auf die aktuelle Situation zurück, in der die Anwendung und ihr Abhängigkeitsdiagramm alle über die Berechtigungen verfügen, die durch die Befehlszeilenargumente bereitgestellt wurden ∎
Das obige ist der detaillierte Inhalt vonVerhinderung von Supply-Chain-Angriffen auf das JavaScript-Ökosystem. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
