Kategorien
Angular Security

Dependency-Check-Tools für Angular

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.

Kategorien
Angular Security

Angular Security Best Practises

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.
Kategorien
Angular PHP Security

XSRF Schutz in Angular

Cross-Site Request Forgery (XSRF), auch als Session Riding bekannt, ist ein weit verbreitetes Sicherheitsproblem, das Webanwendungen betrifft, einschließlich Angular-Anwendungen. XSRF-Attacken zielen darauf ab, die Identität und Berechtigungen eines unwissenden Nutzers zu missbrauchen, um bösartige Aktivitäten durchzuführen. Angular bietet jedoch eingebaute Mechanismen zur Bekämpfung solcher Angriffe. In diesem Artikel werden wir XSRF in Angular eingehender betrachten und darüber diskutieren, wie wir uns davor schützen können.

Ablauf einer XSRF Attacke

Bei einer XSRF-Attacke sendet der Angreifer eine betrügerische Anfrage von einer Seite, der das Opfer vertraut. Der Angreifer nutzt die Tatsache aus, dass Cookies beim Senden von Anfragen an eine Site automatisch inkludiert werden, auch wenn die Anfrage von einer dritten Site ausgelöst wird. Wenn das Opfer zu diesem Zeitpunkt bei der betroffenen Anwendung angemeldet ist, wird die Anfrage als legitime Anfrage des Opfers angesehen und ausgeführt. Dies könnten zum Beispiel ein Request an einen Bank Server sein, der eine Überweisung auslöst.

Implementierung des XSRF-Schutzes in Angular

Hier sind die Schritte, die Sie befolgen sollten, um XSRF-Schutz in Ihrer Angular-Anwendung zu implementieren:

  1. HttpClientModule importieren: Sie müssen das HttpClientModule importieren in der src/app/app.module.ts und für die Requests verwenden.
import {HttpClientModule} from "@angular/common/http";
...
imports: [
  HttpClientModule,
]
  1. XSRF-Token setzen: Der Server sollte das XSRF-Token in einem Cookie setzen. Das Standardcookie, das Angular sucht, heißt XSRF-TOKEN.
  2. XSRF-Tokens in HTTP-Anfragen verwenden: Der HttpXsrfInterceptor fügt automatisch das X-XSRF-TOKEN-Header mit dem XSRF-Token aus dem Cookie hinzu. Wenn der Server das Header erhält, vergleicht er das Token mit dem, was er hat. Wenn es nicht übereinstimmt, wird die Anfrage abgelehnt.

Es ist wichtig zu beachten, dass XSRF-Schutz in Angular darauf beruht, dass der Server korrekt konfiguriert ist, um das XSRF-Token in einem Cookie zu setzen und dieses bei eingehenden Anfragen zu überprüfen.

Wenn der Backend Server einen anderen Cookie oder Header für den XRSF Token verwendet, kann dies in Angular folgender Maßen konfiguriert werden:

imports: [
  HttpClientModule,
  HttpClientXsrfModule.withOptions({
    cookieName: 'My-Xsrf-Cookie',
    headerName: 'My-Xsrf-Header',
  }),
],

Angular fügt das XSRF-Token standardmäßig nur zu den PUT, POST, DELETE und PATCH HTTP-Anfragen hinzu, da diese Operationen im Allgemeinen den Zustand des Servers ändern können und daher als potenziell unsicher angesehen werden.

GET– und HEAD-Anfragen dagegen sind idempotent und lesen nur Daten, sie führen keine Aktionen aus, die den Zustand des Servers verändern, daher fügt Angular diesen Anfragen standardmäßig kein XSRF-Token hinzu. Das ist eine gängige Praxis, um die Menge der übertragenen Daten zu reduzieren und da XSRF-Angriffe typischerweise auf Zustandsänderungen abzielen.

Beispiel Implementierung im Backend mit PHP

Hier ist ein einfaches Beispiel in PHP für das Setzen und Überprüfen eines XSRF-Tokens.

Token setzen

Wenn ein Benutzer eine Sitzung startet, erstellen und speichert man ein XSRF-Token in einem Cookie und überträgt ihn damit an das Frontend.

<?php
session_start();

