Forged Cookies

Kurz: Gefälschte oder manipulierte Session-Cookies, mit denen ein Angreifer versucht, sich als ein anderer, bereits angemeldeter Nutzer auszugeben.

Genauer: Wenn ein Session-Cookie erraten, gestohlen (z. B. via XSS) oder mit einem schwachen/fehlenden Signaturverfahren einfach nachgebaut werden kann, kann ein Angreifer ihn im eigenen Browser setzen und wird vom Server als der ursprüngliche Nutzer erkannt. Schutz: kryptografisch signierte, zufällige Session-Tokens, HttpOnly/Secure-Flags auf Cookies und kurze Session-Laufzeiten.

Im Detail

Cookies können auf mehreren Wegen gefälscht oder gestohlen werden:

Diebstahl über XSS      - bösartiges Skript liest document.cookie aus und sendet
                           den Wert an einen Angreifer-Server
Session Fixation        - Angreifer erzwingt eine bekannte Session-ID beim Opfer,
                           bevor es sich einloggt, und übernimmt sie danach
Vorhersehbare Session-IDs - Session-Werte folgen einem erratbaren Muster
                           (z. B. hochzählende Zahlen statt echter Zufallswerte)
Man-in-the-Middle        - Cookie wird unverschlüsselt über HTTP mitgelesen

Die wirksamste Einzelmaßnahme dagegen ist das HttpOnly-Flag: Ohne dieses Flag kann JEDES per XSS eingeschleuste JavaScript den Cookie-Wert direkt auslesen — mit HttpOnly bleibt der Cookie für JavaScript komplett unsichtbar, selbst wenn XSS gelingt. Das Secure-Flag verhindert zusätzlich, dass der Cookie überhaupt unverschlüsselt über das Netzwerk übertragen wird.

Auf Server-Seite gilt als bewährte Praxis, Session-IDs kryptografisch zufällig (nicht vorhersehbar) zu generieren, sie nach erfolgreichem Login neu zu erzeugen (verhindert Session Fixation) und eine sinnvolle, nicht zu lange Ablaufzeit zu setzen — je kürzer das Zeitfenster, in dem ein gestohlener Cookie gültig bleibt, desto geringer der mögliche Schaden.

Signierte Cookies als zusätzliche Schutzebene

Eine weitere Verteidigungslinie sind kryptografisch signierte Cookies: Statt eine rohe, bedeutungslose Zeichenfolge als Session-ID zu verwenden, signiert der Server den Cookie-Inhalt mit einem geheimen, nur ihm bekannten Schlüssel (HMAC). Verändert ein Angreifer auch nur ein einziges Zeichen des Cookie-Werts, stimmt die Signatur beim nächsten Server-Check nicht mehr überein, und der Cookie wird sofort als ungültig zurückgewiesen — ein Angreifer kann also nicht einfach eine Nutzer-ID im Cookie manipulieren (z. B. von “user_id=42” auf “user_id=1”, um sich als ein anderer Nutzer auszugeben), ohne den geheimen Signierschlüssel zu kennen.

Session Hijacking über Netzwerkabhören

Neben den bereits genannten Methoden ist auch reines Netzwerkabhören (Sniffing) in unsicheren Umgebungen ein reales Risiko: In einem ungesicherten öffentlichen WLAN kann jeder im selben Netzwerk mit einem Tool wie Wireshark unverschlüsselten HTTP-Verkehr mitlesen und darin enthaltene Session-Cookies extrahieren — bekannt geworden durch das Browser-Add-on “Firesheep” (2010), das genau diesen Angriff auf öffentliche Netzwerke drastisch vereinfachte und massenhaft demonstrierte, wie viele damalige Websites Session-Cookies unverschlüsselt übertrugen. Der Secure-Flag zusammen mit durchgängigem HTTPS macht diesen speziellen Angriffsvektor heute praktisch wirkungslos.

Erkennung ungewöhnlicher Session-Nutzung

Als zusätzliche Verteidigungsebene überwachen manche Anwendungen Session-Nutzungsmuster auf Anomalien: Wechselt eine Session plötzlich die IP-Adresse oder den geografischen Standort innerhalb kurzer Zeit (z. B. ein Login aus Deutschland, Minuten später derselbe Session-Cookie aus einem anderen Kontinent), kann das auf einen gestohlenen, gerade von einem Angreifer genutzten Cookie hindeuten — solche Systeme können die Session automatisch invalidieren oder eine erneute Authentifizierung verlangen, statt den auffälligen Zugriff einfach zuzulassen.

Siehe auch: Cookies, Session