Sebastian Viereck

Dependency-Check-Tools sind Werkzeuge, die dabei helfen, die Abhängigkeiten eines Softwareprojekts zu analysieren und zu verwalten. Sie sind besonders nützlich in modernen Softwareprojekten, die oft Dutzende, wenn nicht Hunderte von Abhängigkeiten haben können.

Die Hauptfunktionen von Dependency-Check-Tools umfassen:

1. Erkennung von veralteten Abhängigkeiten: Tools können Benutzer darauf hinweisen, wenn eine Abhängigkeit aktualisiert werden muss, oft mit Informationen darüber, welche neuen Funktionen oder Sicherheitsupdates die neue Version beinhaltet.
2. Sicherheitsanalyse: Einige Tools können über bekannte Sicherheitslücken in den verwendeten Bibliotheken informieren. Dies ist besonders wichtig, da die Verwendung von Bibliotheken mit Sicherheitslücken ein erhebliches Risiko darstellen kann.

Zu den Dependency-Check-Tools, die mit Angular-Projekten verwendet werden können, gehören:

• npm audit: Diese Funktion ist in npm (Node Package Manager) eingebaut, dem Standardpaketmanager für Node.js, der häufig in Angular-Projekten verwendet wird. npm audit kann über bekannte Sicherheitslücken in den Projektabhängigkeiten informieren.
• Dependabot: Ein von GitHub bereitgestelltes Tool, das Sicherheitslücken und veraltete Abhängigkeiten in einem Projekt erkennen kann. Es kann auch automatisch Pull-Anfragen erstellen, um Abhängigkeiten auf die neuesten Versionen zu aktualisieren. Achtung: nur auf GitHub verfügbar
• Snyk: Ein weiteres Tool, das Sicherheitslücken in Abhängigkeiten erkennt und auch Patches für diese Lücken anbieten kann. Snyk kann in den CI/CD-Prozess integriert werden und unterstützt auch eine breite Palette von Sprachen und Paketmanagern.
• OWASP Dependency-Check: Dies ist ein spezialisierteres Tool, das insbesondere auf das Auffinden bekannter Sicherheitslücken in den Abhängigkeiten eines Projekts abzielt. Es ist Teil des OWASP (Open Web Application Security Project) und kann eine Vielzahl von Sprachen und Paketmanagern unterstützen.

npm audit

npm audit erkennt und updatet npm Packete um Sicherheitslücken zu entfernen und ist Teil von npm und kann auch verwendet werden, wenn yarn als Packetmanager verwendet wird.

npm audit
# ng audit report

quill  <=1.3.7
Severity: moderate
Cross-site Scripting in quill - https://github.com/advisories/GHSA-4943-9vgg-gr5r
No fix available
node_modules/quill
  ngx-quill  *
  Depends on vulnerable versions of quill
  node_modules/ngx-quill

semver  <=5.7.1 || 6.0.0 - 6.3.0 || 7.0.0 - 7.5.1
Severity: moderate
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
fix available via `npm audit fix --force`
node_modules/less/node_modules/semver
node_modules/make-dir/node_modules/semver
  @angular/cli  9.1.0-next.0 - 14.2.11 || 15.0.0-next.0 - 15.2.8 || 16.0.0-next.0 - 16.1.1
  Depends on vulnerable versions of semver
  node_modules/@angular/cli

4 moderate severity vulnerabilities

To address all issues possible, run:
  npm audit fix --force

Some issues need review, and may require choosing
a different dependency.

Der Output von npm audit liefert Informationen über Sicherheitsprobleme in den abhängigen Paketen eines Node.js-Projekts. Hier ist eine Erklärung des gegebenen Outputs:

1. quill <=1.3.7:

• Schweregrad: moderat
• Beschreibung: Es wurde eine Cross-Site-Scripting-Schwachstelle in der Version 1.3.7 und älter von „quill“ festgestellt. Der Link führt zu weiteren Informationen über diese Schwachstelle.
• Keine verfügbare Lösung.
• Abhängigkeit in node_modules/ngx-quill, die von ngx-quill genutzt wird.

1. semver <=5.7.1 || 6.0.0 - 6.3.0 || 7.0.0 - 7.5.1:

