Best Practices für Angular-Sicherheit

Wir haben bereits unseren Spickzettel zu den Sicherheitsgrundlagen von AngularJS veröffentlicht. Dieses Mal widmen wir uns direkt den Best Practices für die Sicherheit des modernen Angular. Hier können Sie den Spickzettel zu den Best Practices für Angular-Sicherheit herunterladen.

6 Best Practices für Angular-Sicherheit

1. Der „Angular-Weg“ schützt Sie vor XSS

2. Verwenden Sie innerHTML mit Vorsicht

3. Verwenden Sie niemals Templates, die durch Verketten von Benutzereingaben generiert wurden

4. Verwenden Sie niemals native DOM-APIs für die Interaktion mit HTML-Elementen

5. Vermeiden Sie Template-Engines in serverseitigen Templates

6. Prüfen Sie Ihr Angular-Projekt auf Komponenten, die Sicherheitslücken verursachen

1. Der „Angular-Weg“ schützt Sie vor XSS

Best Practice für Angular-Sicherheit Nr. 1: Verwenden Sie Interpolation ({{  }}) zur sicheren Kodierung potenziell gefährlicher Zeichen und zum Escapen nicht vertrauenswürdiger HTML- oder CSS-Ausdrücke in einem Template-Ausdruck. 

Angular verfolgt, ähnlich wie React und Vue.js, bei der Verarbeitung von String-Interpolation im Browser standardmäßig einen Security-by-Default-Ansatz. Standardmäßig werden alle Daten als unsicher und nicht vertrauenswürdig behandelt. Deshalb setzen diese Bibliotheken und andere moderne View-Bibliotheken die Best Practice um, Ausgaben in einem HTML-Kontext standardmäßig zu kodieren.

Wie wir ausführlich in unserem früheren Blogbeitrag zu den Best Practices für die Sicherheit von AngularJS beschrieben haben, wird dringend empfohlen, dem „Angular-Weg“ zu folgen und die integrierte Interpolation mit geschweiften Klammern zu verwenden. So escapen Sie bösartige Benutzereingaben, die Ihre Webanwendung gefährden und sie möglicherweise Cross-Site-Scripting-Schwachstellen (XSS) aussetzen können.

2. Verwenden Sie innerHTML mit Vorsicht

Best Practice für Angular-Sicherheit Nr. 2: Wenn Sie einer Komponente dynamisch HTML hinzufügen müssen, binden Sie dessen Generierung an [innerHTML]. So werden die Daten in ihrem Kontext als HTML interpretiert und bereinigt. Dabei werden alle unsicheren Tags entfernt und die Ausführung schädlichen Cross-Site-Scripting-Codes verhindert. Beachten Sie, dass die Aktion des Bereinigens nicht dasselbe ist wie Kodieren.

Was ist der Unterschied zwischen Bereinigung und Ausgabekodierung?

Bei der Ausgabekodierung werden Zeichenfolgen durch ihre Textdarstellung ersetzt, die einem bestimmten HTML-Tag zugeordnet werden kann. Wird zum Beispiel eine Eingabe wie script geparst, kann Angular diesen Text anzeigen, indem die Sonderzeichen für spitze Klammern kodiert werden. Dies ist ein Standard für viele andere Bibliotheken und Frameworks, die Best Practices für Sicherheit umsetzen. Dazu werden sogenannte HTML-Entities kodiert und folgender Text in das DOM geschrieben: script. Der Browser interpretiert dann den Kontext und gibt ein script-Tag aus.

Anders als die Ausgabekodierung geht die Bereinigung oder Filterung proaktiver vor: Unsichere Zeichen werden erkannt und aus dem Text entfernt, der anschließend in das DOM geschrieben wird.

Der Kontext ist entscheidend für die Ausgabekodierung und Bereinigung, da er unmittelbar beeinflusst, wie diese korrekt ausgeführt werden.

Weitere Informationen zu Sicherheitskontexten finden Sie in der Angular-Dokumentation. Dort heißt es:

Angular definiert die folgenden Sicherheitskontexte:

