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.

Verständnis 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 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 in Ihrem App-Modul importieren.
  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 folgenr Maßen konifuriert 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 speichern Sie ein XSRF-Token in einem Cookie.

<?php
session_start();

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

Token überprüfen

Bei eingehenden POST, PUT, DELETE oder PATCH Anfragen überprüfen Sie das XSRF-Token. Stellen Sie sicher, dass das Token im X-XSRF-TOKEN Header mit dem in der Sitzung gespeicherten Token übereinstimmt.

<?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'))) {
    // Only check the token for certain methods
    if (!isset($clientToken)) {
        // X-XSRF-TOKEN header is missing
        die("Unauthorized request (missing X-XSRF-TOKEN header)");
    } elseif (!hash_equals($serverToken, $clientToken)) {
        // The X-XSRF-TOKEN header does not match the server token
        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 abgerufen 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() + (86400 * 30), // 86400s = 1Tag
    '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 keien sensiblen Informationen in solchen unsicheren Cookies gespeichert werden.

Keine sensiblen Daten speichern

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 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.
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';