Link-Scanner und Einmal-Geheimnisse

Ein Einmal-Link, der schon bei einem einfachen GET gelöscht wird, ist in dem Moment verbraucht, in dem Slack, Teams oder ein E-Mail-Gateway ihn für eine Vorschau abruft. Die Lösung: Auf GET nur Metadaten zurückgeben und das Geheimnis erst bei einem ausdrücklichen POST zum Anzeigen löschen, mit einer Passphrase über einen zweiten Kanal als Absicherung. Dieser Beitrag zeigt, welche Systeme Links ungefragt abrufen und wie Sie Ihr Design gegen alle davon absichern.

Der Generator für Einmal-Links von LinkPilot ist genau so gebaut: Ein Vorschauabruf bekommt nur das Seitengerüst. Das Geheimnis wird erst abgerufen und der Aufruf erst gezählt, wenn ein Browser die Seite ausführt.

Der übliche Fehler

Die meisten Chat- und E-Mail-Programme versuchen, eine Vorschau anzuzeigen, sobald sie eine URL sehen. Der Ablauf sieht so aus:

1. Jemand fügt den Secret-Link in Slack ein.
2. Der Vorschau-Bot von Slack ruft die URL ab (mit GET; Slack dokumentiert das Verhalten unter Link Unfurling).
3. Ihr Handler für das Anzeigen behandelt die Anfrage wie einen menschlichen Aufruf, löscht das Geheimnis und gibt den Inhalt zurück.
4. Slack erhält den gelöschten Inhalt (oder eine allgemeine Seite) und zeigt ihn an.
5. Der Mensch klickt auf den Link, sieht „bereits angesehen“ und bittet den Absender um einen neuen.

Der Vorschau-Bot hatte keine böse Absicht. Ihr Handler hat „jemand hat die URL abgerufen“ mit „der Empfänger hat das Geheimnis gelesen“ gleichgesetzt. Das sind zwei verschiedene Ereignisse, und die ganze Designaufgabe besteht darin, sie auseinanderzuhalten.

In Schritt 3 steckt eine noch schlimmere Variante: Hat das GET des Vorschau-Bots den eigentlichen Inhalt erhalten, liegt das Geheimnis jetzt in der Infrastruktur eines Dritten, die Vorschauen erzeugt. Im besten Fall wurde es nach dem Erstellen der Vorschau verworfen. Bestätigen können Sie das aber nicht, und kein Audit-Ereignis sagt Ihnen, dass es passiert ist.

Wer ruft einen Link ab, bevor der Empfänger ihn öffnet?

Vorschau-Bots von Chat-Programmen, E-Mail-Sicherheitsgateways, Endpoint-Schutz, Firmen-Proxys und Vorschau-Erweiterungen, meist mehrere davon. „Slack zeigt Vorschauen an“ unterschätzt das Problem. Eine URL, die an einem modernen Arbeitsplatz eingefügt wird, rufen typischerweise mehrere Systeme ab, bevor irgendein Mensch klickt:

Das Verhalten der Anbieter in dieser Tabelle ändert sich laufend. Lesen Sie Angaben zu einzelnen Gateways als „Stand Juli 2026, mit der aktuellen Dokumentation abgleichen“. Der gemeinsame Nenner bleibt aber: Jedes dieser Systeme sendet ein einfaches GET, weil das der einzige sichere und universelle Weg ist, sich eine URL anzusehen, die man nicht kontrolliert.

Wie verhindern Sie, dass eine Vorschau einen Einmal-Link löscht?

Liefern Sie auf GET Metadaten aus und löschen Sie nur bei einem ausdrücklichen POST. Die HTTP-Semantik gibt das schon her: RFC 9110, Abschnitt 9.2.1 definiert GET als sicher und idempotent, also als Anfrage, die jeder frei senden darf, weil sie nichts verändern soll. POST ist das Verb für Aktionen. Behandeln Sie das Anzeigen deshalb als POST-Aktion hinter einer sichtbaren Schaltfläche:

GET  /s/abc123   →  HTML page: "Click to reveal this secret"
POST /s/abc123   →  burns the secret, returns the payload

Jetzt liefert das GET von Slack eine neutrale Seite mit Metadaten. Das Geheimnis wird erst gelöscht, wenn der Mensch auf die Schaltfläche klickt. Ein Scanner, der sich an die HTTP-Semantik hält, berührt den Inhalt nie. Das tun fast alle, denn POST-Anfragen mit Nebenwirkungen an beliebige URLs würden das halbe Web kaputt machen.