if (empty($_SESSION['token'])) {
    $token = bin2hex(random_bytes(32));
    $_SESSION['token'] = $token;
    setcookie("XSRF-TOKEN", $token, time() + 3600, "/");
}

Token überprüfen

Bei eingehenden POST, PUT, DELETE oder PATCH Anfragen vom Frontend, überprüft man das XSRF-Token im Backend.

<?php
session_start();

$method = $_SERVER['REQUEST_METHOD'];
$serverToken = $_SESSION['token'];
$clientToken = $_SERVER['HTTP_X_XSRF_TOKEN'];

if (in_array($method, array('POST', 'PUT', 'DELETE', 'PATCH'))) {
    if (!isset($clientToken)) {
        die("Unauthorized request (missing X-XSRF-TOKEN header)");
    } elseif (!hash_equals($serverToken, $clientToken)) {
        die("Unauthorized request (X-XSRF-TOKEN does not match)");
    }
}
Kategorien
Angular Security

HTTPOnly und Secure Cookies in Angular

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.
Kategorien
Angular Security

Anwenden von HTTP Strict Transport Security (HSTS) in Angular

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

Kategorien
Angular Security

Verwenden von Content Security Policy (CSP) in Angular

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';
Kategorien
Angular JavaScript

Identifizieren von ungenutzten NPM Packeten mit depcheck in Angular

Das npm Packet depcheck kann ungenutzten NPM Packete finden. Diese Information ist wichtig, weil fremde Packete ein Sicherheitsrisiko darstellen.

Das Risiko geht von fremden npm Packeten

Es gibt verschiedene potenzielle Angriffe oder Sicherheitsrisiken, die mit npm-Paketen verbunden sein können. Hier sind einige Beispiele:

  1. Maliziöse Pakete: Angreifer können böswillige oder schädliche Pakete veröffentlichen, die als nützliche oder beliebte Bibliotheken getarnt sind. Diese Pakete können schädlichen Code enthalten, der dein System oder deine Anwendung beeinträchtigen kann.
  2. Abhängigkeitskette: Wenn du npm-Pakete in deinem Projekt verwendest, können diese wiederum von anderen Paketen abhängen. Angreifer könnten eine Schwachstelle in einer Abhängigkeit ausnutzen, um Zugriff auf dein System zu erlangen oder deine Anwendung zu kompromittieren.
  3. Verwaiste Pakete: Verwaiste Pakete sind solche, deren ursprüngliche Entwickler die Wartung eingestellt haben. Diese Pakete erhalten möglicherweise keine Sicherheitsupdates mehr und könnten anfällig für Angriffe sein. Verwenden deiner Anwendung veraltete und unsichere Pakete erhöht das Risiko von Sicherheitslücken.
  4. Manipulation von Paketregistrierungen: Ein Angreifer könnte versuchen, die Infrastruktur der Paketregistrierung zu kompromittieren und schädliche Pakete in den offiziellen Paketkanälen bereitzustellen. Dies könnte dazu führen, dass du unwissentlich gefährliche Pakete installierst.
  5. Code-Injektion: Wenn du npm-Pakete verwendest, ist es wichtig, darauf zu achten, dass der Code sicher ist. Ein fehlerhaftes oder unsicher implementiertes Paket kann Angreifern die Möglichkeit bieten, schädlichen Code in deine Anwendung einzuschleusen.

Die Funktionsweise von Depcheck

Depcheck analysiert den Quellcode deines Projekts, um festzustellen, welche Pakete tatsächlich verwendet werden. Dabei untersucht es verschiedene Aspekte des Codes, um die Verwendung von Paketen zu ermitteln:

  1. Importanweisungen: Depcheck überprüft die Importanweisungen in den JavaScript-/TypeScript-Dateien. Es sucht nach importierten Modulen, Klassen, Funktionen oder Variablen und ermittelt so, welche Pakete im Code verwendet werden.
  2. Referenzen und Verwendungen: Depcheck analysiert den Code, um festzustellen, ob die importierten Module, Klassen, Funktionen oder Variablen tatsächlich verwendet werden. Es überprüft, ob Funktionen aufgerufen, Methoden aufgerufen, Eigenschaften gelesen oder Variablen referenziert werden. Wenn ein importiertes Element nicht verwendet wird, markiert depcheck das zugehörige Paket als potenziell unbenutzt.
  3. Berücksichtigung verschiedener Dateitypen: Depcheck kann auch andere relevante Dateitypen analysieren, wie z.B. HTML-Dateien oder Konfigurationsdateien, um die Verwendung von Paketen zu ermitteln. Beispielsweise können in HTML-Dateien verwendete Direktiven oder Komponenten auf Pakete hinweisen, die im Code selbst möglicherweise nicht explizit importiert werden.