* HTML wird verwendet, wenn ein Wert als HTML interpretiert wird, zum Beispiel bei der Bindung an innerHtml.* Style wird verwendet, wenn CSS an die Style-Eigenschaft gebunden wird.* URL wird für URL-Eigenschaften verwendet, zum Beispiel für * Resource URL ist eine URL, die als Code geladen und ausgeführt wird, zum Beispiel in .

Beachten Sie die besondere Behandlung von URLs, die nicht gefiltert werden.

3. Verwenden Sie niemals Templates, die durch Verketten von Benutzereingaben generiert wurden

Best Practice für Angular-Sicherheit Nr. 3: Verketten Sie niemals potenzielle Benutzereingaben als Zeichenfolge mit einem Template.

Es sollte kaum Anwendungsfälle geben – wenn überhaupt –, die das Verketten von Templates statt der korrekten Verwendung von String-Interpolation oder der empfohlenen Komposition von Komponenten in einer Angular-Anwendung erfordern. Wenn Sie diese schlechte Praxis in einer Codebasis entdecken, sollten Sie die Eingabe so weit wie möglich bereinigen oder den Code umgestalten.

Hier sehen Sie ein Beispiel dafür, worauf Sie achten und was Sie vermeiden sollten:

Best Practice für Angular-Sicherheit: Verwenden Sie niemals Templates, die durch Verketten von Benutzereingaben generiert wurden

Achten Sie besonders auf die ungewöhnliche Verkettung von Zeichenfolgen zu einem Template in Zeile 20. Der Wert von potentialUserInput kann ein bösartiger Ausdruck unbekannter oder nicht vertrauenswürdiger Herkunft sein. Das ist eine schlechte Praxis, auf die Sie achten sollten.

Im Folgenden sehen Sie ein ausführlicheres Beispiel, das Sie ausprobieren können in meinem Angular-Playground. Es zeigt, wie Benutzereingaben unsicher verarbeitet werden, wenn sie an das Template angehängt werden:

Best Practice für Angular-Sicherheit in der Praxis: Verwenden Sie niemals Templates, die durch Verketten von Benutzereingaben generiert wurden

Die offizielle Empfehlung im Angular-Sicherheitsleitfaden lautet:

„Generieren Sie niemals Template-Quellcode, indem Sie Benutzereingaben und Templates verketten. Verwenden Sie zur Vermeidung dieser Schwachstellen den Offline-Template-Compiler, auch bekannt als Template Injection.“

– Angular-Sicherheitsleitfaden

Angular empfiehlt, Templates mit dem Ahead-of-Time-Compiler offline zu kompilieren. So lassen sich zahlreiche Schwachstellen durch Template Injection vollständig vermeiden:

ng build --aot
ng serve --aot

Beachten Sie, dass in den neuesten Angular-Versionen – Angular v9 und höher – bei der Kompilierung mit Ivy die Ahead-of-Time-Kompilierung standardmäßig aktiviert ist und so Template Injection verhindert:

{
  "projects": {
    "my-existing-project": {
      "architect": {
        "build": {
          "options": {
            ...
            "aot": true,
          }
        }
      }
    }
  }
}

4. Verwenden Sie niemals native DOM-APIs für die Interaktion mit HTML-Elementen

Best Practice für Angular-Sicherheit Nr. 4: Verwenden Sie niemals native DOM-APIs für die Interaktion mit HTML-Elementen auf der Seite.

Vermeiden Sie direkte DOM-Manipulationen und verwenden Sie stattdessen die Angular-Template-Mechanismen und die Angular-eigenen APIs zur Manipulation des DOM. Vermeiden Sie grundsätzlich Folgendes:

•  node.appendChild();

• Verwendung der Methoden des document-Objekts für die Interaktion mit der Seite

• Verwendung von jQuery-APIs

Es gibt native Angular-APIs, die dieselbe Art direkter DOM-Manipulation ermöglichen, von der wir abraten – zum Beispiel die ElementRef-API. Angular ElementRef kann Sicherheitsprobleme verursachen, wenn damit auf einen direkten DOM-Knoten zugegriffen und dieser manipuliert wird.

Diese und andere Interaktionen außerhalb der Angular-APIs können zu Sicherheitslücken führen.

5. Vermeiden Sie Template-Engines in serverseitigen Templates

