Aufgabe 18 - Cookie gegen Token: zwei Varianten derselben Anmeldung

Worum geht es?

Sie bauen dieselbe Anmeldung zweimal: einmal mit einem Sitzungscookie, einmal mit einem Bearer-Token, und vergleichen beide an denselben Fragen (siehe Kapitel Getrennte Systeme). Es gibt hier keine allgemein richtige Antwort. Am Ende der Übung haben Sie eine für Ihr Projekt, und Sie können sie begründen.

Was Sie dafür brauchen

Kapitel Getrennte Systeme, Abschnitt Die Sitzung über Systemgrenzen.
Die beiden Anwendungen aus Aufgabe 17 mit funktionierender CORS-Konfiguration.
Browser mit Entwicklerwerkzeugen. Der Anwendungs-Tab zeigt Cookies und localStorage.

Welche Kompetenzen Sie erwerben und zeigen

Sie richten eine Sitzung ein, die über eine Origin-Grenze hinweg funktioniert.
Sie benennen die Wirkung der Cookie-Attribute HttpOnly, Secure, SameSite und Domain.
Sie stellen Cookie- und Token-Ansatz gegenüber und treffen eine begründete Wahl.

Pädagogische Einordnung

Reproduktion: Cookie-Attribute benennen und im Browser auffinden (Teil A).
Reorganisation und Transfer: dieselbe Anmeldung in zwei Varianten bauen (Teil B).
Reflexion, Problemlösung und Urteilsbildung: beide Varianten vergleichen und die Wahl begründen (Teil C).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt.

Teil A - Cookies ansehen

Öffnen Sie eine beliebige Website, bei der Sie angemeldet sind, und sehen Sie sich im Anwendungs-Tab die Cookies an. Notieren Sie zu einem davon alle gesetzten Attribute.
Erklären Sie in je einem Satz, was HttpOnly, Secure, SameSite und Domain bewirken.
Setzen Sie in Ihrer API einen Endpunkt POST /login, der ein Cookie mit einem festen Wert setzt, zunächst ohne weitere Attribute. Rufen Sie ihn auf und suchen Sie das Cookie im Browser.
Versuchen Sie, das Cookie in der Konsole mit document.cookie zu lesen. Notieren Sie das Ergebnis. Ergänzen Sie danach HttpOnly, wiederholen Sie den Versuch und notieren Sie den Unterschied.
Setzen Sie SameSite=None ohne Secure und laden Sie die Seite neu. Suchen Sie das Cookie. Beschreiben Sie in zwei bis drei Sätzen, was passiert ist und warum dieser Fall im Betrieb besonders unangenehm ist.

Teil B - Beide Varianten bauen

Bauen Sie die Cookie-Variante: POST /login setzt ein Sitzungscookie mit HttpOnly, Secure und passendem SameSite. Ein geschützter Endpunkt GET /me antwortet nur, wenn das Cookie mitkommt, sonst mit 401.
Rufen Sie GET /me aus dem Frontend auf. Achten Sie darauf, dass fetch Cookies nur mit credentials: "include" mitschickt und die API dafür Access-Control-Allow-Credentials: true senden muss. Notieren Sie, was Sie ändern mussten, bis es funktioniert hat.
Bauen Sie die Token-Variante: POST /login liefert ein Token im Rumpf zurück. Das Frontend legt es ab und schickt es bei GET /me im Authorization-Header mit.
Legen Sie das Token zunächst im localStorage ab. Lesen Sie es in der Konsole mit einer einzigen Zeile aus und notieren Sie diese Zeile. Sie ist Ihr Beleg in Teil C.
Laden Sie in beiden Varianten die Seite neu. Notieren Sie, welche Variante die Anmeldung überlebt und welche nicht, und erklären Sie den Unterschied in zwei Sätzen.
Legen Sie das Token danach in einer JavaScript-Variable im Speicher ab statt im localStorage. Laden Sie neu und beschreiben Sie in zwei bis drei Sätzen, welches Problem Sie sich damit eingehandelt haben und mit welchem Mechanismus man es üblicherweise löst.

Teil C - Vergleichen und entscheiden

Bauen Sie in Ihr Frontend eine Stelle ein, die fremden Text ungeprüft in die Seite schreibt, etwa über innerHTML. Das ist eine XSS-Lücke, und Sie bauen sie absichtlich, um sie zu messen.
Schreiben Sie über diese Lücke ein kleines Skript, das das Token aus dem localStorage ausliest und in der Konsole ausgibt. Notieren Sie das Ergebnis.
Versuchen Sie dasselbe mit dem HttpOnly-Cookie aus der ersten Variante. Notieren Sie das Ergebnis und erklären Sie den Unterschied in drei bis vier Sätzen. Entfernen Sie die Lücke danach wieder.
Füllen Sie die Vergleichstabelle aus dem Kapitel für Ihre beiden Varianten aus, mit den fünf Zeilen Übertragung, Schutz vor XSS-Diebstahl, CSRF-Gefahr, fremde Clients und Aufwand im Frontend. Belegen Sie mindestens drei Zeilen mit einer eigenen Beobachtung aus dieser Übung.
Beschreiben Sie in vier bis fünf Sätzen, warum die Cookie-Variante zwar vor dem Diebstahl schützt, aber eine andere Gefahr mitbringt. Nennen Sie die beiden Gegenmaßnahmen dazu und das Kapitel, in dem sie behandelt werden.
Entscheiden Sie sich für Ihr eigenes Projekt. Schreiben Sie den Eintrag in docs/entscheidungen.md mit den vier Abschnitten Entscheidung, Alternativen, Begründung und Folgen. Zwei Angaben gehören in die Begründung: liegen Frontend und API unter derselben Hauptdomain, und ist ein fremder Client wie eine Mobil-App geplant?
Nennen Sie zum Schluss die eine Kombination, die Sie laut Kapitel in jedem Fall vermeiden sollen, und begründen Sie in zwei Sätzen, warum.

Wissenscheck

Was bewirken HttpOnly, Secure und SameSite jeweils?
Warum wird ein Cookie mit SameSite=None ohne Secure verworfen, und warum ist das im Betrieb schwer zu bemerken?
Welche zwei Einstellungen braucht es auf beiden Seiten, damit ein Cookie über eine Origin-Grenze mitkommt?
Warum ist ein Token im localStorage bei einer XSS-Lücke besonders gefährlich?
Warum ist die Cookie-Variante anfälliger für CSRF als die Token-Variante?
Wann führt an Tokens wenig vorbei?
Wozu dient ein Refresh-Token in einem HttpOnly-Cookie?

Abgabe

Beide Varianten liegen lauffähig als Code vor. In protokoll.md stehen die Cookie-Beobachtungen aus Teil A, die Änderungen aus Teil B Punkt 2, das Ergebnis des XSS-Versuchs mit beiden Speicherorten und die ausgefüllte Vergleichstabelle. Der Entscheidungseintrag steht in docs/entscheidungen.md. Die absichtlich eingebaute XSS-Lücke ist wieder entfernt.