Einbinden von depcheck in Angular

Die Installation erfolgt über

npm install -g depcheck typescript

Beispiel Ausgabe bei einem Angular Projekt:

Unused dependencies
* @types/quill
* @types/vis
* bootstrap
* ngx-quill
* tslib
Unused devDependencies
* @angular-devkit/build-angular
* @angular/cli
* @angular/compiler-cli
* @types/jasmine
* jasmine-core
* karma
* karma-chrome-launcher
* karma-coverage
* karma-jasmine
* karma-jasmine-html-reporter
* typescript

In der package.json befanden sich 11 dev Dependencies und 19 normale Dependencies. Es wurden alle dev Dependencies falsch positiv erkannt. Von den potenziel gefährlicheren normalen Packete, die nicht nur im dev Modus existieren, wurden korrekt 13 Packete als verwendet erkannt. Die 5 Packete kann man einfach per Namen oder Regex (@types/*) entfernen.

Es wird tatsächlich erkannt, das ngx-quill in dem Beispiel als einziges Packet nicht verwendet wird.

Es muss also eine Menge von Hand ausgechlossen werden, wofür ein spezielle depcheck Angular Erweiterung nützlich wäre, aber leider noch nicht existiert im Gegensatz zu React JSX und Vue.js.

Fazit

Depcheck ist nützlich um unbenutzte Packete zu identifizieren, um die Sicherheit von Angular Anwendungen zu gewährleisten.

Außerdem sollten alle Packete fortwährend auf Sicherheitslücken gescannt werden. Wenn ein Packet nicht mehr weiter entwickelt wird oder Sicherheitslücken nicht schließt, sollte es ausgetauscht werden gegen eine aktuelle Variante.

Kategorien
Projekte

Berlin Tipps Webseite veröffentlicht

Als kleines neben Projekt, habe ich die Webseite fnfn.de veröffentlicht, indem ich die besten Restaurants, Bars, Sehenswürdigkeiten und Clubs von Berlin vorstelle.

Kategorien
Symfony

Sonata 4 Admin Variablen im Template

In Sonata 4 stehen verschiedene Sonata-spezifische Variablen in den Templates zur Verfügung. Hier sind einige der häufig verwendeten Variablen:

  1. admin: Diese Variable repräsentiert das aktuelle Admin-Objekt und ermöglicht den Zugriff auf verschiedene Admin-spezifische Informationen und Methoden. Sie kann verwendet werden, um beispielsweise den Admin-Titel oder die Routen zu erhalten.
  2. object: Diese Variable repräsentiert das aktuelle Objekt oder die aktuelle Entität, mit der das Template arbeitet. Sie ermöglicht den Zugriff auf Eigenschaften und Methoden des Objekts, um dynamische Inhalte im Template zu generieren.
  3. id: Diese Variable enthält die ID des aktuellen Objekts. Sie ist besonders nützlich in Templates, die auf einzelne Objekte angewendet werden, um spezifische Daten abzurufen oder Aktionen durchzuführen.
  4. form: Wenn das Template ein Formular darstellt, steht die form Variable zur Verfügung. Diese Variable ermöglicht den Zugriff auf das Formularobjekt und dessen Felder, um beispielsweise Validierungen durchzuführen oder Daten zu verarbeiten.
  5. base_template: Diese Variable definiert das Basis-Template, das von einem spezifischen Sonata Template erweitert wird. Sie ermöglicht es Entwicklern, das Standardverhalten von Sonata anzupassen, indem sie ein benutzerdefiniertes Basis-Template festlegen.
  6. admin_pool: Diese Variable stellt den Admin-Pool dar und bietet Zugriff auf den gesamten verfügbaren Admin-Bereich. Sie ermöglicht den Zugriff auf Informationen über alle registrierten Admin-Klassen und kann zum Beispiel verwendet werden, um eine Liste der verfügbaren Admin-Objekte anzuzeigen.

In Sonata 4 stehen neben den zuvor genannten Variablen auch die value-Variable zur Verfügung. Diese Variable repräsentiert den aktuellen Wert eines bestimmten Feldes oder einer Eigenschaft des Objekts.

Hier ist ein Beispiel, wie die value-Variable im Template array.html.twig verwendet werden kann:

{% extends '@SonataAdmin/CRUD/base_show_field.html.twig' %}

{% block field %}
    {% if value is not empty %}
        {{ value | join(', ') }}
    {% endif %}
{% endblock %}
protected function configureShowFields(ShowMapper $show): void
{
	$show->add('my_attrbute', null, [
		'label' => 'Array Attribute Example',
		'template' => 'array.html.twig',
		]
	)
}
Kategorien
PHP Symfony

SQL vs. Doctrine Migrations

In Symfony und Doctrine stehen Ihnen zwei Optionen zur Verfügung, um Datenbankmigrationen zu verwalten: SQL und Doctrine-Objekte.

  1. SQL-Migrationen: Mit SQL-Migrationen schreiben Sie die Datenbankänderungen als SQL-Skripte. Dies gibt Ihnen die volle Kontrolle über den genauen SQL-Code, der ausgeführt wird. Sie können spezifische Datenbankfunktionen und -funktionen nutzen, die möglicherweise nicht direkt von Doctrine unterstützt werden. SQL-Migrationen können auch einfacher sein, wenn Sie bereits über umfangreiche SQL-Kenntnisse verfügen.

Einige Vorteile der SQL-Migrationen sind:

  • Direkte Kontrolle über den SQL-Code.
  • Nutzung spezifischer Datenbankfunktionen.
  • Einfacher für Entwickler mit umfangreichen SQL-Kenntnissen.

Einige Nachteile der SQL-Migrationen sind:

  • Möglicherweise weniger portabel, da der SQL-Code an eine bestimmte Datenbank-Engine gebunden sein kann.
  • Weniger objektorientiert und weniger Integration mit dem Doctrine ORM.
  1. Doctrine-Objekt-Migrationen: Mit Doctrine-Objekt-Migrationen verwenden Sie Doctrine-Migrationsklassen, um Ihre Datenbankänderungen zu definieren. Dies ermöglicht eine objektorientierte Herangehensweise an die Migrationen und eine bessere Integration mit dem Doctrine ORM. Sie können auf die Funktionen von Doctrine zugreifen und beispielsweise Änderungen an Ihren Datenbanktabellen über die Objektmodelle vornehmen.

Einige Vorteile der Doctrine-Objekt-Migrationen sind:

  • Objektorientierte Herangehensweise an Migrationen.
  • Bessere Integration mit dem Doctrine ORM.
  • Portabler, da Doctrine den generierten SQL-Code an die spezifische Datenbank-Engine anpasst.

Der entscheidende Nachteil von Doctrine-Objekt-Migrationen

Ein wichtiger Nachteil bei der Verwendung von Doctrine-Objekt-Migrationen besteht darin, dass bei der Erstellung der Entitäten ein Fehler auftritt, wenn ein Attribut in der Datenbank nicht vorhanden ist. Dies kann insbesondere dann zum Problem werden, wenn Sie vorhandene Datenbanktabellen haben und Änderungen an den Entitäten vornehmen, die zu Spalten hinzufügen oder entfernen.

Wenn Sie beispielsweise eine Entität mit einem bestimmten Attribut definieren und versuchen, die Datenbanktabellen basierend auf dieser Entität zu erstellen, wird Doctrine einen Fehler werfen, wenn das entsprechende Attribut in der Datenbanktabelle nicht vorhanden ist. Dies liegt daran, dass Doctrine die Entitäten und die Datenbanktabellen synchron halten möchte.

Aufgrund meiner Erfahrungen mit Migrationen würde ich immer empfehlen SQL-Migrationen zu verwenden, weil beim hinzufügen von Attributen ansonsten immer Fehler geworfen werden.