• Schweregrad: moderat
• Beschreibung: Die Versionen von „semver“ zwischen 5.7.1 und 6.3.0 sowie zwischen 7.0.0 und 7.5.1 sind anfällig für sogenannte „Regular Expression Denial of Service“-Angriffe (ReDoS). Der Link führt zu weiteren Informationen über diese Schwachstelle.
• Eine Lösung ist verfügbar, die mit dem Befehl npm audit fix --force angewendet werden kann.
• Abhängigkeiten in node_modules/less/node_modules/semver und node_modules/make-dir/node_modules/semver, die von @angular/cli genutzt werden.

Am Ende der Ausgabe werden insgesamt 4 Schwachstellen mit moderatem Schweregrad angegeben. Um alle möglichen Probleme zu beheben, wird empfohlen, den Befehl npm audit fix --force auszuführen. Es wird auch darauf hingewiesen, dass einige Probleme eine manuelle Überprüfung erfordern können und eine alternative Abhängigkeit ausgewählt werden muss.

snyk

Snyk liefert eine umfangreiche Schwachstellenanalyse von Open Source npm Packeten.

Testing project dependencies...
⚠ Found 3 vulnerabilities in 'lodash' package:
  - Severity: High, CVE-2021-23337, Prototype Pollution
  - Severity: Medium, CVE-2022-12345, Cross-Site Scripting (XSS)
  - Severity: Low, CVE-2023-9876, Denial of Service (DoS)

⚠ Found 1 vulnerability in 'express' package:
  - Severity: Medium, CVE-2023-4567, Cross-Site Request Forgery (CSRF)

Testing project files...
✓ Tested 243 files for known vulnerabilities, no vulnerabilities found.

Overall test results:
⚠ Tested 395 dependencies and files, found 4 vulnerabilities.

In diesem Beispiel wurden einige Sicherheitslücken in den Abhängigkeiten ‚lodash‘ und ‚express‘ gefunden. Es gibt drei Schwachstellen in der ‚lodash‘-Version, die als hoch, mittel und niedrig eingestuft sind und verschiedene Arten von Angriffen ermöglichen können, wie z.B. die Beeinflussung von Prototypen (Prototype Pollution) oder Denial-of-Service-Angriffe (DoS). Zusätzlich wurde eine mittlere Schwachstelle in der ‚express‘-Version gefunden, die Cross-Site Request Forgery (CSRF) ermöglichen könnte.

Snyk bietet einige Funktionen, die über die Standardfunktionen von „npm audit“ hinausgehen. Hier sind einige Bereiche, in denen Snyk als Sicherheitstool Vorteile gegenüber „npm audit“ bieten kann:

1. Erweiterte Schwachstellenanalyse: Snyk verwendet umfangreiche Sicherheitsdatenbanken und -quellen, um Sicherheitslücken in Abhängigkeiten zu identifizieren. Es kann potenzielle Schwachstellen entdecken, die von „npm audit“ möglicherweise nicht erkannt werden.
2. Zusätzliche Sicherheitsinformationen: Snyk liefert detailliertere Informationen zu Schwachstellen, einschließlich Schweregrad, Auswirkungen und Lösungsvorschlägen. Dadurch erhalten Sie einen besseren Einblick in die Sicherheitsprobleme und können gezieltere Maßnahmen ergreifen.
3. Integration in den Entwicklungsprozess: Snyk kann nahtlos in Ihren Entwicklungsprozess integriert werden, einschließlich CI/CD-Pipelines. Es ermöglicht Ihnen, automatisierte Sicherheitsscans durchzuführen und Schwachstellen frühzeitig zu erkennen.
4. Kontinuierliche Überwachung: Snyk bietet die Möglichkeit, Ihre Abhängigkeiten kontinuierlich auf neue Schwachstellen zu überwachen. Sie erhalten Benachrichtigungen über neu entdeckte Schwachstellen und empfohlene Maßnahmen zur Behebung.
5. Multi-Language-Unterstützung: Snyk unterstützt nicht nur JavaScript und Node.js, sondern auch eine Vielzahl anderer Programmiersprachen und Plattformen. Das bedeutet, dass Sie eine einheitliche Sicherheitslösung für verschiedene Teile Ihres Projekts verwenden können, wenn Sie neben Angular auch andere Technologien einsetzen.

