Angular vs. React: Das Sicherheitsrisiko indirekter Abhängigkeiten

Willkommen zum Snyk-Bericht 2019 zum Sicherheitsstatus von JavaScript-Frameworks.

In diesem Abschnitt betrachten wir die Sicherheitsrisiken indirekter Abhängigkeiten bei Angular und React und anschließend die direkten Abhängigkeiten – zuerst bei Angular, dann bei React.

Laden Sie den Bericht hier herunter!

Die in diesem Abschnitt untersuchten Module stellen keine vollständige Liste anfälliger React- und Angular-Module dar. Einige Module verwenden möglicherweise spezielle Namenskonventionen (beispielsweise Präfixe wie ng-, angular- oder react-), die bei unserer musterorientierten Suche nicht erfasst wurden.

Das Sicherheitsrisiko indirekter Abhängigkeiten

Projekte auf Basis von React oder Angular werden häufig mit einem Gerüstbau-Tool erstellt, das eine Vorlage für den Entwicklungsstart bereitstellt. Bei React ist die gängige Vorgehensweise für Entwickler, das npm-Paket create-react-app zu verwenden. Es erstellt ein vorkonfiguriertes Projekt als Ausgangspunkt und integriert beispielsweise das Test-Framework Jest, CSS-Prozessoren und weitere Tools. Bei Angular ist dies dank des npm-Pakets @angular/cli möglich.

Um den Zustand der Abhängigkeiten und die Sicherheit (die das Gesamtsicherheitsrisiko widerspiegeln) der React- und Angular-Vorlagen zu vergleichen, haben wir ein Beispielprojekt erstellt. Das Ergebnis ist recht erfreulich: Beide enthalten anfällige Entwicklungsabhängigkeiten, aber keine Sicherheitsprobleme in Produktionsabhängigkeiten.

Die folgenden Sicherheitslücken werden von Anfang an in Ihren Code eingebracht, wenn Sie ein Projekt mit der Angular- oder React-Vorlage starten:

Bemerkenswert ist, dass Angular auf 952 Abhängigkeiten setzt, die insgesamt zwei Sicherheitslücken enthalten. React verwendet 1257 Abhängigkeiten, darunter drei Sicherheitslücken und ein mögliches Problem mit der Lizenzkompatibilität.

Hinweis zu Softwarelizenzen in Open Source

Bei der Lizenzierung betrachten wir die Lizenzkonformität neben Sicherheitsproblemen als wichtigen Faktor für den allgemeinen Zustand von Abhängigkeiten. Daher prüfen unsere Scans auch Lizenzen. Die Ergebnisse der Lizenzprüfung basierten auf den Standardkonfigurationen unserer Lizenzrichtlinien, die vor dem Scan festgelegt wurden.

Diesen Ergebnissen zufolge hängt das generierte React-Projekt vom Paket mdn-data ab, das wiederum die Mozilla-Copyleft-Lizenz MPL-2.0 verwendet. Wenn Sie Ihre React-Anwendung mit On-Premises-Installationen oder ähnlichen Setups verteilen möchten, die die Abhängigkeit mdn-data enthalten, sollten Sie die Lizenzanforderungen prüfen, damit Ihr Projekt konform ist.

Außerdem empfehlen wir, Ihre Projekte anhand der Vorgaben der individuellen Richtlinien Ihrer Organisation zu scannen. Diese können weitere indirekte React-Abhängigkeiten beanstanden – müssen es aber nicht.

Anfällige Pfade beheben

Ein Pfad beschreibt, wie eine Open-Source-Abhängigkeit in Ihr Projekt gelangt. Angenommen, Sie haben zwei direkte Abhängigkeiten namens Project A und Project B. Beide bringen die Abhängigkeit Project C mit. Project C ist nun mit zwei verschiedenen Pfaden verknüpft, da es sowohl von Project A als auch von Project B installiert wird. Enthält Project C Sicherheitslücken, müssen Entwickler beide Pfade berücksichtigen, um diese zu beheben.