Best Practice für Angular-Sicherheit Nr. 5: Vermeiden Sie Template-Engines von Drittanbietern, um Templates oder Template-Daten in serverseitig gerenderten Angular-Anwendungen zu erstellen oder hinzuzufügen.

Wenn Sie Node.js zum Erstellen von Webanwendungen verwenden, haben Sie wahrscheinlich schon einmal eine Template-Engine wie EJS, Pug, Handlebars oder eine Alternative dazu genutzt. Sie dienen der Verwaltung serverseitig gerenderter Templates für die View-Ebene und können Partials, Layout-Kompositionen sowie weitere Funktionen zur dynamischen Generierung einer View umfassen.

Die Verwendung dieser Template-Engine-Mechanismen in einer serverseitig gerenderten Angular-Anwendung kann jedoch dazu führen, dass bösartiger Code in ein Template eingeschleust wird. Das liegt daran, dass die eingefügten Daten außerhalb des Geltungsbereichs der Angular-API liegen und nicht bereinigt werden können. Dadurch entstehen dieselben Risiken wie beim Verketten von Template-Zeichenfolgen.

6. Prüfen Sie Ihr Angular-Projekt auf Komponenten, die Sicherheitslücken verursachen

Best Practice für Angular-Sicherheit Nr. 6: Prüfen Sie die Open-Source-Abhängigkeiten und Angular-Komponenten Ihres Projekts stets auf Sicherheitslücken. Nutzen Sie die Snyk-Plattform oder die CLI kostenlos, um Sicherheitslücken zu finden, zu beheben und zu überwachen.

Bei der Verwendung von Bibliotheken von Drittanbietern wie Angular und seinem Ökosystem aus Modulen und Komponenten sollten Sie Folgendes berücksichtigen: Sicherheitslücken in der Angular-Kernbibliothek und Sicherheitslücken in den Angular-Modulen von Drittanbietern, die Sie in Ihr Projekt importieren und verwenden.

Die Verwendung von Komponenten mit bekannten Schwachstellen ist ein dokumentiertes Sicherheitsrisiko der OWASP Top 10, das Sie kennen sollten. Die Abbildung unten zeigt eine Liste von Angular-Modulen mit bekannten Sicherheitslücken, die beispielsweise bei der Ausführung von npm install oder npm audit gemeldet würden. Wie Sie in dieser Abbildung aus unserem Bericht zur Sicherheit von JavaScript-Frameworks sehen, verzeichnen einige davon zwar jährlich Millionen Downloads, verfügen aber bis heute über keinen Sicherheitsfix:

Angular-Sicherheit – das Risiko indirekter Abhängigkeiten

Angular-Webanwendungen absichern

Wenn Sie npm audit verwenden, ist das ein hervorragender erster Schritt – Sie sind bereits auf einem guten Weg!

Doch auch wenn Sie die Audit-Funktion von npm verwenden, gibt es weiterhin Sicherheitsrisiken, die Sie minimieren sollten:

• Vielleicht haben Sie derzeit alle Sicherheitslücken in Ihrem Projekt behoben. Was aber passiert, wenn eine neue Schwachstelle in einem dieser Angular-Module entdeckt wird? Erfahren Sie, ob sie eine Ihrer auf Vercel, Netlify oder anderen Plattformen bereitgestellten Angular-Anwendungen betrifft?

• Ein weiteres Problem: npm audit erfasst nur bekannte Schwachstellen mit einer offiziellen CVE. Snyk hingegen erfasst über 23 Sicherheitslücken in Angular-bezogenen Modulen, während npm audit keine davon meldet: https://snyk.io/blog/angular-vs-react-security-bakeoff-2019/

Snyk löst beide Probleme für Sie – und ist kostenlos ;-)

Wie können Sie loslegen?

Erstellen Sie Ihr kostenloses Snyk-Konto und verbinden Sie Ihre Frontend-Projekte auf GitHub oder Bitbucket. So findet Snyk automatisch Schwachstellen und erstellt Pull Requests mit Korrekturen für Sie.

Ein weiterer schneller Weg, um loszulegen und Angular-Sicherheitsprobleme zu finden, ist die Snyk CLI:

npm install -g snyk
snyk test

Die Snyk-CLI liefert mehr als nur bekannte CVE-Sicherheitslücken – im Gegensatz zu npm audit, das diese nicht meldet.

