Sitzungen laufen nicht ab

Beim Anmelden wird oft sorgfältig über Passwörter und zweite Faktoren nachgedacht, während die Frage, wie lange die daraus entstehende Sitzung gültig bleibt, unbeantwortet bleibt. Dabei entscheidet genau diese Antwort darüber, wie viel ein gestohlenes Token wert ist. Im Folgenden lesen Sie, warum eine Sitzung zwei verschiedene Uhren braucht und was schiefgeht, wenn beide fehlen.

Was bedeutet es, dass eine Sitzung nicht abläuft?

Nach einer erfolgreichen Anmeldung erhält der Nutzer eine Sitzungskennung, meist in einem Cookie. Solange dieser Wert gültig ist, muss er sich nicht erneut anmelden: Das Token ist der Nachweis der Authentifizierung. Eine Sitzung, die nicht abläuft, ist ein Token, das diesen Nachweis unbegrenzt weiter liefert, unabhängig davon, wie viel Zeit vergeht oder was zwischenzeitlich geschieht.

Vergleichen Sie es mit einem Zutrittsausweis, der nach der Ausgabe nie wieder ungültig wird. Solange der Ausweis in der Brieftasche des rechtmäßigen Inhabers steckt, ist alles in Ordnung. Ein Ausweis jedoch, der vor zwei Jahren in einem Taxi liegen blieb, öffnet heute noch dieselben Türen. Das Problem ist nicht die Ausgabe, sondern das fehlende Verfallsdatum.

In der Praxis sollte es zwei Grenzen geben. Die erste ist ein Untätigkeitslimit: Geschieht eine Zeit lang nichts, verfällt die Sitzung. Die zweite ist eine absolute Höchstdauer: Unabhängig von der Aktivität endet die Sitzung nach so vielen Stunden. Fehlt diese zweite Grenze, kann ein Angreifer eine gestohlene Sitzung endlos offen halten, indem er hin und wieder eine Anfrage damit sendet.

Wie werden Sitzungen ohne Ablauf ausgenutzt?

Der Unterschied liegt darin, ob der Server die Gültigkeit selbst überwacht oder das Token akzeptiert, solange es formal stimmt.

Verwundbar:

// Die Sitzung wird angelegt und danach nie wieder beurteilt
app.post('/anmelden', async (req, res) => {
  const nutzer = await pruefeZugangsdaten(req.body);
  if (!nutzer) return res.status(401).send('Ungültige Daten');

  req.session.userId = nutzer.id;
  res.send('Willkommen');
});

function aktuellerNutzer(req) {
  return req.session.userId ?? null;   // gültig, immer
}

Nirgends wird festgehalten, wann die Sitzung begann oder wann sie zuletzt genutzt wurde. Solange der Sitzungsdatensatz besteht, ist der Nutzer angemeldet. Ein Cookie, das auf einem gemeinsam genutzten Rechner im Browser zurückbleibt, in einer Sicherung eines Profils landet oder einmal über eine Netzwerkabhörung erbeutet wurde, bleibt damit nutzbar, bis jemand die Sitzungstabelle von Hand aufräumt.

Sicher:

const UNTAETIGKEIT = 30 * 60 * 1000;        // 30 Minuten
const ABSOLUT = 8 * 60 * 60 * 1000;         // 8 Stunden

app.post('/anmelden', async (req, res) => {
  const nutzer = await pruefeZugangsdaten(req.body);
  if (!nutzer) return res.status(401).send('Ungültige Daten');

  req.session.regenerate(() => {           // neue ID, gegen Session Fixation
    req.session.userId = nutzer.id;
    req.session.gestartetAm = Date.now();
    req.session.zuletztGesehen = Date.now();
    res.send('Willkommen');
  });
});

app.use((req, res, next) => {
  const s = req.session;
  if (!s?.userId) return next();

  const jetzt = Date.now();
  if (jetzt - s.zuletztGesehen > UNTAETIGKEIT || jetzt - s.gestartetAm > ABSOLUT) {
    return s.destroy(() => res.status(401).send('Sitzung abgelaufen'));
  }

  s.zuletztGesehen = jetzt;                // verschiebt nur die Untätigkeitsuhr
  next();
});

