Prototype Pollution in Ihrem Repository verhindern

Wenn Sie direkt über einen Aikido Autofix Pull Request auf dieser Seite gelandet sind und nur erfahren möchten, wie Sie den PR abschließen, springen Sie zu „Wie implementieren“.

Das JavaScript-Ökosystem hat ein Problem, das als Prototype Pollution bekannt ist. Für ein SaaS-Unternehmen, das mit JavaScript/npm entwickelt, werden typischerweise bis zu 20-30 % aller bekannten Schwachstellen (CVE), die in den Abhängigkeiten entdeckt werden, durch Prototype Pollution verursacht. Diese sind in der Regel nicht leicht auszunutzen, können aber in schlimmen Fällen zu Remote Code Execution-Fehlern führen. Das bedeutet, sie sind insgesamt schwer zu ignorieren.

Zwei Wege, um Prototype Pollution zu verhindern

Es gibt experimentelle Unterstützung in Node.js, um den Prototyp standardmäßig unter einem Flag namens --frozen-intrinsics einzufrieren. Das Aktivieren dieses Flags vereitelt alle Prototype Pollution Angriffe. Wir können es jedoch noch nicht empfehlen, da es experimentell ist und auch nicht auf Frontend-Codebasen funktioniert. Das würde Sie daran hindern, den gleichen Schutz über Ihr Frontend und Backend hinweg aufzubauen.

Eine Alternative ist nopp (No Prototype Pollution), eine 14-zeilige Bibliothek, die den Prototyp (und einige andere Einstiegspunkte) einfriert.

Wie man implementiert

1. Importieren der Bibliothek

Nachdem Sie nopp installiert haben, müssen Sie nur noch zu dem Skript gehen, das Ihre App startet. Dort binden Sie die Bibliothek einfach ein, nachdem Sie alle anderen Bibliotheken eingebunden haben. Beispiel-Commit unten:

2. App-weiter Sicherheitscheck für Bibliotheken, die von Prototypenmanipulation abhängen.

Der Grund, warum wir den Prototyp nach dem Einbinden anderer Bibliotheken einfrieren, ist, dass einige Ihrer anderen Bibliotheken möglicherweise auf die Änderung des Prototyps angewiesen sind, um zu funktionieren! Selbst nachdem Sie sichergestellt haben, dass der Prototyp NACH dem Einbinden anderer Bibliotheken eingefroren wird, ist es immer noch möglich, dass Sie ein Refactoring benötigen, bevor Ihre App wieder funktioniert!

Ein Beispiel dafür ist, dass Amazons eigenes aws-sdk für Node.js Änderungen am Prototyp während der Konstruktion von Objekten wie „new AWS.S3(..)“ vornimmt. In solchen Fällen müssen Sie möglicherweise einen Refactor durchführen, wie unten gezeigt, um sicherzustellen, dass das Objekt beim Start Ihres Node.js-Prozesses und nicht in einer späteren Phase erstellt wird.

Sicherzustellen, dass Ihre App nach dieser Änderung noch funktioniert, könnte für größere Repositories mit geringer Testabdeckung einen größeren Zeitaufwand bedeuten. Für kleinere Repositories wird es sich lohnen, nie wieder mit Prototype Pollution zu tun zu haben. Für größere Repositories mag dies komplexer sein, aber die technische Investition wird sich langfristig wahrscheinlich immer noch positiv auf den ROI auswirken.