Grundlagen der AngularJS-Sicherheit

In diesem Cheatsheet zu Best Practices für die AngularJS-Sicherheit konzentrieren wir uns auf AngularJS und stellen Tipps und Richtlinien für sicheres Programmieren vor. Im Wesentlichen ist dieses Cheatsheet eine Sammlung von Grundlagen der AngularJS-Sicherheit für Webentwickler.

Grundlagen der AngularJS-Sicherheit herunterladen

Im Folgenden finden Sie die 10 Best Practices zu den Grundlagen der AngularJS-Sicherheit, die wir in diesem Blogbeitrag behandeln:

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

2. Vermeiden Sie die Eingabeinjektion in das Angular-DOM

3. Vermeiden Sie das dynamische Laden von Angular-Templates aus nicht vertrauenswürdigen Quellen

4. Open-Redirect-Schwachstellen in AngularJS

5. Angular-Code-Injection auf der Serverseite

6. Vermeiden Sie die Manipulation des DOM mit der jQuery-kompatiblen Angular-API .element

7. Verwenden Sie Angular-Security-Linter

8. Scannen Sie Angular-Komponenten von Drittanbietern auf Schwachstellen und beheben Sie diese

9. Integrierte CSRF-Unterstützung für Angular-Anwendungen

10. Integrierte CSP-Kompatibilität von Angular

Warum ist es so wichtig, über Best Practices für die AngularJS-Sicherheit zu sprechen?

Laut unserer früheren Studie zu JavaScript-Frameworksicherheit entfallen auf Angular v1.x etwa 30 % aller Downloads von Angular-Versionen und etwas mehr als 2 Millionen Downloads im Juli 2019.

Quelle: https://snyk.io/blog/javascript-frameworks-security-report-2019/

Ist Angular besser als AngularJS?

Angular ist die Nachfolgeversion von AngularJS. Bemerkenswert ist, dass wir keine gemeldeten Sicherheitslücken in der Kernkomponente von Angular finden konnten. Allerdings sind für AngularJS 23 Schwachstellen über alle Release-Zweige der Version 1.x hinweg erfasst.

Welche AngularJS-Version sollte ich verwenden?

Sie sollten immer die neueste Version von AngularJS verwenden – zum Zeitpunkt der Erstellung dieses Beitrags AngularJS 1.7. Sie ist stets auf dem neuesten Stand der Sicherheitskorrekturen und wird bis zum 30. Juni 2021 unterstützt.

Vielen Dank an Lewis Arden, der zuvor umfangreiche Recherchen und hilfreiche Informationen zur AngularJS-Sicherheit geteilt hat. Hier finden Sie seinen Vortrag zur Absicherung von AngularJS bei OWASP London.

Testen Sie Ihr AngularJS-Projekt auf GitHub oder Bitbucket auf Sicherheitslücken

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

AngularJS führt standardmäßig eine automatische, kontextbezogene Ausgabekodierung und Eingabebereinigung für alle Datenwerte durch, die in das DOM eingefügt werden. Wenn Sie den „Angular-Weg“ nutzen, profitieren Sie von diesem Schutz.

Sehen wir uns einige Beispiele an.

Angulars ng-bind verwenden

Mit der Angular-Direktive ng-bind können Sie den Wert eines HTML-Elements an einen Wert binden, der im Angular-Code festgelegt wurde, beispielsweise im Controller.

Die folgende Datei view.html enthält das Angular-Template, das ng-bind verwendet, um einen Ausdruck im Angular-Code auszuwerten und seinen Wert für das HTML-div-Element darzustellen:

<div class="jumbotron" ng-controller="AboutController as about">
 <h1>About</h1>
 <p>
   Signed by:
 </p>
 <div ng-bind="about.signature"></div>
</div>

Der Controller, der den Wert für diese Ansicht bereitstellt, ist AboutController:

(function() {
 "use strict";
 angular.module("angularjs-starter").controller("AboutController", function() {
   this.signature =
     'Yours truly, Angle <img src="x" onError="alert('its me!')"/>> Bob';
 });
})();

