Eine Anmelde‑E‑Mail enthält oft eine Fähigkeit: einen Link oder Code, der den Kontostatus ändert. Das Bedrohungs‑Modellieren dieses Flusses beginnt damit, der Fähigkeit zu folgen, anstatt die Nachricht als gewöhnlichen Text zu behandeln.
Den Pfad zeichnen
Listen Sie die Anwendung, den sendenden Anbieter, das empfangende Postfach, den Browser, der die Nachricht anzeigt, und das Ziel, das durch den Link geöffnet wird. Fügen Sie Betriebsprotokolle, Support‑Screenshots und weitergeleitete Kopien hinzu. Jede zusätzliche Kopie kann die Lebensdauer oder das Publikum des Geheimnisses erweitern.
Stellen Sie an jeder Grenze eine Frage
- Anwendung zum Sender: Ist die Nachricht mit der beabsichtigten Aktion und dem Empfänger verknüpft?
- Empfänger zum Leser: Was beweist, dass dieser Browser oder dieses Konto den Posteingang einsehen darf?
- HTML zum Browser: Können entfernte Inhalte, Skripte oder Navigation eine unerwartete Anfrage erzeugen?
- Link zur Anwendung: Ist das Token auf den beabsichtigten Zweck, das Konto und die Lebensdauer beschränkt?
- Operationen zum Support: Werden Tokens aus Routinelogs und Screenshots entfernt?
Praktische Fehlerszenarien priorisieren
Testen Sie für Ihre eigene Anwendung ein wiederverwendetes Token, ein nach Ablauf geöffnetes Token, eine Adresse, die während der Verifizierung geändert wurde, und eine Nachricht, die aus einer nicht autorisierten Sitzung angezeigt wird. Verwenden Sie synthetische Konten, nicht Kunden‑Postfächer.
Das Postfach entsprechend wählen
Ein Posteingang, der für einen öffentlichen Download praktisch ist, kann für die Kontowiederherstellung ungeeignet sein. Überprüfen Sie das tatsächliche Zugriffs‑ und Aufbewahrungsmodell. Eine zufällig aussehende Adresse ist allein kein Beweis für exklusiven Zugriff. Bewahren Sie langlebige oder sensible Identitäten in einem Postfach auf, das Sie kontrollieren und wiederherstellen können.