Sitzung bleibt nach dem Löschen eines Kontos gültig

Das Sperren eines Kontos fühlt sich wie eine endgültige Handlung an: Der Schalter ist umgelegt, der Zugang ist entzogen. Für alle, die in diesem Moment nicht angemeldet sind, stimmt das. Für alle, die sehr wohl eine aktive Sitzung haben, ändert sich in vielen Anwendungen überhaupt nichts. Im Folgenden lesen Sie, woran das liegt und warum dies ein Problem der Zugriffskontrolle ist und keines der Sitzungsverwaltung.

Was läuft beim Löschen eines Kontos schief?

Bei der Anmeldung stellt die Anwendung fest, wer jemand ist und ob er Zugang haben darf. Dieses Ergebnis wird in der Sitzung festgehalten. Bei jeder weiteren Anfrage wird anschließend nur noch die Sitzung herangezogen: Steht dort eine Nutzernummer, ist der Nutzer angemeldet.

Bleibt die Sitzung nach dem Löschen eines Kontos gültig, wurde diese Argumentation nie unterbrochen. Bei der zweiten und jeder folgenden Anfrage fragt sich die Anwendung nicht mehr, ob dieses Konto noch besteht, noch aktiv ist und noch dieselben Rechte hat. Sie vertraut auf eine Entscheidung, die zu einem früheren Zeitpunkt getroffen wurde.

Das gleicht einem Besucherausweis, der beim Eintritt geprüft wird und danach nicht mehr. Wird dem Besucher unterwegs der Zutritt entzogen, sollten die Türen davon wissen. Bei einem System, das nur am Eingang prüft, läuft er einfach weiter.

Wie wird eine Sitzung nach dem Löschen des Kontos ausgenutzt?

Verwundbar:

// Die Sitzung ist die einzige Quelle der Wahrheit
function aktuellerNutzer(req) {
  if (!req.session.userId) return null;
  return {
    id: req.session.userId,
    rolle: req.session.rolle,      // bei der Anmeldung festgehalten
  };
}

app.delete('/verwaltung/nutzer/:id', async (req, res) => {
  await nutzer.entferne(req.params.id);
  res.send('Nutzer gelöscht');     // Sitzungen bleiben unberührt
});

Der Administrator löscht das Konto und erhält eine Bestätigung. In der Nutzertabelle ist die Zeile verschwunden, in der Übersicht taucht der Name nicht mehr auf. Die Sitzung dieses Nutzers besteht jedoch weiter, mit der Nutzernummer und der Rolle darin. Seine nächste Anfrage läuft ohne jede Hürde durch:

GET /vorgaenge/export HTTP/1.1
Host: portal.example
Cookie: sid=8f42c19ade7b3f5c

HTTP/1.1 200 OK

Der Nutzer existiert nicht mehr und hat weiterhin Zugang. Bei einem Mitarbeiter, der fristlos gegangen ist, ist das genau das Zeitfenster, in dem der größte Schaden entsteht.

Sicher:

// Bei jeder Anfrage wird der aktuelle Status abgerufen
async function aktuellerNutzer(req) {
  if (!req.session.userId) return null;

  const nutzer = await nutzerRepo.finde(req.session.userId);
  if (!nutzer || nutzer.status !== 'aktiv') {
    await req.session.destroy();
    return null;
  }
  return nutzer;                   // einschließlich der Rechte dieses Moments
}

app.delete('/verwaltung/nutzer/:id', async (req, res) => {
  await nutzerRepo.sperre(req.params.id);
  await sitzungen.entferneFuerNutzer(req.params.id);   // aktiv aufräumen
  await tokens.widerrufe(req.params.id);
  await auditlog.schreibe('Konto gesperrt', { durch: req.nutzer.id });
  res.send('Nutzer gesperrt und Sitzungen beendet');
});

Nun geschehen zwei Dinge, die einander ergänzen. Die Autorisierungsprüfung zieht bei jeder Anfrage den aktuellen Status heran statt der gespeicherten Momentaufnahme, wodurch auch zwischenzeitlich geänderte Rechte sofort gelten. Und beim Sperren werden bestehende Sitzungen und Token aktiv aufgeräumt, sodass der Zugang unmittelbar endet statt erst bei der nächsten Anfrage.