Bei React verteilen sich die drei Sicherheitslücken auf 16,293 anfällige Pfade. Bei so vielen Paketen in der Abhängigkeitskette, die aktualisiert werden müssen, wird die Behebung durch Paket-Upgrades zu einer gewaltigen Aufgabe. Im Gegensatz dazu lassen sich die beiden Sicherheitslücken in Angular einfach beheben, da nur zwei anfällige Pfade betroffen sind.

Das folgende Bild stammt aus einem Sicherheits-Scanbericht vom August 2019 für ein mit dem npm-Paket create-react-app erstelltes React-Projekt. Der Bericht zeigt das Problem mit der Abhängigkeitskette, das bei einer einzelnen Sicherheitslücke angegangen werden muss.

Um die Sicherheitslücke zu beheben, müssen Sie in jedem einzelnen betroffenen Paket der gesamten Abhängigkeitskette neue Versionen von lodash einspielen.

Da lodash im Ökosystem weit verbreitet ist, wird die anfällige Version letztlich in Tausenden von Abhängigkeitspfaden verwendet.

Sicherheitslücken im Angular-Modul-Ökosystem

Im Angular-Ökosystem treten Sicherheitslücken in Modulen in drei Bereichen auf:

• Module im Angular-Ökosystem

• Schädliche Modulversionen

• Entwickler-Tools. Bei der Untersuchung des Angular-Modul-Ökosystems stechen die folgenden Module aufgrund ihrer Download-Zahlen und der damit verbundenen Sicherheitslücken besonders hervor:

Ordnen wir die Arten von Sicherheitslücken nach der Anzahl der Downloads der Module, die sie enthalten, zeigt sich deutlich, dass XSS-Sicherheitslücken die Liste anführen. Das wird auch in den OWASP Top 10 Web-Sicherheitsrisiken deutlich, auf die Sie achten sollten:

Schädliche Angular-Module

Insgesamt konnten wir drei schädliche Versionen der folgenden Angular-Module aufspüren: angular-bmap, ng-ui-library, ngx-pica.

angular-bmap ist vielleicht am wenigsten interessant, wie sich auf der Seite zum Zustand der Abhängigkeiten zeigt: Alle acht veröffentlichten Versionen stammen aus dem September 2017. Dennoch wurde Version 0.0.9 von angular-bmap veröffentlicht. Sie enthält schädlichen Code, der vertrauliche Passwort- und Kreditkartendaten aus Formularen ausliest und an die vom Angreifer kontrollierte URL https://js-metrics.com/minjs. php?pl= sendet. Diese schädliche Version 0.0.9 wurde aus der npm-Registry entfernt.

Anders als das Angular-bmap-Modul wird ng-ui-library weiterhin gepflegt und umfasst mehr als 150 veröffentlichte Versionen, allein sieben davon aus dem Jahr 2019. Allerdings wurde festgestellt, dass Version 1.0.987 von ng-ui-library denselben schädlichen Code enthält, den wir bereits in angular-bmap gefunden haben. ng-ui-library verzeichnet weiterhin nahezu 400 bis 3000 Downloads pro Monat.

Dieselbe Art schädlichen Codes, der Kreditkartendaten ausliest, findet sich auch in einer schädlichen Version von ngx-pica. Das mit Angular v5 und Angular v7 kompatible Modul dient der Bildgrößenanpassung im Browser und wird monatlich etwa 800-mal heruntergeladen.

Interessanterweise wurden alle diese schädlichen Versionen erst vor Kurzem entdeckt. Sie wurden sämtlich im Juni 2019 offengelegt, obwohl der schädliche Code bereits einen Monat zuvor in einer neuen Version veröffentlicht worden war.

Angular-Entwickler-Tools

Bei der Analyse des Modul-Ökosystems entdeckten wir ein Modul, das als allgemeiner HTTP-Server zum Bereitstellen von Ressourcen für Single-Page-Anwendungen dient, die mit Angular, React, Vue und anderen Technologien erstellt wurden.

