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.