Welche Auswirkungen hat eine Sitzung nach dem Löschen des Kontos?

Der Schweregrad reicht von mittel bis hoch, abhängig davon, wer gesperrt wird und weshalb. Geht es um eine routinemäßige Bereinigung eines ungenutzten Kontos, ist die Wirkung gering. Geht es um einen erzwungenen Weggang, einen Betrugsverdacht oder ein kompromittiertes Konto, ist dies der Moment, in dem die Maßnahme greifen muss.

Das häufigste Szenario ist ein ausscheidender Mitarbeiter. Die Personalabteilung meldet den Weggang, der Administrator sperrt das Konto, und der Vorgang gilt als abgeschlossen. Bleibt die Sitzung auf dem Laptop dieses Mitarbeiters gültig, hat er noch Stunden oder Tage Zugriff auf Kundendaten, Dokumente und Systeme, und zwar genau in dem Zeitraum, in dem die Organisation den Zugang für entzogen hält.

Noch unangenehmer ist das zweite Szenario: Ein Konto ist kompromittiert, dies wird entdeckt, und das Konto wird als erste Maßnahme gesperrt. Behält der Angreifer seine Sitzung, ist die Reaktion auf den Vorfall faktisch gescheitert, während alle das Problem für eingedämmt halten. Damit ist dieser Befund nicht nur ein technisches, sondern auch ein organisatorisches Risiko: Er untergräbt das Vertrauen in die eigenen Maßnahmen.

Wie spürt man eine Sitzung nach dem Löschen des Kontos auf?

Der Test verlangt zwei Konten. Ein Tester meldet sich als Zielnutzer an, lässt diese Sitzung offen und sperrt oder löscht das Konto aus einem Administratorkonto heraus. Anschließend wird mit der ersten Sitzung eine Anfrage an eine geschützte Route gesendet. Funktioniert das noch, ist der Befund nachgewiesen.

Dieselbe Anordnung wird für Varianten wiederholt, die häufig getrennt umgesetzt sind: der Entzug einer Rolle, die Änderung einer Gruppenmitgliedschaft, das Deaktivieren eines Kontos in einem zentralen Verzeichnis sowie das Auslaufen einer Lizenz oder eines Abonnements. In der Praxis zeigt sich regelmäßig, dass das Sperren sehr wohl wirkt, der Entzug von Rechten jedoch nicht, oder umgekehrt. Ebenso wird geprüft, ob Token für API-Zugriff, mobile Anwendungen und Integrationen einbezogen werden, denn diese werden beim Aufräumen oft vergessen. AssistSec prüft dabei ausdrücklich die Zeitspanne: Wie lange bleibt die alte Lage in Kraft, und ist dieses Fenster für die Art der Daten hinter der Anwendung vertretbar?

Wie verhindert man eine Sitzung nach dem Löschen des Kontos?

• Rufen Sie Status und Rechte des Nutzers bei jeder Anfrage ab, statt sie in der Sitzung einzufrieren.
• Entfernen Sie beim Sperren oder Löschen eines Kontos aktiv alle zugehörigen Sitzungen und Token.
• Widerrufen Sie ebenso API-Schlüssel, Refresh-Token und Anbindungen mobiler Anwendungen.
• Lassen Sie einen fehlenden Nutzer oder eine fehlende Rolle stets zur Verweigerung führen, nie zum Durchlassen.
• Nutzen Sie einen kurzen Cache für den Kontostatus, wenn die Leistung eine Rolle spielt, und leeren Sie diesen bei einer Änderung.
• Wenden Sie dasselbe Vorgehen beim Entzug von Rollen und Gruppenmitgliedschaften an, nicht nur beim Sperren des gesamten Kontos.
• Frischen Sie bei föderierter Authentifizierung den Status regelmäßig auf statt nur bei der Anmeldung.
• Halten Sie Sperrungen und das Beenden von Sitzungen in einem Auditprotokoll fest, damit nachträglich nachweisbar ist, wann der Zugang tatsächlich endete.