Das Modul angular-http-server war gleich zweimal anfällig für Directory Traversal. Beide anfälligen Versionen sind ein Jahr alt, und inzwischen wurden bereits ein halbes Dutzend neuere Versionen veröffentlicht. Obwohl der Modulbetreuer ausdrücklich darauf hinweist, dass dieses Tool nicht als produktionsreifer Dienst empfohlen wird, sind die Downloads in diesem Jahr deutlich gestiegen: Im Mai 2019 wurden 20,670 Downloads verzeichnet.

Angesichts der zunehmenden Verbreitung dieses Angular-HTTP-Server-Entwicklertools möchten wir darauf hinweisen, dass es einen öffentlichen Exploit für diese Sicherheitslücke gibt.

Sicherheitslücken im React-Modul-Ökosystem

Wie bei Angular haben wir festgestellt, dass im React-Ökosystem irgendwann mehrere schädliche Module veröffentlicht wurden. Die folgende Darstellung zeigt die Verteilung der Arten von Sicherheitslücken und deren Anzahl in allen von uns gefundenen anfälligen Modulen. Besonders hervorgehoben sind vier schädliche Pakete: react-datepicker- plus, react-dates-sc, awesome_react_utility, react- server-native.

Alle vier schädlichen Module enthalten denselben schädlichen Code, der Kreditkarten- und andere vertrauliche Informationen ausliest. Auch Module im React-Ökosystem waren von diesem Angriff betroffen.

Das unterstreicht erneut, wie wichtig es ist, als Betreuer eines Open-Source-Projekts die Multi-Faktor-Authentifizierung zu aktivieren, beispielsweise die vom npm-Paket-Registry unterstützte 2FA. So verhindern Sie, dass Ihre Nutzer gefährdet werden, falls jemand Ihr Konto kompromittiert und schädliche Paketversionen veröffentlicht.

Falls Sie es noch nicht getan haben, empfehlen wir Ihnen dringend, 2FA für Ihr npmjs.org-Entwicklerkonto zu aktivieren und weitere npm-Sicherheits-Best Practices zu befolgen.

Bemerkenswerte anfällige Module, die wir im React-Ökosystem erfasst haben:

• Eine XSS-Sicherheitslücke mit hohem Schweregrad in react-marked-markdown, für die es keine Behebung gibt. Dieser React-Komponenten-Wrapper für die JavaScript-Markdown-Bibliothek marked wird dennoch weiterhin tausendfach heruntergeladen – insgesamt 65,790-mal in den vergangenen zwölf Monaten.

• Für alle unter Ihnen, die preact verwenden: Die Bibliothek preact-render-to-string ist in allen Versionen vor 3.7.2 anfällig für Cross-Site-Scripting. Ihre Nutzung nimmt zu; im betrachteten Zeitraum der vergangenen zwölf Monate wurde sie insgesamt 3,228,049-mal heruntergeladen.

• Wenn Sie Tooltips in Ihrer React-Frontend-Anwendung einsetzen, verwenden Sie möglicherweise react-tooltip. Allein im Juli 2019 wurde die Bibliothek knapp eine Million Mal heruntergeladen (994,903). Allerdings sind alle Versionen vor 3.8.1 anfällig für Cross-Site-Scripting-Angriffe – dies wurde im September 2018 offengelegt.

• Wenn Sie häufig mit SVGs arbeiten, verwenden Sie wahrscheinlich react-svg, das in den vergangenen zwölf Monaten 1,446,442 Downloads verzeichnete. Im April 2018 legte der Sicherheitsforscher Ron Perris eine XSS-Sicherheitslücke mit hohem Schweregrad offen, die alle Versionen vor 2.2.18 betrifft.

• Im März 2019 wurde eine CSV-Injection-Sicherheitslücke in mui-datatables offengelegt. Diese React-Bibliothek bietet eine UI-Komponente für tabellarische Daten, die auf dem Material-UI-Framework basiert, und verzeichnet in den vergangenen zwölf Monaten mehr als 350,000 Downloads.

