Session

In PHP/Python: $_SESSION['cart'] = 'iPhone'; (PHP) request.session['user'] = 'Max' (Django) Das Framework generiert automatisch die ID, setzt das Cookie und speichert die Daten in einer Datei (oder Datenbank). Du musst dich um die Details nicht kümmern.

Praxisroutine

In der Praxis lernst du Session, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Storage Backend (File vs. Redis)

Standardmäßig speichern Frameworks Sessions als Dateien auf der Festplatte. Schlecht bei vielen Usern (Festplatte langsam). Schlecht bei mehreren Servern (Server B kennt die Datei von Server A nicht). Lösung: Redis oder Memcached. Schneller RAM-Speicher, auf den alle Server zugreifen können.

2. Session Fixation Attack

Hacker schickt dir einen Link: bank.com?PHPSESSID=hacker123. Du klickst drauf und loggst dich ein. Die Bank benutzt die ID hacker123 für deine Session. Der Hacker kennt die ID ja schon. Er ist jetzt auch eingeloggt. Schutz: Regenerate ID. Nach dem Login muss der Server sofort die alte ID wegwerfen und eine neue generieren.

3. Session Hijacking

Wenn der Hacker dein Session-Cookie klaut (via XSS oder unverschlüsseltem WLAN), ist er du. Gegenmaßnahmen:

• HTTPS erzwingen (Secure Flag).
• IP-Bindung (Schwierig, da Handy-IPs oft wechseln).
• User-Agent prüfen (Wenn sich Browser plötzlich von Chrome zu Firefox ändert -> Verdächtig -> Logout).

1. Deserialisierungs-Vulnerabilities

Sessions speichern oft komplexe Objekte (z.B. ein User-Objekt mit Rechten). Damit das auf die Festplatte oder in Redis passt, muss es in einen String umgewandelt werden (Serialisierung). In Python nutzt man oft pickle, in Java die Standard-Serialisierung. Gefahr: Wenn ein Angreifer es schafft, den Inhalt des Session-Speichers zu manipulieren (z.B. durch einen Fehler im Redis-Zugang), kann er manipulierten Code einschleusen. Sobald der Server die Session wieder einliest (Deserialisierung), wird der Schadcode mit Server-Rechten ausgeführt. Sichere Web-Frameworks nutzen heute fast nur noch JSON oder signierte Strings für Sessions, da diese keine Logik ausführen können.

2. Session Ghosting & Race Conditions

Was passiert, wenn ein User zwei Tabs gleichzeitig offen hat und in beiden Tabs etwas in den Warenkorb legt? Tab A sendet Request 1 -> Server liest Session -> Fügt "Apfel" hinzu. Tab B sendet Request 2 -> Server liest Session -> Fügt "Birne" hinzu. In einem schlechten System "schlägt" das Speichern von Tab B das Speichern von Tab A (Last Write Wins). Der Apfel ist weg. Fortgeschrittene Session-Manager nutzen Optimistic Locking: Beim Speichern wird geprüft, ob sich die Session-Datenbank während der Verarbeitung geändert hat. Wenn ja, muss der Request wiederholt werden.

3. Rolling Sessions & Sliding Window TTL

Wie lange bleibt eine Session gültig?

• Fixed TTL: Nach 30 Minuten wirst du ausgeloggt, egal ob du gerade arbeitest oder nicht (nervig).
• Rolling TTL (Sliding Window): Jedes Mal, wenn der User eine Seite aufruft, setzt der Server den Ablauf-Timer zurück auf 30 Minuten. Technisch bedeutet das: Bei jedem Klick muss der Server ein EXPIRE Kommando an die Redis-Datenbank schicken. Das erzeugt bei Millionen Usern eine enorme Last auf dem Redis. Große Plattformen aktualisieren den Timer daher oft nur "ungefähr" (z.B. nur alle 5 Minuten oder bei wichtigen Aktionen), um die Datenbank zu entlasten.