Wie Sie sehen, wird im Signaturwert ein HTML-Injektionsversuch simuliert, der eine Browsermeldung auslösen soll. Bei der Darstellung auf dem Bildschirm kodiert Angular jedoch Zeichen wie < in ihre HTML-Entitäten. Dadurch werden sie als Text ausgegeben, statt als tatsächliches HTML-Element in das DOM eingefügt zu werden.

Angulars geschweifte Klammern verwenden

Datenwerte lassen sich auch mit Angulars Konvention doppelter geschweifter Klammern an HTML-Elementwerte binden. Die Direktive ngBind und die Schreibweise mit geschweiften Klammern funktionieren gleich, unterscheiden sich jedoch geringfügig hinsichtlich der UX.

Hier sehen Sie ein Beispiel dafür, wie Angular schädliche Daten bei Verwendung geschweifter Klammern kodiert. Zunächst fügen wir der Ansicht einen Beschreibungswert hinzu:

<div class="jumbotron" ng-controller="AboutController as about">
 <h1>About</h1>
 <p>
   {{ about.description }}
 </p>

 <p>
   Signed by:
 </p>
 <div ng-bind="about.signature"></div>
</div>

Der zugehörige Controller stellt einen Wert bereit, der Cross-Site-Scripting-Angriffe in die Seite einschleusen soll:

(function() {
 "use strict";
 angular.module("angularjs-starter").controller("AboutController", function() {
   this.signature =
     'Yours truly, Angle <img src="x" onError="alert('its me!')"/>> Bob';
   this.description =
     "hello there you <a href="javascript:alert('hello')">crazy</a> diamond";
 });
})();

Da dies auf die Angular-Art erfolgt, sehen Sie, wie Angular seine Ausgabekodierung als Gegenmaßnahme gegen Cross-Site-Scripting-Angriffe anwendet, wenn geschweifte Klammern und ngBind-Direktiven mit potenziell schädlichen Benutzereingaben verwendet werden:

Wichtigste Erkenntnis:Nutzen Sie Angulars standardmäßige Schutzmaßnahmen, um Cross-Site-Scripting-Schwachstellen (XSS) zu mindern: Interpolieren Sie Daten auf die „Angular-Art“ mit ngBind-Direktiven oder geschweiften Klammern wie {{ data }}, damit Angular standardmäßig Ausgabekodierung und Bereinigung anwendet.

2. Vermeiden Sie Eingabeinjektionen in das Angular-DOM

Missbrauch der unsicheren HTML-Bindung in Angular

Frühere AngularJS-Versionen wie 1.2 und älter verfügten über die Direktive ng-bind-html-unsafe, mit der HTML-Daten in das DOM eingefügt und neue Elemente erstellt werden konnten. Ein Anwendungsfall dafür war, DOM-Elemente direkt aus eingegebenen Daten zu erstellen und anschließend bestimmte Zeichenfolgen darin herauszufiltern, etwa Links.

Diese Methode zum Erstellen einer Daten-Blacklist ist fehleranfällig und nicht immer sicher, da mit der Zeit neue Angriffsvektoren und Methoden entdeckt werden und die Blacklist entsprechend gepflegt werden muss.

Sehen wir uns ein Beispiel an, wie ng-bind-html-unsafe HTML-Elemente in das DOM einfügt.

Ein Angular-Template:

<div ng-controller="AboutController" ng-app>
  <span>{{email}}</span>
  <div ng-bind-html-unsafe="link">
  </div>
</div>

Und der zugehörige Angular-Controller für die Ansicht:

function AboutController($scope) {
  $scope.email = 'Email me:'
  $scope.link = "<a href='javascript:alert(1)'>Contact me</a>"
}

Die gerenderte HTML-Ansicht enthält „Kontaktieren Sie mich“ als tatsächlichen Link, der beim Anklicken eine Warnmeldung auslöst:

Missbrauch von Angular Strict Contextual Escaping

Mit AngularJS 1.2 wurde die Direktive ng-bind-html-unsafe als veraltet markiert und stattdessen Strict Contextual Encoding (SCE) eingeführt. SCE ermöglicht das Escaping und die Bereinigung von Daten anhand eines Kontexts, jedoch nicht anhand der Daten eines bestimmten HTML-Elements.