Der Server überwacht nun zwei Dinge gleichzeitig. Die Untätigkeitsuhr wird bei jeder Anfrage zurückgesetzt, sodass ein aktiver Nutzer nicht gestört wird. Die absolute Uhr läuft ab dem Moment der Anmeldung und lässt sich nicht verlängern, und genau dieser Unterschied verhindert, dass ein Angreifer eine erbeutete Sitzung endlos am Leben hält. Sobald eine der beiden Grenzen überschritten wird, wird die Sitzung serverseitig vernichtet.

Welche Auswirkungen haben Sitzungen ohne Ablauf?

Dies ist selten eine Schwachstelle, über die ein Angreifer hereinkommt; es ist eine Schwachstelle, die bestimmt, wie lange er drinbleibt. Der Schweregrad fällt deshalb meist niedrig bis mittel aus, je nachdem, was hinter der Sitzung liegt.

Das Szenario, auf das es am meisten ankommt, ist der gemeinsam genutzte oder öffentliche Arbeitsplatz: ein Empfangstresen, ein Schulrechner, ein Tablet in einem Wartebereich. Der Nutzer schließt das Fenster, steht auf und geht. Die nächste Person öffnet den Browser und sitzt im Konto. Das erfordert keinerlei technische Fertigkeit und kommt regelmäßig vor.

Darüber hinaus erhöht eine unbegrenzte Sitzung den Wert jeder anderen Schwachstelle. Ein Token, das über Cross-Site Scripting, eine Netzwerkabhörung oder eine offengelegte Protokollzeile erbeutet wurde, ist bei einem strengen Zeitlimit höchstens eine halbe Stunde nutzbar. Ohne Zeitlimit ist es ein dauerhafter Schlüssel, der ohne Passwortwechsel nicht ungültig wird, und selbst ein Passwortwechsel hilft nicht, wenn bestehende Sitzungen dabei nicht widerrufen werden.

Wie spürt man Sitzungen ohne Ablauf auf?

Der Test ist einfach angelegt, kostet aber Zeit: Ein Tester meldet sich an, hält das Sitzungstoken fest und versucht, es nach einer längeren Zeit des Nichtstuns erneut zu verwenden. Funktioniert es dann noch, fehlt das Untätigkeitslimit.

Die zweite Messung ist feiner. Indem die Sitzung mit einer regelmäßigen Anfrage künstlich am Leben gehalten wird, lässt sich prüfen, ob eine absolute Obergrenze besteht. Viele Anwendungen haben die erste Maßnahme und die zweite nicht. Zusätzlich wird geprüft, ob die Ablaufzeit tatsächlich serverseitig durchgesetzt wird; dazu entfernt ein Tester schlicht das Ablaufdatum des Cookies und schaut, ob das Token dennoch akzeptiert wird. Ebenso relevant: Gelten die Zeitlimits auch für API-Token und für die mobile Anwendung, oder nur für die Weboberfläche? AssistSec prüft diese Szenarien gesondert, denn ein strenges Zeitlimit im Web ist wenig wert, wenn dieselbe Authentifizierung über eine API unbegrenzt gültig bleibt.

Wie verhindert man Sitzungen ohne Ablauf?

• Setzen Sie ein Untätigkeitslimit, das zur Sensibilität der Anwendung passt, und führen Sie diese Uhr serverseitig.
• Ergänzen Sie eine absolute Höchstdauer, die sich durch Aktivität nicht verlängern lässt.
• Vernichten Sie die Sitzung beim Ablauf serverseitig; belassen Sie es nicht beim Entfernen des Cookies.
• Geben Sie dem Nutzer vor dem Ablauf eine sichtbare Warnung mit der Möglichkeit, die Sitzung zu verlängern.
• Behandeln Sie “Angemeldet bleiben” als eigenes, widerrufbares Token und nicht als Sitzung ohne Ende.
• Widerrufen Sie alle bestehenden Sitzungen bei einem Passwortwechsel, einer Rechteänderung oder dem Sperren eines Kontos.
• Wenden Sie dieselben Regeln auf API-Token und mobile Clients an, nicht nur auf die Weboberfläche.
• Bieten Sie Nutzern eine Übersicht aktiver Sitzungen mit der Möglichkeit, diese aus der Ferne zu beenden.