Ein Ablauf Schritt für Schritt

Verfolgen Sie einen Link von Anfang bis Ende. Sie erstellen ein Geheimnis mit Löschen nach dem Lesen und einer Passphrase und fügen die URL in eine Slack-Direktnachricht und in eine E-Mail ein.

1. Der Vorschau-Bot von Slack sendet GET /s/abc123. Antwort: eine kleine Seite mit Metadaten, Status „active“, Passphrase erforderlich. Kein Aufruf gezählt. Das Geheimnis existiert noch.
2. Das E-Mail-Gateway des Empfängers schreibt die URL in der E-Mail um und ruft sie bei der Zustellung zur Reputationsprüfung ab. Dasselbe GET, dieselben Metadaten. Das Geheimnis existiert weiter.
3. Der Empfänger klickt auf den Link in der E-Mail. Der Scanner des Gateways ruft ihn beim Klick noch einmal ab (GET) und leitet den Browser dann weiter.
4. Der Browser lädt die Seite zum Anzeigen, wieder mit einem GET. Die Seite zeigt eine Schaltfläche zum Anzeigen und ein Feld für die Passphrase. Weiterhin kein Aufruf gezählt.
5. Der Empfänger gibt die Passphrase ein und klickt auf „Anzeigen“. Der Browser sendet POST /s/abc123. Der Aufruf wird gezählt, der Inhalt zurückgegeben, das Geheimnis gelöscht.
6. Wer die URL danach abruft, bekommt statt Inhalt eine ausdrückliche Antwort „bereits angesehen und gelöscht“.

Fünf Abrufe, ein Anzeigen. Dieses Verhältnis ist in einem Unternehmensnetz normal. Ein Design, das damit nicht umgehen kann, scheitert am ersten Tag, und der Absender fügt das Passwort dann einfach direkt in den Chat ein.

Mehrere Schutzschichten

Die Trennung von GET und POST

Sie fängt jeden Vorschau-Bot und Scanner ab, der sich an die Regeln hält, und das ist der weitaus größte Teil des automatisierten Verkehrs. Das ist die Grundlage, alles Weitere ist zusätzliche Tiefe.

Passphrase als Sperre

Sie deckt ab, was die Trennung nicht schafft: Sandboxes, die JavaScript ausführen und mit der Seite interagieren, dazu versehentliche Klicks von Menschen und weitergeleitete E-Mails. Eine Detonations-Sandbox kann auf eine Schaltfläche zum Anzeigen klicken. Eine Passphrase, die über einen anderen Kanal kam, kann sie nicht eingeben. Schicken Sie den Link per E-Mail und die Passphrase per Slack-Direktnachricht oder SMS.

Filtern von Bot-User-Agents

Verwerfen Sie bekannte Vorschau-Bots (Slackbot, LinkedInBot, Twitterbot), bevor sie die Logik zum Anzeigen erreichen. Das lohnt sich als zusätzliche Sicherung, reicht allein aber nie: Sicherheitsscanner geben sich regelmäßig mit echten Browser-User-Agents aus, gerade damit sich bösartige Seiten nicht vor der Analyse verstecken können.

Kurzer Ablauf

Begrenzen Sie das Zeitfenster für Schaden. Ein Link, der fünfzehn Minuten gültig war, hinterlässt in Scannern, Logdateien und Chatverläufen eine URL, die auf nichts mehr verweist.

Cache-Control: no-store

Setzen Sie den Header bei jeder Antwort zum Anzeigen, damit keine Zwischenstation (Firmen-Proxy, CDN, Browser-Cache) nach dem einen legitimen Lesen eine Kopie des Inhalts behält.

Speziell: E-Mail-Sicherheitsgateways

Firmen-Gateways verdienen einen eigenen Abschnitt, weil sie zweimal abrufen. Produkte dieser Art (Microsoft Defender Safe Links ist das dokumentierte Beispiel) schreiben jede URL in eingehenden E-Mails auf ihre eigene Scan-Domain um. Die URL wird typischerweise einmal bei der Zustellung zur Reputationsprüfung abgerufen und noch einmal beim Klick, bevor der Mensch zum echten Ziel weitergeleitet wird.

Würde einer dieser Abrufe das Geheimnis löschen, sähe der Empfänger immer einen toten Link. Für Nutzer wirkt dieser Fehler zufällig, tatsächlich ist er völlig vorhersehbar. Die Trennung von GET und POST fängt beide Abrufe ohne Zusatzaufwand ab, denn beide sind einfache GET-Anfragen. Die Weiterleitung beim Klick bringt den Menschen dann auf die Seite zum Anzeigen, wo das POST stattfindet.