Es gibt jedoch Möglichkeiten, die Kodierung zu umgehen und anzunehmen, dass die bereitgestellten Daten sicher verwendet werden können. Möglich ist das mit den Angular-Methoden $sce.trustAsHtml() und $sce.trustAs(type, value).

Darüber hinaus lässt sich mit $sceProvider.enabled(false) die kontextbezogene Escaping-Funktion global deaktivieren und die Bereinigung überspringen, sodass Eingaben als vertrauenswürdig behandelt werden. Auch das ist eine schlechte Praxis. Wir empfehlen, dies nur bei wirklich guten Gründen zu tun und andere Gegenmaßnahmen und Schutzvorkehrungen einzusetzen.

Betrachten wir das folgende Beispiel, das Nutzern das Erstellen von Links ermöglichen soll, dabei aber Cross-Site-Scripting-Schwachstellen einführt. Das Angular-Template dazu:

<html>
  <body ng-app='myApp'>
    <div ng-controller="AboutController">
      <span>{{email}}</span>
      <div ng-bind-html="link | stripDangerousHTML">
      </div>
    </div>
  </body>
</html>

Der Angular-Controller lautet:

var myApp = angular.module('myApp', []);

myApp.filter('stripDangerousHTML', function($sce) {
  return function(value) {
    let dataInput = value
    dataInput = dataInput
      .replace(/javascript/g, '')
      .replace(/alert/g, '');
    return $sce.trustAsHtml(dataInput);
  }
})

myApp.controller('AboutController', function($scope) {
  // this is filtered ok:
  // const emailAddress = 'javascript:alert(1)'
  // but is this??
  const emailAddress = `jav
ascript:al
ert(1);`
  $scope.email = 'Email me:'
  $scope.link = `Hi there, <a href="${emailAddress}">Contact me</a>`
});

Mit dem Angular-Filter stripDangerousHTML stellt ein Entwickler sicher, dass kein schädlicher JavaScript-Code im href-Attribut landet und dieses nur für E-Mail-Adressen bereinigt wird.

Wenn die vom Nutzer bereitgestellte Eingabe für emailAddress 'javascript:alert(1)' lautet, funktioniert mein auf regulären Ausdrücken basierender Musterabgleich sehr gut. Bei einer vom Nutzer bereitgestellten Eingabe wie jav ascript:al ert(1); funktioniert er jedoch nicht so gut. Diese konkrete Eingabe umgeht den Musterabgleich und ergibt eine gültige JavaScript-Anweisung, die zu einer XSS-Schwachstelle führt.

Wichtigste Erkenntnis:Vermeiden Sie Eingabeinjektionen in das Angular-DOM, die Schwachstellen verursachen können.

• Verwenden Sie in Angular 1.2 und älter nicht die Direktive ng-bind-html-unsafe.

• Vertrauen Sie in Angular 1.2 und höher Benutzereingaben nicht blind mit Methoden aus der Sammlung Strict Contextual Escaping, etwa $sce.trustAsHtml(value).

3. Vermeiden Sie das dynamische Laden von Angular-Templates aus nicht vertrauenswürdigen Quellen

Angular-Code verwendet ständig Angular-Templates. Diese HTML-Templates sehen so aus:

<div>
  Hello, {{ name }}
</div>

Meistens werden Angular-Templates aus Dateien zusammengesetzt, die beim Build an eine Angular-Anwendung gebunden werden. Es ist jedoch auch möglich, diese HTML-Templates zur Laufzeit clientseitig verzögert zu laden, indem eine Anfrage zum Herunterladen des Templates gesendet und dieses dynamisch ausgewertet wird.

Dadurch besteht jedoch das Risiko, Templates unsicher von nicht vertrauenswürdigen Domains zu laden, die außerhalb der Kontrolle und Vertrauenswürdigkeit der Webanwendung liegen. Entwickler sollten außerdem darauf achten, Templates über sichere Protokolle wie aktuelle TLS-Versionen abzurufen, um Man-in-the-Middle-Angriffe zu mindern.

