Keine erneute Authentifizierung bei sensiblen Änderungen

Eine gekaperte Sitzung ist unangenehm, aber vorübergehend: Sie läuft ab, oder der Nutzer meldet sich ab. Es sei denn, der Angreifer kann innerhalb dieses Fensters den Wiederherstellungskanal des Kontos auf seinen eigenen Namen setzen. Dann wird aus einem vorübergehenden Problem ein dauerhafter Verlust. Diese eine zusätzliche Abfrage des Passworts macht den Unterschied.

Was ist erneute Authentifizierung?

Erneute Authentifizierung bedeutet, einen Nutzer seine Identität in dem Moment erneut nachweisen zu lassen, in dem er etwas Sensibles tun möchte, obwohl er bereits angemeldet ist. In der Praxis heißt das, das aktuelle Passwort abzufragen, und am besten auch den zweiten Faktor, bevor die Änderung durchgeführt wird.

Der Grund liegt im Unterschied zwischen zwei Fragen. Eine gültige Sitzung belegt, dass sich irgendwann jemand angemeldet hat. Sie belegt nicht, dass die Person, die jetzt an der Tastatur sitzt, dieselbe ist. Dieser Unterschied ist meist hinnehmbar: Beim Betrachten einer Übersicht oder beim Verfassen einer Nachricht ist die Sitzung eine ausreichende Grundlage. Beim Ändern der Schlüssel zum Konto ist sie es nicht.

Bei einer Bank dürfen Sie mit Ihrer Karte hineingehen und am Schalter das eine oder andere regeln. Für das Ändern Ihrer Adresse oder das Beantragen einer neuen Karte wird eine zusätzliche Legitimation verlangt. Nicht weil Sie verdächtig wären, sondern weil gerade diese Vorgänge bestimmen, wer künftig hereinkommt.

Was kann ein Angreifer ohne erneute Authentifizierung tun?

Verwundbar:

// Die Sitzung ist die einzige Voraussetzung
app.post('/konto/email', erfordertAnmeldung, async (req, res) => {
  await nutzerRepo.aendereEmail(req.nutzer.id, req.body.neueEmail);
  res.send('E-Mail-Adresse aktualisiert');
});

app.post('/konto/passwort', erfordertAnmeldung, async (req, res) => {
  await nutzerRepo.setzePasswort(req.nutzer.id, req.body.neuesPasswort);
  res.send('Passwort aktualisiert');
});

Ein Angreifer, der auf irgendeine Weise eine Sitzung erlangt, über einen unbeaufsichtigten Arbeitsplatz, ein gestohlenes Cookie, Cross-Site Scripting oder einen gemeinsam genutzten Rechner, führt nun zwei Anfragen aus. Zuerst setzt er die E-Mail-Adresse auf eine Adresse, die er verwaltet. Danach ändert er das Passwort.

Von diesem Moment an ist die Lage umgekehrt. Der rechtmäßige Inhaber kann sich nicht mehr anmelden, denn das Passwort ist geändert. Er kann keine Wiederherstellung anfordern, denn die Wiederherstellungsmail geht an die Adresse des Angreifers. Und seine eigene Sitzung läuft von selbst ab. Was als vorübergehender Zugang begann, ist zu einer dauerhaften Übernahme geworden, und das Zurückholen erfordert das Eingreifen Ihres Kundendienstes.

Sicher:

async function bestaetigeIdentitaet(req) {
  // Vor Kurzem bestätigt? Dann innerhalb dieses Fensters nicht erneut fragen
  if (req.session.bestaetigtAm > Date.now() - 10 * 60 * 1000) return true;

  const nutzer = await nutzerRepo.finde(req.nutzer.id);
  const passwortStimmt = await argon2.verify(nutzer.hash, req.body.aktuellesPasswort ?? '');
  if (!passwortStimmt) return false;

  if (nutzer.mfaAktiv && !await pruefeMfa(nutzer, req.body.mfaCode)) {
    return false;
  }
  req.session.bestaetigtAm = Date.now();
  return true;
}

app.post('/konto/email', erfordertAnmeldung, async (req, res) => {
  if (!await bestaetigeIdentitaet(req)) {
    return res.status(403).send('Bestätigen Sie zunächst Ihre Identität');
  }

  const alt = req.nutzer.email;
  // Neue Adresse wird erst nach Bestätigung über diese Adresse aktiv
  await nutzerRepo.starteEmailAenderung(req.nutzer.id, req.body.neueEmail);

  // Warnung an die alte Adresse, mit einem Weg zurück
  await mail.sende(alt, 'Für Ihr Konto wurde eine Änderung der E-Mail-Adresse beantragt. ' +
    'Waren Sie das nicht? Über diesen Link blockieren Sie die Änderung: ...');

  res.send('Prüfen Sie Ihre neue E-Mail-Adresse, um die Änderung zu bestätigen');
});

Drei Schichten erschweren den Angriff hier jeweils für sich. Die Identität wird erneut bestätigt, mit einer kurzen Gültigkeitsdauer, damit ein Nutzer, der mehrere Einstellungen anpasst, nicht ständig neu tippen muss. Die neue Adresse wird erst nach Bestätigung über diese Adresse aktiv. Und die alte Adresse erhält eine Warnung mit einer Möglichkeit einzugreifen, also genau die Meldung, die der rechtmäßige Inhaber braucht, um rechtzeitig davon zu erfahren.

Welche Auswirkungen hat fehlende erneute Authentifizierung?

Der Schweregrad reicht von mittel bis hoch. Das Kennzeichnende ist, dass dieser Befund die Folgen jedes anderen Problems verstärkt: Er entscheidet darüber, ob eine vorübergehende Kompromittierung vorübergehend bleibt.

Ohne erneute Authentifizierung ist jede gekaperte Sitzung eine mögliche dauerhafte Übernahme. Das gilt für die klassischen Szenarien, den unbeaufsichtigten Arbeitsplatz, den gemeinsam genutzten Rechner, das gestohlene Cookie, aber auch für kurze Situationen, die sonst folgenlos blieben, etwa einen Kollegen, der kurz auf einen nicht gesperrten Bildschirm blickt.

Die Folge reicht über das Konto selbst hinaus. Wer die E-Mail-Adresse eines Kontos verwaltet, kommt häufig auch in verbundene Dienste hinein, die dieselbe Adresse als Wiederherstellungskanal nutzen. Und da der rechtmäßige Inhaber ausgesperrt ist, verlagert sich das Problem zu Ihrem Kundendienst, der feststellen muss, wer der echte Inhaber ist, ein Verfahren, das seinerseits eine Angriffsfläche bildet.

Wie spürt man fehlende erneute Authentifizierung auf?

Ein Tester geht die Kontoeinstellungen durch und prüft bei jedem sensiblen Vorgang, ob er sich ohne das aktuelle Passwort abschließen lässt: das Ändern der E-Mail-Adresse, der Telefonnummer und des Passworts, das Abschalten der Zwei-Faktor-Authentifizierung, das Erstellen von API-Schlüsseln und das Löschen des Kontos.

Entscheidend ist dabei die Prüfung auf der Serverseite. Anwendungen fragen mitunter sehr wohl im Formular nach dem aktuellen Passwort, prüfen es aber nicht wirklich; eine direkte Anfrage ohne dieses Feld gelingt dann einfach. Das wird ausdrücklich getestet. Ebenso wird geprüft, ob die Änderung einer E-Mail-Adresse erst nach Bestätigung über die neue Adresse wirksam wird, ob die alte Adresse eine Warnung erhält und ob bestehende Sitzungen nach einem Passwortwechsel widerrufen werden. Auch wird beurteilt, ob die API dieselben Anforderungen stellt wie die Weboberfläche, denn diese beiden laufen in der Praxis regelmäßig auseinander. AssistSec prüft diese Punkte als zusammenhängendes Ganzes, denn die Widerstandsfähigkeit bestimmt sich nach dem schwächsten der beteiligten Wege.

Wie verhindert man fehlende erneute Authentifizierung?

• Fragen Sie das aktuelle Passwort ab, bevor Sie Passwort, E-Mail-Adresse oder Telefonnummer ändern.
• Fragen Sie dabei auch den zweiten Faktor ab, sofern dieser eingeschaltet ist.
• Prüfen Sie diese Bestätigung serverseitig und nicht nur im Formular.
• Lassen Sie eine neue E-Mail-Adresse erst nach Bestätigung über diese Adresse wirksam werden.
• Senden Sie eine Warnung an die alte Adresse, mit einer Möglichkeit, die Änderung zu blockieren.
• Widerrufen Sie nach einem Passwortwechsel alle übrigen Sitzungen und Token.
• Verlangen Sie auch beim Abschalten der Zwei-Faktor-Authentifizierung und beim Erstellen von API-Schlüsseln eine erneute Bestätigung.
• Halten Sie die Bestätigung kurz gültig, damit ein Nutzer mehrere Einstellungen anpassen kann, ohne jedes Mal neu zu tippen.
• Stellen Sie an die API dieselben Anforderungen wie an die Weboberfläche.