Quelle: Angular vs. React: Sicherheitsvergleich 2019

Snyk bietet konkrete Empfehlungen zur Behebung und zum Upgrade auf eine Version mit Fix.

Wenn Sie nach einem Angular-Sicherheitsscanner suchen, probieren Sie Snyk aus. Damit können Sie Ihre Open-Source-Abhängigkeiten verfolgen, sich benachrichtigen lassen und Schwachstellen beheben, sobald sie entdeckt werden.

Weitere empfohlene Lektüre:

• Wenn Sie AngularJS pflegen oder aktiv damit entwickeln, sind die 10 grundlegenden Best Practices für AngularJS-Sicherheit hilfreich.

• Wie schneiden Angular und React im Hinblick auf ihre Sicherheitslage ab? Wir haben dazu einen ausführlichen Bericht zur Sicherheit von JavaScript-Frameworks veröffentlicht.

Ist Angular sicher?

Das neue Angular-Framework (Angular 2 und höher) gilt standardmäßig als sicher und weist keine bekannten Sicherheitslücken auf. Im Vergleich dazu hat AngularJS, sein Vorgänger, mehr als 25 öffentlich bekannte Sicherheitslücken, zuletzt im Juni 2020. Befolgen Sie unbedingt die Best Practices für Angular-Sicherheit und lesen Sie den Bericht von Snyk zur Sicherheit von JavaScript-Frameworks, um die Sicherheit des npm-Modul-Ökosystems für Angular, React und andere Projekte genauer kennenzulernen.

Wie sichern Sie eine Angular-Anwendung?

Hier sind einige grundlegende Richtlinien, mit denen Sie die Sicherheit Ihrer Angular-Anwendung gewährleisten können:

1. Achten Sie als Entwickler darauf, dem „Angular-Weg“ und seinen Best Practices zu folgen, um sich vor XSS zu schützen. Verwenden Sie zum Beispiel kein innerHTML, erstellen Sie niemals Templates durch Verketten von Benutzereingaben und verwenden Sie niemals native DOM-APIs für die Interaktion mit HTML-Elementen.

2. Prüfen Sie Ihr Angular-Projekt auf Komponenten, die Sicherheitslücken verursachen. Selbst wenn Sie die Sicherheitspraktiken von Angular befolgen, tun dies andere Modulautoren möglicherweise nicht – und setzen Sie dadurch schwerwiegenden Risiken aus. Beschränken Sie sich nicht auf das Scannen: Beheben und überwachen Sie auch potenziell neu auftretende Probleme. Snyk eignet sich hervorragend dafür und ist ein kostenloses Tool, das Sie ganz einfach mit Ihren Projekten verbinden können. Erfahren Sie mehr über Best Practices für Angular-Sicherheit.

Was ist sicherer: Angular oder React?

Das Angular-Projekt (Angular 2+) weist keine öffentlich bekannten Sicherheitslücken auf. React hat 2 Sicherheitslücken, die das Framework betreffen. Diese stammen jedoch aus dem Jahr 2017, und wahrscheinlich verwenden Sie bereits eine neuere Version. Angulars Vorgänger AngularJS weist mehr als 25 Sicherheitslücken auf. Wenn Sie es weiterhin entwickeln oder warten, sollten Sie Ihre Projekte unbedingt mit einem kostenlosen entwicklerorientierten Sicherheitstool wie Snyk scannen. Zu diesem Thema können Sie den Sicherheitsbericht zu JavaScript-Frameworks lesen, der den Sicherheitsstatus des Angular- und des React-Ökosystems untersucht.

Bereinigt Angular Eingaben?

Angular kodiert standardmäßig alle potenziell gefährlichen Textausgaben, die zu XSS führen könnten – vorausgesetzt, Sie halten sich an die sicheren Codierungspraktiken von Angular, etwa indem Sie für sichere Interpolation doppelte geschweifte Klammern ({{}}) verwenden. Wenn Sie jedoch Angulars innerHTML-Binding verwenden, versucht Angular, Sie durch die Bereinigung gefährlicher Inhalte bestmöglich zu schützen. Das sollte allerdings Ihr letzter Ausweg sein, wenn Sie Benutzereingaben hinzufügen.