Ein Beispiel dafür, wie ein Angular-Template dynamisch über das Netzwerk geladen wird:

angular.module(‘myModule’)
  .component(‘myComponent’, {
     templateUrl: ‘/path/to/template.html’,
     controller: function() {}
   });

Angular bietet eine Möglichkeit, die Kontrolle über Template-Ressourcen festzulegen. In der offiziellen Dokumentation wird dies treffend beschrieben:

Mit dem $sceDelegateProvider können die Whitelists und Blacklists festgelegt und abgerufen werden, die sicherstellen, dass die URLs für AngularJS-Templates und andere URLs, die Skripte ausführen, sicher sind (alle Stellen, an denen der $sce.RESOURCE_URL-Kontext verwendet wird).

Wenn Ihr Angular-Anwendungscode den SCE-Delegationsprovider verwendet, sollten Sie die Konfiguration der Ressourcen-Whitelist sorgfältig prüfen:

• Verwenden Sie HTTPS als sicheres Protokoll, um die Remote-Templates abzurufen, und stellen Sie sicher, dass der Remote-Endpunkt aktuell konfiguriertes TLS unterstützt.

• Vermeiden Sie die Verwendung des Platzhalters mit zwei Sternchen ** für Domains oder Protokolle.

• Erstellen Sie bei Bedarf eine Blacklist als zusätzliche Schutzmaßnahme.

4. Open-Redirect-Schwachstellen in AngularJS

Die nativen Browser-APIs ermöglichen die Seitennavigation, etwa über $window.location. Angular abstrahiert die Navigation mit dem Service-Provider $location und stellt Methoden wie $location.url(), $location.path() und $location.hash(), sowie weitere bereit, um auf die aktuelle Navigations-URL zuzugreifen und sie bei Bedarf zu synchronisieren.

Möglicherweise enthält Ihr Angular-Code eine Navigation, die auf URL-Abfrageparametern oder anderen URL-bezogenen Daten basiert.

Betrachten Sie das folgende Beispiel:

myApp.controller('AboutController', function($scope, $location) {
    $scope.submit = function() {
       const referer = $location.hash()
     }

     window.location.href = referer
});

Dieser Angular-Code soll eine URL parsen, zum Beispiel https://www.example.com/path/to/this#referer, und sie als Grundlage für die Navigation zu einer anderen Seite verwenden.

Da die URL-Adresse jedoch vom Nutzer der Webanwendung kontrolliert wird, kann dieser den Hash auf gültigen JavaScript-Code setzen, zum Beispiel https://www.example.com/path/to/this#javascript:alert(1) – und diese URL ausführen.

Ebenso würde das Setzen von window.location.href auf eine Benutzereingabe – beispielsweise auf das JavaScript-Injektionsbeispiel im Hash – zum gleichen Ergebnis führen.

Grundlagen der AngularJS-Sicherheit

Best Practices zur Vermeidung von Open Redirects und JavaScript-Code-Injection:

1. Vermeiden Sie die Seitennavigation auf Grundlage absoluter Benutzereingaben.

2. Wenn eine Seitennavigation auf Grundlage von Benutzereingaben erforderlich ist, verwenden Sie Wörterbuchzuordnungen, um die Benutzereingabe einer Seite oder URL zuzuordnen.

3. Verketten Sie niemals Benutzereingaben mit URLs für die Seitennavigation.

Wichtigste Erkenntnis:Vermeiden Sie Open-Redirect-Fallen, indem Sie Benutzereingaben direkt für die Seitennavigation verwenden.

• Vermeiden Sie Muster wie window.location.href = $location.hash, die potenziell zu JavaScript-Code-Injection-Angriffen führen.

• Verwenden Sie Wörterbuchzuordnungen, um anhand von Benutzereingaben durch Seiten zu navigieren.

5. Angular-Code-Injection auf der Serverseite

