Kategorie: Security

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