Sichere Programmierpraktiken in React und Angular im Vergleich
30. Oktober 2019
0 Min. LesezeitWillkommen beim Snyk-Bericht 2019 zum Sicherheitsstatus von JavaScript-Frameworks. Dieser Abschnitt des Berichts befasst sich mit der allgemeinen Sicherheitslage von Angular- und React-Projekten.
In diesem Abschnitt untersuchen wir die Sicherheitslage der Projekte Angular und React. Dazu gehören sichere Programmierkonventionen, integrierte Sicherheitsfunktionen, Richtlinien zur verantwortungsvollen Offenlegung und spezielle Sicherheitsdokumentation für das jeweilige Projekt.
Die folgende Tabelle zeigt einige Sicherheitskomponenten, die unserer Einschätzung nach für die Best Practices bei der Pflege jedes Open-Source-Pakets unverzichtbar sind, sowie einen Hinweis darauf, wie Angular und React mit diesen Komponenten umgehen (sofern überhaupt).
Element | Angular | React |
Sicherheitsseite | ✅ https://angular.io/guide/security | ❌Auf der Website von React (https://reactjs.org) werden keine Sicherheitsrichtlinien erwähnt. Eine Ausnahme ist der Verweis auf die Funktion dangerouslySetInnerHTML im Abschnitt „DOM Elements“ der API-Referenzdokumentation. |
Sicherheitskontakt | ✅security@angular.io | ❌Kein Sicherheitskontakt |
Richtlinie zur verantwortungsvollen Offenlegung | ✅Unterstützt von den internen Sicherheitsteams bei Google und orientiert an der Google-Sicherheitsphilosophie. Referenz: https://www.google.com/about/appsecurity/ | ❌Keine Richtlinie zur verantwortungsvollen Offenlegung |
Beispiele für verwundbare Projekte | ✅https://angular.io/generated/live-examples/security/stackblitz. html | ❌Keine Verweise auf Beispiele für verwundbare Projekte |
Integrierte Bereinigung | ✅DomSanitizer bietet eine integrierte Funktion zur Bereinigung nicht vertrauenswürdiger Werte. Referenz: https://angular.io/api/platform-browser/DomSanitizer#sanitize | ❌Die Bereinigung potenziell schädlicher Eingaben muss von den Nutzern selbst implementiert werden, beispielsweise mithilfe von Drittanbieter-Bibliotheken wie DOMPurify. Referenz: https://github.com/cure53/DOMPurify |
Content Security Policy (CSP) | ✅CSP-Kompatibilität für Angular-v1.x-Direktiven. Referenz: https://docs.angularjs.org/api/ng/directive/ngCsp | 🔘Für React nicht relevant |
✅Integrierte CSRF-Unterstützung über den HttpClient-Dienst von Angular. Referenzen: https://angular.io/guide/http und https://docs.angularjs.org/api/ng/service/$http | 🔘Für React als View-Bibliothek nicht relevant. Entwickler müssen dies mit eigenem Code oder Community-Modulen handhaben. |
Sichere Programmierpraktiken in Angular
Angular v2 und neuere Versionen haben eine völlig andere Architektur als Angular v1, etwa eine unidirektionale Datenbindung. Außerdem verzichten Version 2 und höher auf die automatische Dateninterpolation durch Watcher sowie auf weitere Techniken, die häufig für viele Sicherheitslücken in Angular v1 verantwortlich waren.
Die Ahead-of-Time-Kompilierung (AoT) mindert Probleme wie das Einschleusen von Ausdrücken in Angular-Templates und ermöglicht Sicherheit zur Build-Zeit statt zur Laufzeit. Werden Templates jedoch dynamisch clientseitig interpoliert, bleibt die Tür für Sicherheitslücken in Form von Angular-Code-Injection offen. In der Dokumentation zu Best Practices rät Angular ausdrücklich dringend von dieser dynamischen Interpolation ab. Auch angesichts der Angular-Dokumentation gilt: Diese Vorgehensweisen werden ausdrücklich nicht empfohlen, wie die Best Practices von Angular klar hervorheben.
Um Cross-Site-Scripting-Sicherheitslücken zu mindern, verwendet Angular standardmäßig eine kontextabhängige Ausgabekodierung oder bereinigt schädlichen Code. Darüber hinaus sind die Namenskonventionen für Methoden im Hinblick auf ihre Auswirkungen leichter zu verstehen, wenn Entwickler sich bewusst für deren Verwendung entscheiden. Das ist eine Verbesserung gegenüber früheren Angular-Versionen, insbesondere Angular v1.x.
Methoden wie bypassSecurityTrustHtml(value)oder bypassSecurityTrustUrl() machen implizit deutlich, welche Gefahren damit verbunden sind, Daten in das DOM einzufügen. Zudem bietet Angular mit DomSanitizer eine integrierte Möglichkeit, Werte explizit zu bereinigen.
Sichere Programmierpraktiken in React
React kodiert standardmäßig fast alle Datenwerte, wenn DOM-Elemente erstellt werden. Damit Nutzer HTML-Inhalte in das DOM einfügen können, bietet React die treffend benannte Funktion dangerouslySetInnerHTML(), die klar auf die Gefahren ihrer Verwendung hinweist.
Zu den Bereichen, die nicht vom React-Sicherheitsmodell abgedeckt werden und für die Nutzer selbst verantwortlich sind, gehört das Erstellen von:
HTML-Ankerelementen (Links), bei denen vom Nutzer bereitgestellte Eingaben als Wert des href-Attributs verwendet werden. Dies betrifft vor allem Versionen vor der kürzlich veröffentlichten React-Version 16.9, die URLs auf Basis von javascript: in Werten des href-Attributs sowie in weiteren Kontexten wie Formularaktionen, iFrame-Quellen und anderen Bereichen entschärft.
React-Komponenten aus vom Nutzer bereitgestellten Eingaben
Das serverseitige Rendering von React kann potenziell XSS-Sicherheitslücken verursachen, wenn schädliche Nutzereingaben unverändert in einen JavaScript-Kontext eingefügt werden, ohne zuvor korrekt kodiert oder bereinigt zu werden.
HTTP-Sicherheit
Ab Version 1.2 bieten die Release-Zweige von Angular v1.x Kompatibilitätsunterstützung für Content Security Policy (CSP). Diese ist erforderlich, da zum Interpolieren von Ausdrücken die Methoden eval() und Function() verwendet werden.
Cross-Site Request Forgery (CSRF) ermöglicht Webanwendungen, dem Ursprung einer Anfrage zu vertrauen. In neueren Angular-Versionen ist der CSRF-Unterstützungsmechanismus im HTTP-Client über das Modul @angular/common/ http integriert. In Angular-v1.x-Versionen wird eine ähnliche Funktion über den Provider $http unterstützt.
Anders als Angular enthält React keinen HTTP-Client und kann daher keine sofort verfügbare CSRF-Unterstützung bieten. Da React als schlanke View-Bibliothek konzipiert ist, liegt es an den Entwicklern, dieses Thema mit eigenem Code oder von der Community bereitgestellten Modulen zu handhaben.
Wir empfehlen dringend, die vollständige Version des Berichts im digitalen Format herunterzuladen. Die folgenden allgemeinen Abschnitte haben wir jedoch auch als Blogbeiträge veröffentlicht:
