Kostenloser Link-Sicherheitscheck: Ist dieser Link sicher?

Der erste Schritt ist das Auflösen. Die URL geht an den zustandslosen Expand-Endpunkt von U2L, der eine GET-Anfrage mit deaktivierten Weiterleitungen sendet und jede Antwort protokolliert. Lautet der Status 301, 302, 303, 307 oder 308 und ist ein Location-Header vorhanden, wertet der Endpunkt diesen Header relativ zur aktuellen URL aus (relative Location-Werte sind laut RFC 9110 zulässig) und wiederholt den Vorgang: bis zu 15 Stationen, mit einem Zeitlimit von 5 Sekunden für die erste Anfrage und 3 Sekunden für jede weitere. Eine 3xx-Antwort ohne Location-Header wird auf ein Meta-Refresh- oder Anker-Ziel untersucht. Die angezeigte Liste der Stationen gibt genau diese Kette unverändert wieder: URL, Statuscode und Millisekunden pro Station. JavaScript-Weiterleitungen auf einer Seite mit Status 200 werden nicht ausgeführt, daher wird eine Seite, die per Skript weiterleitet, als Ziel angezeigt.

Der zweite Schritt ist die Reputationsprüfung, und sie läuft nur für die letzte Station. Der Hostname wird zweimal per DNS-over-HTTPS aufgelöst: einmal bei cloudflare-dns.com (dem einfachen Resolver 1.1.1.1) und einmal bei security.cloudflare-dns.com (dem Resolver 1.1.1.2). Für Hostnamen, die in den Malware- und Phishing-Bedrohungsdaten von Cloudflare stehen, liefert der Dienst 1.1.1.2 statt der echten Adresse 0.0.0.0. Das Tool meldet „blockiert“ nur, wenn der einfache Resolver echte A-Records zurückgegeben hat und der Sicherheits-Resolver nichts als 0.0.0.0. Ein Hostname, der sich überhaupt nicht auflösen lässt, wird als „nicht geprüft“ gemeldet, nie als „blockiert“. Parallel dazu wird die vollständige URL an die checkurl-API von PhishTank übermittelt: Eine URL, die in der Datenbank steht und als gültig markiert ist, gilt als Phishing-Seite; eine URL, die eingereicht, aber von den Prüfern abgelehnt wurde, gilt als unauffällig; und jeder HTTP-Fehler sowie jede Zeitüberschreitung (6 Sekunden) wird als „nicht geprüft“ gemeldet.

Im dritten Schritt geht es um das Registrierungsalter. Die registrierbare Domain (example.co.uk, nicht sub.example.co.uk) wird über rdap.org abgefragt, den RDAP-Bootstrap-Dienst nach IETF-Standard, der WHOIS für generische TLDs abgelöst hat. Das Datum des Registrierungsereignisses wird in ein Alter in Tagen umgerechnet. Einige länderspezifische TLDs veröffentlichen keine RDAP-Daten. In diesem Fall zeigt die Alterszeile „nicht verfügbar“, und die altersabhängigen Heuristiken werden einfach nicht ausgelöst. Von keiner dieser Abfragen wird etwas gespeichert; die API reicht die Daten nur durch und setzt einen Cache-Header von fünf Minuten, damit eine wiederholte Prüfung desselben Links die Anbieter nicht mit Anfragen überhäuft.

Der vierte Schritt läuft in Ihrem Browser. Die Ziel-URL wird mit der nativen URL-API geparst, die internationalisierte Hostnamen zudem in Punycode umwandelt. So sind Labels mit xn-- auch dann sichtbar, wenn der ursprüngliche Link Unicode zeigte. Danach bewerten acht Heuristiken Hostname und Pfad: Das Schema ist nicht HTTPS; der Hostname ist eine reine IPv4- oder IPv6-Adresse; der Hostname enthält ein Label mit xn-- oder mischt lateinische mit kyrillischen oder griechischen Buchstaben; ein bekannter Markenbegriff (paypal, microsoft, netflix und andere) steht in einem Hostnamen, dessen registrierbare Domain nicht dieser Marke gehört; ein irreführendes Wort wie login, verify, secure oder wallet steht im Hostnamen einer Domain, die vor weniger als 90 Tagen registriert wurde; der Hostname hat mehr als vier Labels; die URL enthält vor einem @ einen Nutzernamen; oder die URL ist ungewöhnlich lang und enthält Daten, die nach Base64 aussehen. Die abschließende Bewertung kombiniert alle vier Schritte: „Schädlich“, wenn eine der beiden Reputationsquellen das Ziel als auffällig gemeldet hat, „Vorsicht“, wenn zwei oder mehr Heuristiken ausgelöst wurden oder ein irreführendes Schlüsselwort auf einer Domain steht, die jünger als 30 Tage ist, andernfalls „Keine bekannten Bedrohungen“.