Es ist wichtig zu beachten, dass „npm audit“ weiterhin eine nützliche Funktion ist, um bekannte Schwachstellen zu erkennen. Snyk bietet jedoch zusätzliche Funktionen, die eine umfassendere Schwachstellenanalyse, Integration in den Entwicklungsprozess und kontinuierliche Überwachung ermöglichen. Es ist empfehlenswert, beide Tools in Kombination zu verwenden, um das Sicherheitsniveau Ihrer Anwendung zu maximieren.

OWASP dependency-check-cli

Der OWASP Dependency-Check CLI ist ein Werkzeug zur Überprüfung von Abhängigkeiten auf Sicherheitslücken. Hier ist ein Beispiel für einen möglichen Output mit gefundenen Problemen:

[INFO] --------------------------------------------------
[INFO] OWASP Dependency-Check CLI (version 6.2.2)
[INFO] --------------------------------------------------

[INFO] Initializing... (this may take a moment)
[INFO] Loading NVD data...
[INFO] NVD data loaded successfully.

[INFO] Scanning project dependencies...
[INFO] Found 253 dependencies to analyze.

[INFO] Analyzing dependencies...
[INFO] Found 5 vulnerabilities:

- CVE-2021-1234 (Medium Severity)
    Description: Cross-Site Scripting (XSS) vulnerability in library A version 1.2.3
    Recommendation: Upgrade to library A version 1.2.4

- CVE-2022-5678 (High Severity)
    Description: Remote Code Execution (RCE) vulnerability in library B version 2.0.1
    Recommendation: Upgrade to library B version 2.0.2

- CVE-2023-9876 (Critical Severity)
    Description: SQL Injection vulnerability in library C version 3.4.5
    Recommendation: Upgrade to library C version 3.4.6 or apply the provided patch

[INFO] Analysis completed.

[INFO] Summary:
- Total Dependencies: 253
- Vulnerable Dependencies: 5
- Highest CVSS Score: 9.8 (Critical)

[INFO] Build finished.

In diesem Beispiel wurde ein Projekt mit 253 Abhängigkeiten gescannt. Es wurden 5 Sicherheitslücken gefunden, darunter Cross-Site Scripting (XSS), Remote Code Execution (RCE) und SQL Injection. Jede Schwachstelle enthält Informationen wie die CVE-Nummer, die Schwere der Schwachstelle, eine Beschreibung und Empfehlungen zur Behebung.

Der CVSS-Score (Common Vulnerability Scoring System) von 9.8 weist auf eine sehr hohe Schwere einer Sicherheitslücke hin. CVSS-Scores werden verwendet, um die Schwere von Sicherheitslücken zu bewerten und reichen von 0 bis 10.

Ein CVSS-Score von 9.8 zeigt an, dass die Sicherheitslücke als kritisch eingestuft wird und ein erhebliches Risiko darstellt. Es bedeutet, dass die Schwachstelle potenziell ausgenutzt werden kann, um erheblichen Schaden anzurichten, Daten zu stehlen, unautorisierten Zugriff zu ermöglichen oder Systeme komplett zu kompromittieren.

Angular bietet einige eingebaute Sicherheitsmaßnahmen, aber es gibt auch mehrere Tools und Praktiken, die helfen können, die Sicherheit einer Angular-Anwendung zu erhöhen:

1. Inhalts-Sicherheitsrichtlinie (Content Security Policy, CSP): Diese Richtlinie hilft, Cross-Site-Scripting (XSS)-Angriffe zu verhindern, indem sie regelt, welche Ressourcen in Ihrer Webanwendung geladen werden dürfen. Zum Artikel
2. HTTP Strict Transport Security (HSTS): Dieser Mechanismus zwingt Webbrowser dazu, nur sichere HTTPS-Verbindungen zu verwenden, was Man-in-the-Middle-Angriffe erschwert. Zum Artikel
3. HTTPOnly und Secure Cookies: Diese Einstellungen verhindern, dass Cookies von JavaScript (also durch Cross-Site-Scripting) ausgelesen werden und sicherstellen, dass Cookies nur über HTTPS versendet werden. Zum Artikel
4. Angular’s Cross Site Request Forgery (XSRF) Schutz: Angular bietet einen eingebauten Schutz gegen XSRF- oder CSRF-Angriffe in der HttpClient-Bibliothek. Zum Artikel
5. Tools für statische Code-Analyse wie SonarQube und ESLint: Diese Tools können dabei helfen, sicherheitsrelevante Programmierfehler aufzudecken. Zum Artikel
6. Automatisierte Sicherheitsscanner wie OWASP ZAP: Dieses Tool kann Ihre Webanwendung auf bekannte Sicherheitsprobleme prüfen. Zum Artikel
7. Dependency-Check-Tools wie Snyk, Dependabot oder OWASP Dependency-Check: Diese Tools können Ihre Projektabhängigkeiten überwachen und Sie auf Sicherheitsprobleme oder veraltete Pakete hinweisen. Zum Artikel
8. Angular’s eingebaute DOM-Sanitization: Angular hat einen Mechanismus, um sicherzustellen, dass nur sicherer, „gesäuberter“ Code in den DOM eingefügt wird, um XSS-Angriffe zu verhindern.
9. Subresource Integrity (SRI): Angular bietet einen Mechanismus an um die Integrität von der eigenen JavaScript und CSS Dateien zu gewährleisten. Zum Artikel

Außerdem gibt es Coding Best Practises für die sichere Programmierung von sicherheitsrelevanten Themen:

1. Unsichere Verarbeitung von Benutzereingaben: Wenn Benutzereingaben nicht ordnungsgemäß validiert und verarbeitet werden, kann dies zu Sicherheitslücken führen, wie z.B. SQL-Injektionen oder Remote-Code-Ausführung.
2. Unsichere Authentifizierung und Autorisierung: Unzureichende oder fehlerhafte Implementierung von Authentifizierungs- und Autorisierungsmechanismen kann zu unbefugtem Zugriff auf geschützte Bereiche der Anwendung führen.
3. Unsichere Speicherung von Benutzerdaten: Wenn Benutzerdaten nicht sicher gespeichert werden, z. B. durch unsichere Verschlüsselung oder Speicherung in ungeschützten Bereichen, können sie gestohlen oder manipuliert werden.
4. Unsichere Dateiuploads: Unsichere Verarbeitung von Dateiuploads kann dazu führen, dass Angreifer schädlichen Code hochladen und ausführen können.
5. Unsichere Weiterleitungen und Umleitungen: Unsichere Weiterleitungen und Umleitungen können von Angreifern ausgenutzt werden, um Benutzer auf bösartige Websites umzuleiten oder Phishing-Angriffe durchzuführen.

HTTPOnly und Secure Flags sind Optionen, die vom Server verwendet werden, um die Sicherheit von Cookies zu erhöhen.

Ein HTTPOnly Cookie kann nicht von JavaScript-Code gelesen werden; es wird nur an den Server geschickt. Das hilft, sich gegen Cross-Site Scripting (XSS) Angriffe zu schützen.

Ein Secure Cookie wird nur über eine sichere HTTPS-Verbindung gesendet. Das hilft, sich gegen Man-in-the-middle-Angriffe zu schützen.

Die Cookies können mit bspw. PHP so gesetzt werden:

setcookie('foo', 'bar', [
    'expires' => time() + 3600, // 1h gültig
    'path' => "/", // Verfügbar für die gesamte Website
    'secure' => true, // Nur über HTTPS übertragen
    'httponly' => true, // Nur über HTTP/HTTPS, kein Zugriff für JavaScript
]);

Cookies mit Angular

Sie können zwar in Angular Cookies setzen können, aber die Flags Secure und HttpOnly können nur serverseitig gesetzt werden. Deshalb sollten Sie immer sorgfältig abwägen, welche Informationen Sie in clientseitigen Cookies speichern. Allgemein sollten keine sensiblen Informationen in solchen unsicheren Cookies gespeichert werden. Sie sollten niemals direkt sensible Daten wie Passwörter oder personenbezogene Daten in Cookies speichern. Stattdessen sollten Sie eine Session-ID speichern, die auf dem Server verwendet wird, um den entsprechenden Benutzer oder die entsprechenden Daten zu identifizieren.

Wie sollte der Session Cookie gespeichert werden?

Session-Cookies enthalten normalerweise sensitive Informationen und sollten daher sicher gespeichert werden. Hier sind einige allgemeine Richtlinien zum Speichern von Session-Cookies:

1. HttpOnly: Das HttpOnly-Flag sollte immer gesetzt werden. Dies bedeutet, dass das Cookie nicht von clientseitigem JavaScript abgerufen und geändert werden kann, was hilft, Cross-Site-Scripting-(XSS)-Angriffe zu verhindern.
2. Secure: Das Secure-Flag sollte immer gesetzt werden. Dies bedeutet, dass das Cookie nur über eine HTTPS-Verbindung gesendet wird, was hilft, Man-in-the-middle-Angriffe zu verhindern.
3. SameSite: Das SameSite-Attribut sollte, wenn möglich, auf „Strict“ oder zumindest auf „Lax“ gesetzt werden. Dies verhindert, dass das Cookie bei Cross-Site-Requests gesendet wird, was hilft, Cross-Site-Request-Forgery-(CSRF)-Angriffe zu verhindern.

Die Cookie SameSite-Eigenschaften im Allgemeinem

SameSite ist ein Attribut von Cookies, das angibt, wie sie in Cross-Site-Anfragen behandelt werden sollen. Es gibt drei mögliche Werte für die SameSite-Eigenschaft: „Strict“, „Lax“ und „None“. Jeder Wert hat unterschiedliche Auswirkungen auf das Verhalten von Cookies. Leider kann man nicht generell einen Default Wert verwenden, sondern sollte abhängig vom Use Case des einzelnen Cookie entscheiden, welcher am besten geeignet ist.

1. SameSite=Strict:
   Wenn die SameSite-Eigenschaft auf „Strict“ gesetzt ist, wird das Cookie nur an dieselbe Ursprungsseite gesendet, von der es stammt. Das bedeutet, dass das Cookie nicht in Cross-Site-Anfragen, wie zum Beispiel Klicks auf Links von einer anderen Website, gesendet wird. Es bietet eine hohe Sicherheit, da es das Risiko von Cross-Site Request Forgery (CSRF) reduziert. Allerdings kann es dazu führen, dass einige Funktionen, die auf Cookies von Drittanbietern angewiesen sind, möglicherweise nicht mehr wie erwartet funktionieren.
2. SameSite=Lax:
   Bei der SameSite-Eigenschaft „Lax“ werden Cookies in Cross-Site-Anfragen nur eingeschränkt gesendet. Das Cookie wird jedoch an die Zielseite gesendet, wenn es sich um einen „Top-Level-Navigation“ handelt, z.B. wenn der Benutzer auf einen Link klickt, der zu einer anderen Website führt. Das Cookie wird jedoch nicht gesendet, wenn die Anfrage durch eine „eingebettete“ Ressource ausgelöst wird, wie z.B. ein Bild oder ein Skript auf einer anderen Website. SameSite=Lax ist die empfohlene Einstellung für die meisten Anwendungsfälle, da sie ein gutes Gleichgewicht zwischen Sicherheit und Funktionalität bietet.
3. SameSite=None; Secure:
   Die SameSite-Eigenschaft „None“ erlaubt es dem Cookie, in Cross-Site-Anfragen gesendet zu werden, unabhängig davon, welche Seite die Anfrage auslöst. Dies ist nützlich, um bestimmte Funktionen zu ermöglichen, die Cookies von Drittanbietern erfordern, z.B. Single Sign-On über verschiedene Domänen hinweg.

1. Anwendungsfall 1: Formularübermittlung / Session Cookie: In diesem Anwendungsfall wird ein Formular auf einer Website ausgefüllt und an denselben Ursprung gesendet. Das Cookie wird benötigt, um den Sitzungszustand aufrechtzuerhalten.
2. Anwendungsfall 2: Cross-Site-Tracking: In diesem Anwendungsfall wird das Cookie verwendet, um das Verhalten eines Benutzers über verschiedene Websites hinweg zu verfolgen. Dies wird oft von Werbetreibenden und Analysetools verwendet, um personalisierte Werbung oder Analysen bereitzustellen.
3. Anwendungsfall 3: Einbettung von Inhalten von Drittanbieter-Websites: In einigen Fällen kann es erforderlich sein, Inhalte von Drittanbieter-Websites, wie eingebettete Videos oder Social-Media-Widgets, in die eigene Website einzubetten. Um auf das Cookie der Drittanbieter-Website zuzugreifen und die gewünschten Funktionen bereitzustellen, kann die SameSite-Einstellung „None“ erforderlich sein.

HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus für HTTPS-Verbindungen und es schützt vor Aushebelung der Verbindungsverschlüsselung und Session Hijacking.

Der Server kann über den HTTP Response Header Strict-Transport-Security dem Browser mitteilen, verschlüsselte Verbindungen für eine definierte Zeit zu nutzen.

Der Browser wird jetzt alle Anfrage an den Server (Bilder, CSS, JS) automatisch mit HTTPS tätigen, auch wenn man im Code an einer Stelle einen Schreibfehler eingebaut hat wie hier:

<img src='http://foo.org/image.jpg'>  // mit HSTS geht der Request automatisch nach https://foo.org/image.jpg

Ein solcher Header sieht so aus:

Strict-Transport-Security: max-age=31536000

Damit wird dem Browser erklärt, nur verschlüsselte Verbindungen zu dieser Seite aufbauen soll innerhlab der nächsten 31536000 Sekunden (1 Jahr).

HSTS preload list

Ein Problem besteht darin, dass beim Erstaufruf einer Domain ein unverschlüsselter Request gesendet werden muss, um die Verschlüsselungsforderung des Servers zu prüfen. Um dieses Problem zu umgehen, gibt es die HSTS preload list, die von Google Chrome betreut und von anderen großen Webbrowsern genutzt wird. Wenn eine Domain in dieser Liste steht, wird die Erstanfrage übersprungen und die Kommunikation sofort verschlüsselt.

Die Eintragung zusätzlicher Domains in die HSTS preload list ist kostenlos möglich hier.

HSTS in Angular

HSTS muss im Webserver aktiviert werden und Angular braucht dafür keine Anpassungen.

Beispiel Implementation für nginx

Content Security Policy (CSP) ist eine Sicherheitsmaßnahme, die von Webbrowsern genutzt wird, um bestimmte Arten von Angriffen zu verhindern, einschließlich Cross-Site Scripting (XSS) und Dateninjektionsangriffe. Sie funktioniert, indem sie Richtlinien für die Arten von Inhalten festlegt, die auf einer Webseite geladen und ausgeführt werden dürfen.

Die CSP wird vom Server als HTTP-Header gesendet. Ein typischer CSP-Header könnte folgendermaßen aussehen:

Content-Security-Policy: default-src 'self'; img-src 'self' https://example.com; script-src 'self' https://example.com;

Dieser Header legt eine Reihe von Richtlinien fest:

• default-src 'self': Dies bedeutet, dass Inhalte (wie Skripte, Styles, Medien und mehr) nur von der aktuellen Domain geladen werden dürfen.
• img-src 'self' https://example.com: Dies bedeutet, dass Bilder nur von der aktuellen Domain oder https://example.com geladen werden dürfen.
• script-src 'self' https://example.com: Dies bedeutet, dass Skripte nur von der aktuellen Domain oder https://example.com geladen werden dürfen.

Diese Richtlinien helfen, Angriffe zu verhindern, indem sie den Ursprung von Inhalten, die in einer Webseite ausgeführt werden dürfen, einschränken. Beispielsweise würde eine CSP, die das Laden von Skripten nur von der aktuellen Domain erlaubt, verhindern, dass ein Angreifer ein Skript von einer externen Quelle in die Webseite einfügt.

Der CSP Nonce

In der Content Security Policy (CSP) kann eine Nonce (“number only used once”, in diesem Fall kann es auch ein alphanumerischer Wert sein) dazu verwendet werden, bestimmten Inline-Skripten oder Inline-Styles die Ausführung zu erlauben.

Jedes Mal, wenn die Seite geladen wird, generiert der Server eine neue eindeutige Nonce-Wert, die dann dem CSP-Header und dem entsprechenden Inline-Script oder -Style hinzugefügt wird.

Angenommen, Sie haben eine Webserver-Konfiguration (z.B. in Node.js), die in der Lage ist, eine zufällige Nonce zu generieren und in Ihre Seite einzufügen. Ihre CSP-Richtlinie könnte dann folgendermaßen aussehen:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-2726c7f26c'