Bei der Untersuchung aller von uns gefundenen anfälligen React-Module zählten wir in den vergangenen drei Jahren acht Sicherheitslücken: zwei im Jahr 2017, sechs im Jahr 2018 und zwei bis August 2019. Das zeigt, wie wichtig ein verantwortungsvoller Umgang mit Open Source ist und dass Sie Sicherheitslücken so schnell wie möglich finden und beheben sollten.

Im Fokus: Sicherheitslücken in Next.js

Next.js ist ein beliebtes React-Framework von ZEIT. Es ermöglicht Webentwicklern, ihre React-Kenntnisse zu nutzen, um SEO-freundliche Webanwendungen, serverseitig gerenderte Anwendungen, Progressive Web Apps (PWA) und sogar Electron-basierte Anwendungen zu erstellen – alles auf Basis des Next.js-Frameworks.

Next.js wird von immer mehr Entwicklern genutzt und verzeichnete in den vergangenen 12 Monaten 8.414.925 Downloads. Mit dem kontinuierlichen Wachstum des Projekts wird es immer wichtiger, einen Blick auf seinen Sicherheitsstatus zu werfen.

Im Laufe der Jahre 2017 bis 2018 haben wir drei schwerwiegende Directory-Traversal-Schwachstellen und zwei mittelschwere Cross-Site-Scripting-Schwachstellen im Next.js-React-Framework erfasst. Außerdem ist hervorzuheben, dass das ZEIT-Sicherheitsteam alle fünf Schwachstellen schnell behoben und innerhalb einer Woche einen Upgrade-Pfad für das Next.js-Framework bereitgestellt hat.

Insgesamt setzt ZEIT auf starke Sicherheitspraktiken, an denen sich andere Open-Source-Projekte orientieren sollten. Besonders hervorzuheben sind:

• Das Team reagiert schnell auf die Offenlegung von Sicherheitslücken und veröffentlicht zeitnah Sicherheitsupdates. Dadurch bleibt das Zeitfenster, in dem tatsächlich ein Sicherheitsrisiko besteht, klein. ZEIT stellt Nutzern einen Upgrade-Pfad bereit, über den sie die Schwachstelle schnell entschärfen können.

• Um Sicherheitsrückschritte zu vermeiden, hat das Team Sicherheits-Unit-Tests geschrieben, die sicherstellen, dass sich Sicherheitsfehler nicht wiederholen.

• Die Versionshinweise kommunizieren klar sicherheitsrelevante Informationen, deren Auswirkungen und alle erforderlichen Schritte, mit denen Nutzer bei einem Sicherheitsupdate auf dem neuesten Stand bleiben.

• Das Projekt unterhält eine Mailingliste für Sicherheitsmeldungen, eine Richtlinie zur verantwortungsvollen Offenlegung sowie eine eigene E-Mail-Adresse für die Meldung von Problemen.

ZEIT und der Umgang mit dem Next.js-Framework sind ein hervorragendes Beispiel für gute Sicherheitsrichtlinien bei Open-Source-Projekten. ZEIT nimmt Sicherheit ernst und zeigt mit Richtlinien und Maßnahmen ein echtes Engagement für die Sicherheit seiner Nutzer – ein Beispiel, dem andere folgen sollten.

Laden Sie den Bericht hier herunter!

Weiter mit den Highlights des nächsten Abschnitts:

• Der Sicherheitsstatus von JavaScript-Frameworks: Sicherheitsbericht 2019

• Angular vs. React: Sicherheitsvergleich 2019

• Angular und React im Sicherheitsvergleich 2019: Schwachstellen im Überblick

• 10 Best Practices für die Sicherheit von React

• React und Angular: Sichere Programmierpraktiken im Vergleich

• 84 % aller Websites sind von jQuery-XSS-Schwachstellen betroffen

Oder laden Sie die vollständige Version des Berichts im digitalen Format herunter.