Sicherheit von Webanwendungen: So gefährlich ist Cookie-Manipulation

Sicherheitslücken in Webanwendungen entstehen oft durch vermeintlich harmlose Entscheidungen bei der Implementierung. Ein besonders riskantes Muster: Die direkte Speicherung von Berechtigungsinformationen in Cookies. Während Cookies eigentlich nur als Identifikationsmerkmal dienen sollen, vertrauen viele Anwendungen blind auf deren Inhalt. Doch genau diese Vertrauensstellung macht sie zu einem beliebten Angriffsziel. Drei verbreitete Techniken zeigen, wie einfach es für Angreifer ist, durch Cookie-Manipulation Zugriff auf geschützte Bereiche zu erlangen – und wie Entwickler solche Schwachstellen wirksam verhindern können.

Warum Cookies zu einem Sicherheitsrisiko werden

Cookies dienen in modernen Webanwendungen als Session-Token, die zwischen Client und Server ausgetauscht werden. Theoretisch sollte ein Cookie nur eine zufällige, serverseitig generierte Zeichenfolge enthalten, die es dem Server ermöglicht, den Benutzer zu identifizieren. Doch in der Praxis speichern Entwickler häufig sensible Daten wie Authentifizierungsstatus oder Rolleninformationen direkt im Cookie. Diese Praxis birgt ein fundamentales Problem: Der Server vertraut den Inhalten des Cookies, ohne zu überprüfen, ob die Daten tatsächlich vom Server stammen oder manipuliert wurden.

Angreifer nutzen diese Vertrauensstellung aus, indem sie Cookies abfangen, decodieren oder direkt modifizieren. Bereits eine minimale Änderung kann dazu führen, dass eine Anwendung einem Nutzer Administratorrechte zuweist – obwohl dieser nur über Standardrechte verfügt. Die folgenden Beispiele demonstrieren, wie einfach solche Angriffe in der Praxis umzusetzen sind – und warum Entwickler niemals clientseitige Daten als vertrauenswürdig einstufen sollten.

Angriffsmethode 1: Manipulation von Klartext-Cookies

Die naivste, aber leider weit verbreitete Methode besteht darin, Berechtigungsinformationen wie admin=true oder role=user direkt im Cookie abzulegen. Der Server liest diese Werte und gewährt oder verweigert Zugriff entsprechend. Da die Daten im Klartext vorliegen, können Angreifer sie mit einfachen HTTP-Requests anpassen.

Ein typisches Szenario spielt sich wie folgt ab:

• Die Anwendung setzt nach erfolgreicher Anmeldung zwei Cookies:
• Set-Cookie: logged_in=true; Max-Age=3600; Path=/
• Set-Cookie: admin=false; Max-Age=3600; Path=/

• Ein Standardanfrage ohne Cookies liefert die Antwort:

Not Logged In

• Durch das Senden der ursprünglichen Cookies wird der Nutzer als registrierter Benutzer erkannt:

Logged In As A User

• Durch einfaches Ändern des admin-Werts von false auf true erhält der Angreifer Administratorrechte:

Logged In As An Admin

Der Server überprüft nicht, ob der Cookie-Wert tatsächlich vom Server stammt. Er vertraut ausschließlich dem Inhalt, den der Client sendet. Eine einzige Zeile im Request genügt, um die Berechtigungsstruktur der Anwendung zu untergraben.

Schutzmaßnahmen:

• Lagern Sie alle Berechtigungsinformationen ausschließlich serverseitig.
• Verwenden Sie zufällige Session-IDs als Cookie-Werte.
• Verknüpfen Sie diese IDs mit einer serverseitigen Session-Speicherung.
• Vermeiden Sie die clientseitige Speicherung von sensitiven Daten wie Rollen oder Berechtigungen.

Angriffsmethode 2: Umgehung von Hash-basierten Cookies

Entwickler versuchen gelegentlich, die Sicherheit zu erhöhen, indem sie Berechtigungsinformationen nicht im Klartext, sondern als Hash-Wert speichern. Die Idee dahinter: Hashes wirken zufällig und sind für Menschen nicht lesbar. Doch Hashes sind deterministisch – ein und derselbe Eingabewert erzeugt immer denselben Hash. Dadurch können Angreifer bekannte Hash-Werte gezielt erzeugen, um sich höhere Rechte zu erschleichen.

Ein Beispiel verdeutlicht das Problem:

Angenommen, die Anwendung erwartet für die Rolle admin einen MD5-Hash des Strings admin. Der Hash lässt sich mit einem einfachen Befehl berechnen:

echo -n "admin" | md5sum

Die Ausgabe lautet:

21232f297a57a5a743894a0e4a801fc3

Durch das Senden dieses Hash-Werts als role-Cookie kann der Angreifer Administratorrechte vortäuschen:

curl -H "Cookie: role=21232f297a57a5a743894a0e4a801fc3" 

Die Anwendung akzeptiert den Hash, da sie ihn als gültige Rolle interpretiert. Selbst Rainbow-Tabellen oder Cracking-Tools können genutzt werden, um bekannte Hash-Werte zurück in die ursprünglichen Strings zu übersetzen.

Schutzmaßnahmen:

• Verwenden Sie HMAC (Hash-based Message Authentication Code) mit einem serverseitigen Geheimschlüssel.
• Integrieren Sie eine per-Session-Saltierung, sodass derselbe Eingabewert in jeder Session einen anderen Hash erzeugt.
• Hashes allein bieten keine ausreichende Sicherheit, da sie bei bekannten Eingaben vorhersagbar sind.

Angriffsmethode 3: Decodieren und Modifizieren von Base64-Cookies

Base64 ist eine Kodierungsmethode, keine Verschlüsselung. Jeder kann Base64-kodierte Daten mit einfachen Befehlen decodieren und wieder kodieren. Dennoch speichern einige Anwendungen sensible Session-Daten in Base64-kodierten Cookies und behandeln den Inhalt als vertrauenswürdig.

Ein typisches Beispiel:

• Die Anwendung setzt nach der Anmeldung einen Cookie mit folgendem Wert:

Set-Cookie: session=eyJpZCI6MSwiYWRtaW4iOmZhbHNlfQ==; Max-Age=3600; Path=/

• Der Base64-kodierte Inhalt lässt sich mit einem Befehl decodieren:

echo 'eyJpZCI6MSwiYWRtaW4iOmZhbHNlfQ==' | base64 -d

Die Ausgabe zeigt den ursprünglichen JSON-Inhalt:

{"id":1,"admin":false}

Ein Angreifer kann den Wert von admin von false auf true ändern und den JSON-String neu kodieren:

echo -n '{"id":1,"admin":true}' | base64

Der neue Cookie-Wert lautet:

eyJpZCI6MSwiYWRtaW4iOnRydWV9

Durch das Senden dieses manipulierten Cookies erhält der Angreifer Administratorrechte, ohne dass die Anwendung die Authentizität des Cookies überprüft.

Schutzmaßnahmen:

• Nutzen Sie signierte Tokens wie JWT (JSON Web Tokens) mit einem starken Geheimschlüssel.
• Validieren Sie die Signatur auf Serverseite, bevor Sie dem Cookie-Inhalt vertrauen.
• Falls sensible Daten im Cookie gespeichert werden müssen, verwenden Sie verschlüsselte Tokens, um Manipulationen zu verhindern.

Fazit: Vertrauen ist gut – Verifizierung ist besser

Cookie-Manipulationen funktionieren, weil Anwendungen Daten vertrauen, die sie nicht kontrollieren. Klartext-Cookies können direkt im Request geändert werden. Hash-basierte Cookies sind vorhersehbar, da identische Eingaben stets denselben Hash erzeugen. Base64-kodierte Cookies sind zwar obfuskiert, aber nicht geschützt – jeder kann sie decodieren und modifizieren.

Die Lösung liegt in drei grundlegenden Prinzipien:

• Lagern Sie alle sicherheitsrelevanten Informationen serverseitig.
• Signieren Sie Cookies oder Tokens mit einem serverseitigen Geheimschlüssel.
• Validieren Sie die Integrität und Authentizität aller clientseitigen Daten, bevor Sie darauf basierende Entscheidungen treffen.

Entwickler, die diese Maßnahmen umsetzen, erschweren Angreifern den Zugriff auf geschützte Bereiche erheblich. Sicherheit in Webanwendungen beginnt mit der Erkenntnis, dass der Client niemals als vertrauenswürdige Quelle für sensible Daten dienen darf. Nur durch konsequente serverseitige Kontrolle und kryptografische Absicherung können Anwendungen langfristig vor solchen Angriffen geschützt werden.