MB Dev .tech
Registrieren Login

Sicherheit Basics · Sessions & Hardening

← Zurück zu Sicherheit Basics

Sessions sind die Grundlage für Login-Zustände im Web. Sie sind praktisch – aber wenn man sie falsch behandelt, entstehen schnell Sicherheitsprobleme.

Merke
Die Session-ID ist der „Schlüssel“ zum Account

Wer die Session-ID eines eingeloggten Nutzers übernimmt, kann sich oft als dieser Nutzer ausgeben – ohne Passwort.

1) Was ist eine Session?

HTTP ist „zustandslos“. Das heißt: Jede Anfrage ist erstmal unabhängig. Eine Session ist der Trick, um trotzdem zu wissen: „Dieser Browser gehört zu diesem Nutzer.“

Technisch läuft es meist so:

  • Der Server erzeugt eine Session-ID (zufälliger Token).
  • Der Browser speichert sie in einem Cookie.
  • Bei jedem Request wird sie wieder mitgesendet.
Tipp
Session = Server-Zustand + Cookie als Schlüssel

Der Cookie enthält nicht „den Nutzer“, sondern nur den Schlüssel, um den Nutzer serverseitig zu finden.

2) Häufige Session-Risiken

  • Session Hijacking: Session-ID wird gestohlen (z.B. über XSS oder unsichere Verbindung).
  • Session Fixation: Angreifer „setzt“ eine bekannte Session-ID, die der Nutzer später nutzt.
  • Unsichere Cookie-Flags: Cookie ist zu „offen“ (fehlendes Secure/HttpOnly/SameSite).
Achtung
XSS und Sessions hängen zusammen

XSS kann Session-Daten stehlen oder Aktionen ausführen, während der Nutzer eingeloggt ist. Deshalb sind XSS-Schutz und Session-Hardening ein Paket.

3) Nach dem Login: Session-ID regenerieren

Eine der wichtigsten Maßnahmen gegen Session Fixation: Sobald der Nutzer sich erfolgreich einloggt, erzeugst du eine neue Session-ID.

Session regenerieren nach Login

session_start();

// ... Login erfolgreich geprüft ...

session_regenerate_id(true); // "true" löscht die alte Session

$_SESSION['user_id'] = 123;  // Beispiel: Nutzer-ID merken
Merke
Login ist ein „Sicherheits-Übergang“

Vor Login: anonyme Session. Nach Login: Session ist „wertvoll“. Darum: ID wechseln.

4) Cookie-Flags: Secure, HttpOnly, SameSite

Session-Cookies sollten möglichst restriktiv sein:

  • Secure: Cookie nur über HTTPS senden
  • HttpOnly: JavaScript kann Cookie nicht auslesen
  • SameSite: erschwert CSRF

Beispiel (konzeptionell), wie man Session-Cookie-Parameter setzt:

Session-Cookie absichern (Prinzip)

session_set_cookie_params([
    'lifetime' => 0,
    'path'     => '/',
    'secure'   => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);

session_start();
Tipp
SameSite=Lax ist ein guter Standard

Für viele klassische Web-Apps passt Lax sehr gut. Für Spezialfälle (z.B. Drittanbieter-Embeds) braucht man manchmal andere Einstellungen.

5) Timeouts, Inaktivität und Logout

Sessions sollten nicht ewig gültig sein. Ein einfaches Konzept ist: „Wenn der Nutzer lange nichts macht, läuft die Session aus.“

Inaktivität prüfen (Prinzip)

session_start();

$now = time();
$maxIdleSeconds = 30 * 60; // 30 Minuten

$last = (int)($_SESSION['last_activity'] ?? 0);

if ($last > 0 && ($now - $last) > $maxIdleSeconds) {
    // Session abgelaufen
    session_unset();
    session_destroy();
}

$_SESSION['last_activity'] = $now;
Achtung
Timeouts sind ein Trade-off

Zu kurz: Nutzer werden genervt ausgeloggt. Zu lang: mehr Risiko bei fremdem Zugriff. In der Praxis muss man einen sinnvollen Mittelweg wählen.

6) Praktische Regeln für sichere Sessions

  • HTTPS verwenden (sonst kann die Session-ID mitgelesen werden).
  • Nach Login immer session_regenerate_id(true).
  • Cookie-Flags setzen: Secure, HttpOnly, SameSite.
  • XSS verhindern (sonst kann ein Angreifer Aktionen in deinem Kontext ausführen).
  • Sensible Aktionen optional nochmal bestätigen (z.B. Passwort erneut abfragen).
Merke
Session-Sicherheit ist ein Paket

Sessions sind nicht „ein Flag“, sondern mehrere Maßnahmen, die zusammen die Angriffsfläche reduzieren.

Kleine Aufgaben (zum Mitdenken)

Aufgabe 1: Warum regeneriert man nach Login die Session-ID?

Erkläre in einem Satz, warum session_regenerate_id(true) nach dem Login wichtig ist.

Lösung einblenden
Lösung
Schutz vor Session Fixation

Weil eine vorher bekannte oder manipulierte Session-ID nach dem Login wertvoll wäre. Durch die Regeneration bekommt der eingeloggte Zustand eine frische, neue ID.