Der serverseitige Code bereinigt oder kodiert zwar schädliche HTML-Entitäten wie Skripte, kennt aber den clientseitigen AngularJS-Kontext nicht. Angreifer können daher einen Angular-Template-Ausdruck bereitstellen, etwa geschweifte Klammern mit zusätzlichem JavaScript-Payload, der zur Laufzeit clientseitig ausgewertet wird und einen Injektionsangriff ermöglicht.

Best Practices zur Minderung serverseitiger Angular-Code-Injection:

• Vermeiden Sie die Vermischung serverseitiger und clientseitiger Templates. Verwenden Sie Templates stattdessen nur in einem Anwendungskontext: entweder serverseitig oder clientseitig.

• Begrenzen Sie den Geltungsbereich der Direktive ng-app vom HTML-Dokumentkörper auf den Kontext eines bestimmten DOM-Elements innerhalb der Seite.

• Binden Sie die Daten aus dem Template mit ng-bind oder ng-bind-html, damit Benutzereingaben mit der Unterstützung dieser Angular-Direktiven für Ausgabekodierung und Bereinigung korrekt verarbeitet werden.

• Verwenden Sie ng-non-bindable, damit Angular die Daten nicht als auszuwertenden Ausdruck behandelt und so Angular-Code-Injection verhindert wird.

Wichtigste Erkenntnis:Mindern Sie serverseitige Angular-Code-Injection.

6. Vermeiden Sie die jQuery-kompatible Angular-.element-API zur Manipulation des DOM

Angular stellt eine angular.element()-API bereit, die jQuery-ähnliche API-Kompatibilität (jqLite) bietet, um den DOM direkt abzufragen und zu manipulieren.

Das mag wie eine praktische Möglichkeit erscheinen, auf den DOM zuzugreifen und mit ihm zu interagieren. Allerdings entstehen dadurch potenzielle Injection-Schwachstellen, da Inhalte unsicher in den DOM eingefügt werden.

Betrachten Sie die folgende einfache Angular-Vorlage:

    <div ng-controller="AboutController">
      <span id=”content”>{{content}}</span>
    </div>

Der folgende Angular-Controller verwendet angular.element(), um die Seite zu manipulieren:

function AboutController($scope) {
  const element = angular.element(‘#content’)
  element.after($scope.content)
}

Das Problem liegt hier bei element.after(), das den Inhalt von $scope.content ohne Kodierung oder Bereinigung in den DOM einfügt, da es mit der jQuery-eigenen after-API kompatibel ist. Enthält der Wert dieser Variablen bösartige Inhalte, greifen die Angular-Schutzmaßnahmen nicht – und Sie sind potenziell für XSS anfällig.

Weitere Informationen zu angular.element finden Sie in der offiziellen Dokumentation von Angular unter https://docs.angularjs.org/api/ng/function/angular.element.

Wichtigste Erkenntnis: Vermeiden Sie die jQuery-kompatible Angular-API angular.element() zur Manipulation des DOM, da durch das direkte Erstellen von HTML-Elementen im DOM potenzielle Cross-Site-Scripting-Schwachstellen entstehen.

7. Verwenden Sie Angular-Security-Linter

Linter sind in der JavaScript-Entwicklung weit verbreitet. Entwickler verwenden häufig beliebte Projekte wie ESLint zusammen mit Plugins, die dessen Funktionen erweitern. Das Projekt eslint-plugin-angular unterstützt allgemeine Angular-Codierkonventionen und -Richtlinien. Es enthält auch einige Sicherheitsregeln, darunter no-jquery-angularelement, die das Umhüllen von angular.element-Objekten mit jQuery oder $ untersagt.

Ein Beispiel dafür, wie das ESLint-Plugin Probleme erkennt, laut offizieller Dokumentation:

/*eslint angular/no-jquery-angularelement: 2*/
// invalid
$(angular.element("#id")) // error: angular.element returns already a jQLite element. No need to wrap with the jQuery object

// invalid
jQuery(angular.element("#id")) // error: angular.element returns already a jQLite element. No need to wrap with the jQuery object

Wenn Sie nicht sicher sind, warum die Verwendung von angular.element() ein Sicherheitsproblem darstellt, empfehlen wir Ihnen, den vorherigen Abschnitt zu lesen: Vermeiden Sie die jQuery-kompatible Angular-.element-API zur Manipulation des DOM.

Wichtigste Erkenntnis:Verwenden Sie statische Codeanalyse-Tools, um unsicheren Code automatisch zu finden und Entwickler früh im Entwicklungsprozess darauf hinzuweisen. Zu den Security-Linters, die zu den AngularJS-Sicherheitsgrundlagen gehören, zählen:

• eslint-plugin-scanjs-rules

• eslint-plugin-angular untersagt die Verwendung von angular.element()

8. Scannen Sie Angular-Komponenten von Drittanbietern auf Schwachstellen und beheben Sie diese

Wahrscheinlich verwenden Sie zusätzlich zum Angular-Kern und seinen erweiterten Komponenten Open-Source-Pakete, um Ihre Webanwendung zu erstellen. Tatsächlich weist auch das AngularJS-Projekt selbst Schwachstellen auf. Laut einer Studie von Snyk zu JavaScript-Frameworks und Sicherheit hat AngularJS im Versionszweig Angular 1.x über 20 Sicherheitsschwachstellen.

Auch die Abhängigkeiten, die Sie zum Erstellen Ihrer Angular-basierten Webanwendung verwenden, können Sicherheitsschwachstellen aufweisen. Wie die folgende Tabelle zeigt, gibt es für einige dieser Schwachstellen bis heute nicht einmal eine verfügbare Behebung.

Nach Schwachstellen suchen

Sie suchen einen AngularJS-Sicherheitsscanner? Mit Snyk können Sie AngularJS-Sicherheitstests durchführen und bei Schwachstellen in Ihrem Frontend-Projekt auf dem Laufenden bleiben. Verbinden Sie dazu Ihre GitHub- oder Bitbucket-Projekte mit Snyk – so findet Snyk automatisch Schwachstellen und erstellt Pull Requests mit Korrekturen für Sie.

Eine weitere schnelle Möglichkeit, loszulegen und AngularJS-Sicherheitsprobleme zu erkennen, bietet die Snyk-CLI:

npm install -g snyk
snyk test

Bei einem Snyk-Test meldet Snyk die gefundenen Schwachstellen und zeigt die anfälligen Pfade an. So können Sie den Abhängigkeitsbaum nachverfolgen und nachvollziehen, welches Modul eine Schwachstelle eingeführt hat.

Wenn Sie npm audit verwenden, haben Sie wahrscheinlich alle von Snyk gemeldeten AngularJS-Sicherheitsschwachstellen übersehen. npm audit übersieht auch alle drei React-Schwachstellen und vermittelt Entwicklern damit ein falsches Sicherheitsgefühl.

Quelle: https://snyk.io/blog/angular-vs-react-security-bakeoff-2019/

Snyk liefert Ihnen konkrete Empfehlungen zur Behebung, damit Sie auf eine korrigierte Version aktualisieren können – über einen automatisierten Pull Request, den Snyk in Ihrem Repository erstellt. Wenn keine Korrektur verfügbar ist, können Sie auch einen von Snyk bereitgestellten Patch anwenden, um die Schwachstelle einzudämmen.

Wenn Sie einen AngularJS-Sicherheitsscanner suchen, sollten Sie mit Snyk beginnen. Damit können Sie Ihre Open-Source-Abhängigkeiten nachverfolgen, sich benachrichtigen lassen und Schwachstellen beheben, sobald sie entdeckt werden.

Wichtigste Erkenntnis:AngularJS weist bis heute über 20 Schwachstellen auf. Außerdem gibt es Angular-Komponenten mit Millionen Downloads, die weiterhin anfällig sind.

• Verbinden Sie Snyk mit GitHub oder anderen SCMs, um Ihre Projekte optimal in CI/CD zu integrieren.

• Snyk findet Schwachstellen in den Komponenten von Drittanbietern, die Sie verwenden, und erstellt Pull Requests mit Korrekturen. So können Sie das Versions-Update übernehmen und das Risiko mindern.

9. Integrierte CSRF-Unterstützung für Angular-Anwendungen

Bei einer Cross-Site-Request-Forgery (CSRF, XSRF) handelt es sich um einen Web-Sicherheitsangriff, bei dem Benutzer dazu gebracht werden, unbeabsichtigte Aktionen auszuführen – beispielsweise eine API-Anfrage zu senden, die ein Formular übermittelt.

Eine Möglichkeit, CSRF-Schwachstellen einzudämmen, ist der Einsatz zufällig generierter Tokens oder – noch besser – kryptografischer Nonces, mit denen sich überprüfen lässt, ob einer Anfrage vertraut werden kann.

Angular bietet eine integrierte Unterstützung für CSRF-Tokens. Dabei liest Angular Cookies mit bestimmten Namenskonventionen, etwa XSRF-TOKEN, die vom Server gesendet werden, und fügt ihren Wert weiteren HTTP-Anfragen der Angular-Anwendung hinzu.

Die gesamte Verarbeitung von CSRF-Tokens erfolgt in AngularJS über den $http-Dienst. In neueren Angular-Versionen wird sie auch über den HttpClient im offiziell unterstützten Modul @angular/common/http bereitgestellt. Darüber hinaus können Sie den Namen des CSRF-Token-Cookies und das allgemeine Verhalten über die API $http.xsrfCookieName und weitere APIs konfigurieren.

Wichtigste Erkenntnis:Angular unterstützt die Verarbeitung von CSRF-Tokens auf der Clientseite über den integrierten $http-Dienst. Verwenden Sie diesen Dienst, anstatt eine eigene Lösung zu entwickeln.

10. Integrierte CSP-Kompatibilität von Angular

Einige Angular-Funktionen stehen im Konflikt mit gängigen CSP-Einschränkungen, etwa dem Verbot der Auswertung von inline eingefügtem JavaScript-Code. Anstatt CSP vollständig zu deaktivieren – was nicht empfohlen wird –, bietet Angular jedoch die Direktive ngCsp, die die Kompatibilität mit der CSP-Konfiguration ermöglicht.

Content Security Policy (CSP) ist ein Webstandard, mit dem sich Vertrauensrichtlinien festlegen lassen. Sie wird hauptsächlich als zusätzliche Schutzebene eingesetzt, um die Sicherheit zu erhöhen und Probleme wie eine (XSS-)Injection einzudämmen.

AngularJS verfügt über integrierte CSP-Kontrollen. Wenn sie aktiviert sind, müssen jedoch einige Funktionen ausgeschlossen werden – beispielsweise Inline-Skripte und Ausdrücke, da eval() nicht zulässig ist. Einige AngularJS-Funktionen benötigen dies intern dennoch.

Eine empfehlenswerte Lektüre zu CSP finden Sie auf der Mozilla-Website sowie in der Angular-API-Dokumentation zur ngCsp-Direktive.

Wichtigste Erkenntnis:Die Implementierung einer Content Security Policy (CSP) ist ein wichtiger Schritt, um eine zusätzliche Sicherheitsebene einzurichten – insbesondere, weil sie dazu beiträgt, Cross-Site-Scripting-Angriffe einzudämmen.

10 grundlegende Best Practices für die AngularJS-Sicherheit:

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

2. Vermeiden Sie die Injection von Eingaben über den Angular-DOM

3. Laden Sie Angular-Vorlagen nicht dynamisch aus nicht vertrauenswürdigen Quellen

4. Open-Redirect-Schwachstellen in AngularJS

5. Angular-Code-Injection auf der Serverseite

6. Vermeiden Sie die jQuery-kompatible Angular-.element-API zur Manipulation des DOM

7. Verwenden Sie Angular-Security-Linter

8. Scannen Sie Angular-Komponenten von Drittanbietern auf Schwachstellen und beheben Sie diese

9. Integrierte CSRF-Unterstützung für Angular-Anwendungen

10. Integrierte CSP-Kompatibilität von Angular

Laden Sie den Spickzettel mit Best Practices für die AngularJS-Sicherheit herunter!