Sonderfälle, die trotzdem Probleme machen

• Sandboxes, die JavaScript ausführen. Manche Detonationsumgebungen rendern die Seite und interagieren mit ihr. Ein POST hinter einer Schaltfläche ohne Passphrase könnte eine aggressive Sandbox im Prinzip auslösen. Die Passphrase ist die letzte Absicherung.
• Link und Passphrase im selben Kanal. Gehen beide in derselben E-Mail raus, schrumpft jeder Schutz oben auf „hoffentlich liest niemand diese E-Mail“. Trennen Sie die Kanäle immer.
• Weiterleiten. Jede Weiterleitung in einen neuen Chat oder ein neues Mailsystem löst eine neue Runde von Vorschauabrufen aus. Mit der Trennung ist das harmlos, aber jede Station ist ein weiterer Satz Logs mit der URL. Das spricht für einen kurzen Ablauf.
• Gleichzeitiges Anzeigen. Klicken zwei Personen gleichzeitig auf „Anzeigen“, müssen Lesen und Löschen in einem einzigen, unteilbaren Schritt geschehen: Genau eine Anfrage gewinnt, die andere bekommt „bereits angesehen“. Trennt die Umsetzung diese beiden Schritte, kann sie den Inhalt zweimal ausliefern.

Testen Sie Ihr eigenes Tool

Bevor Sie einem Dienst zum Teilen von Geheimnissen echte Zugangsdaten anvertrauen, machen Sie diese Prüfung, die zwei Minuten dauert:

1. Erstellen Sie ein Wegwerf-Geheimnis mit aktiviertem Löschen nach dem Lesen.
2. Rufen Sie es im Terminal ab, genau wie ein Vorschau-Bot: curl -s -o /dev/null -w "%{http_code}" "<url>"
3. Öffnen Sie den Link im Browser. Sehen Sie „bereits angesehen“, löscht das Tool schon bei GET und ist nicht sicher genug, um den Link in einen Chat oder eine E-Mail einzufügen.
4. Hat das Geheimnis überlebt, zeigen Sie es im Browser regulär an und rufen Sie es dann noch einmal mit curl ab. Jetzt sollten Sie eine ausdrückliche Antwort „nicht mehr vorhanden/gelöscht“ bekommen, nicht den Inhalt.

Wie LinkPilot das umsetzt

Zur Einordnung: Dieses Design nutzen die Secret-Links von LinkPilot. Ein GET auf den Endpunkt zum Anzeigen gibt nur Metadaten zurück (den Status und ob eine Passphrase nötig ist). Ein Aufruf wird erst bei einem ausdrücklichen POST zum Anzeigen gezählt. Passphrasen werden clientseitig mit SHA-256 gehasht und auf fünf Versuche pro IP-Adresse, Minute und Geheimnis begrenzt. Jede Antwort zum Anzeigen trägt Cache-Control: no-store. Gelöschte oder abgelaufene Geheimnisse liefern HTTP 410, und der gespeicherte Inhalt ist überschrieben. Der Audit-Verlauf speichert jedes Ereignis mit einer gehashten IP-Adresse unter einem täglich wechselnden Salt, die rohe IP-Adresse wird nie gespeichert. Alle Details stehen auf der Seite zur Sicherheitsarchitektur.

Grenzen dieses Designs

Ehrlich gesagt: Nichts davon schützt ein Geheimnis nach einem legitimen Anzeigen. Der Empfänger kann den Inhalt selbst kopieren, einen Screenshot machen oder ihn weiterleiten. Es hilft nicht, wenn die Passphrase zusammen mit dem Link verschickt wird. Und es kann niemanden, der den Link versehentlich bekommen hat, daran hindern, ihn vor dem eigentlichen Empfänger zu öffnen. Dafür gibt es den Audit-Verlauf: Sie sehen den unerwarteten Aufruf und erneuern die Zugangsdaten.

Weiterlesen

• So funktionieren Einmal-Links für Geheimnisse
• Warum URLs sensible Informationen preisgeben
• Sicherheitsarchitektur von LinkPilot

Quellen

• IETF, RFC 9110: HTTP Semantics, section 9.2.1 Safe Methods.
• Slack API, Unfurling links in messages.
• Microsoft Learn, Safe Links in Microsoft Defender for Office 365.