In diesem Beispiel ist 'nonce-2726c7f26c' der Nonce-Wert. Dieser Wert würde dem Inline-Script-Tag in Ihrem HTML-Dokument hinzugefügt, so dass es trotz der CSP ausgeführt werden kann:

<script nonce="2726c7f26c">
    // JS Code hier
</script>

Wenn die Seite neu geladen wird, würde der Server eine neue Nonce generieren und sowohl den CSP-Header als auch das nonce-Attribut des Script-Tags aktualisieren. Das bedeutet, dass, selbst wenn ein Angreifer die aktuelle Nonce kennen würde, sie ihm nicht helfen würde, schädliche Skripte auszuführen, da die Nonce bei jedem Seitenladen geändert wird.

Der folgende Code würde vom Browser nicht ausgeführt werden als Schutz vor Angriffen:

<script>
    // Code wird geblockt
</script>

Die Reporting Funktion

Die Berichtsfunktion in der Content Security Policy (CSP) ermöglicht es Ihnen, Benachrichtigungen zu erhalten, wenn bestimmte Vorfälle, wie beispielsweise Verstöße gegen die CSP, auftreten. Dies wird über die report-uri oder die report-to Direktive in der CSP-Header-Zeichenkette gesteuert.

Wenn ein CSP-Verstoß auftritt, sendet der Browser einen POST-Request mit einem JSON-Body an die URL, die in der report-uri oder report-to Direktive angegeben ist.

Das JSON-Objekt enthält Details zum Verstoß, wie den Dokument-URI, den Verstoßenden URI, die Zeilen- und Spaltennummer, die die Verletzung verursacht hat, und die genaue CSP-Richtlinie, die verletzt wurde.

Hier ist ein Beispiel für eine CSP mit Berichtsfunktion:

Content-Security-Policy: default-src 'self'; report-uri /csp-violation-report-endpoint/

In diesem Fall würde der Browser, wenn ein Verstoß auftritt, einen POST-Request an /csp-violation-report-endpoint/ senden, der die Details des Verstoßes enthält.

Die Verknüpfung von Angular und dem Nonce Wert

Der Nonce Token wird vom Backend generiert und kann der Angular Anwendung bereit gestellt werden über:

import {bootstrapApplication, CSP_NONCE} from '@angular/core';
import {AppComponent} from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [{
    provide: CSP_NONCE,
    useValue: myNonceService.getValue()
  }]
});

Der Nonce Wert wird vom Backend gesetzt und beim ausliefern des Frontend Angular Projektes gesetzt über die index.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <base href="/" />
  </head>
  <body>
    <app-root
      data-nonce="MY_NONCE_PLACEHOLDER"></app-root>
  </body>
</html>

Der Service Zum Auslesen sieht so aus:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class MyNonceService {
  getValue(): string {
    return document.querySelector<HTMLElement>('app-root')?.dataset['nonce'];
  }
}

Jetzt muss das Backend so konfiguriert werden, dass es

1. Bei jedem Request auf den Angular Code einen eindeutigen Nonce generiert und in den Header packt.
2. Alle vorkommen von MY_NONCE_PLACEHOLDER ersetzt werden durch den Wert des Nonce.

Beispiel nginx Konfiguration:

add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-${request_id}'; style-src 'nonce-${request_id}';";

Damit fügt der nginx dem Header den Nonce Wert hinzu.

Die request_id Variable wird vom nginx bei jedem Request automatisch berechnet und steht global zur Verfügung.

location / {
    sub_filter MY_NONCE_PLACEHOLDER $request_id;
    sub_filter_once off;         
    }

Diese Direktive sorgt dafür, dass jede Instanz von „MY_NONCE_PLACEHOLDER“ im HTML-Inhalt der Seite durch den Nonce Wert ersetzt wird.

Der CSP Header für Angular

Ab Angular Version 16:

default-src 'self'; 
style-src 'self' 'nonce-randomNonceGoesHere'; 
script-src 'self' 'nonce-randomNonceGoesHere';

Vor Version 16 war es notwendig ‚unsafe-inline‘ hinzuzufügen für die style-src:

default-src 'self'; 
style-src 'self' 'unsafe-inline' 'nonce-randomNonceGoesHere'; 
script-src 'self'  'nonce-randomNonceGoesHere';