IDN-Homograph-Prüfer

Zwei Namen können mit verschiedenen Zeichen geschrieben werden und dennoch gleich gelesen werden. apple.com und аpple.com — wobei der erste Buchstabe das kyrillische kleine a ist — sind für das Netzwerk verschiedene Namen und für den Leser dasselbe Wort. Diese Seite zerlegt einen Namen und sagt, welcher der beiden Fälle vorliegt: Sie teilt den Namen in Labels, dekodiert jedes xn---Label zurück in die enthaltenen Zeichen, zählt die Bytes gegen die DNS-Grenzen, benennt jedes Look-alike-Zeichen zusammen mit der Schrift, die es entlehnt, und faltet den gesamten Namen auf die Form, die er imitiert. Sie berichtet, was sie findet und was nicht, im gleichen Detailgrad, sodass ein sauberes Ergebnis bedeutet, dass die Prüfungen gelaufen und bestanden sind, und nicht, dass nichts angesehen wurde.
Die gesamte Verarbeitung findet lokal in Ihrem Browser statt — der eingegebene Name wird nie hochgeladen und nie aufgelöst.

Neu hier? IDN-Homographen einfach erklärt — was Punycode tut und was nicht, warum ein Browser manchmal xn-- zeigt und warum diese Seite eine Sammlung von Prüfungen statt eines Urteils ist.
Eingabe lesen als: Namen zuerst auf NFC falten
LIEST SICH ALS —
DNS-FORM (was ein Resolver erhält) —
GRÖSSE —
Noch nichts geprüft. Geben Sie oben einen Namen ein oder fügen Sie ihn ein — jeweils einen Namen — oder drücken Sie Beispiel laden. Die Seite liest einen nackten Namen, einen aus einer URL herausgelösten Namen oder eine vollständige URL und zeigt Ihnen an, was sie erkannt hat. Jede ausgeführte Prüfung wird unter dem Ergebnis aufgelistet, auch diejenigen, die nichts gefunden haben.
Was ist ein IDN-Homograph?
Ein Homograph ist ein Wort, das auf eine Weise geschrieben und auf eine andere gelesen wird. Bei einem Domainnamen kostet der Trick meist ein einziges Zeichen: apple.com besteht aus sieben lateinischen Buchstaben, während аpple.com mit U+0430 beginnt, dem kyrillischen kleinen a, das in jeder Schrift gleich aussieht. Für das Netzwerk sind das zwei verschiedene Namen. Für Ihr Auge ist es dasselbe Wort, und nur einer der beiden gehört Apple.

Namen waren in den ersten beiden Jahrzehnten des DNS nur ASCII, deshalb wird alles an ihnen in Bytes und Buchstaben gemessen: Labels aus Buchstaben, Ziffern und Bindestrichen, höchstens 63 Byte je Label, höchstens 255 Byte insgesamt. Ein internationalisierter Domainname (IDN) entsteht, wenn die Regeln für den übrigen Unicode geöffnet werden, und Punycode (RFC 3492) ist die Schreibregel, die die alte Technik weiter funktionieren lässt: Ein Label, das irgendetwas außerhalb von ASCII enthält, wird als xn---Label geschrieben, also als ASCII-Zeichenkette, die dieselben Zeichen in gefalteter Form trägt. 中文.com wird als xn--fiq228c.com übertragen, und beide Schreibweisen bezeichnen denselben Host.

Entscheidend ist hier, was Punycode nicht tut. Es wandelt die Schreibweise um und sonst nichts. Es hat keine Meinung darüber, ob аpple.com neben apple.com existieren dürfen sollte, und man könnte es nicht fragen, denn diese Frage betrifft Augen und Schriften, nicht Bytes. Das Register entscheidet, welche Zeichen es vergibt, der Browser entscheidet, wie er einen Namen anzeigt, den er für sicher hält, und der Leser entscheidet, ob er klickt. Diese Seite beantwortet die Frage darunter: Aus welchen Zeichen besteht dieser Name tatsächlich, und was macht ihn dadurch zu dem, was er vorgibt zu sein?

Die Fälle, gegen die diese Seite geprüft wird

Jede Zeile unten wird von dieser Seite beim Laden ausgeführt und erneut durch die Schaltfläche Selbsttest. Die Seite muss genau melden, was die Zeile sagt — dieselben Befunde, dieselbe Stufe, dieselbe DNS-Form, dieselbe Bytezahl, nicht mehr und nicht weniger. Erst dadurch ist ein sauberes Ergebnis hier etwas wert: Der Codepfad, der einen gewöhnlichen Namen durchlässt, ist derselbe, der die unten stehenden Tricks abfängt.

Worum es im Fall geht Stufe Name, wie er ankommt Was die Seite melden muss

Wie diese Seite entscheidet
  1. Entnehmen Sie den Namen dem, was Sie eingefügt haben. Ein nackter Name wird unverändert verwendet; bei einer URL wird der Host herausgelöst, und Schema, Port, Pfad und Abfrage werden verworfen. Die Seite sagt, welches der beiden sie getan hat, statt stillschweigend einen Schrägstrich zu analysieren, als wäre er Teil eines Namens.
  2. Bereinigen Sie ihn so, wie es ein Client täte. Steuerzeichen, Zeichen ohne Breite und die Byte-Order-Mark werden entfernt; ein vollbreiter oder ideographischer Punkt zählt als Trennzeichen, und ein abschließender Punkt gilt als Wurzel und nicht als Fehler. Jedes auf diese Weise entfernte oder umgedeutete Zeichen wird gemeldet, denn ein stillschweigend entferntes Leerzeichen ohne Breite ist genau das, worüber Sie informiert werden müssen.
  3. Teilen Sie ihn in Labels und messen Sie jedes einzelne. Ein Label darf nicht leer sein, nicht mit einem Bindestrich beginnen oder enden und an den Positionen drei und vier nicht zwei Bindestriche tragen, es sei denn, es ist ein xn---Label. Jedes Label wird in UTF-8-Bytes gegen die Obergrenze von 63 Byte gemessen, der gesamte Name gegen 255.
  4. Dekodieren Sie jedes xn---Label zurück in seine Zeichen. Das dekodierte Label wird anschließend ein zweites Mal kodiert und mit der Eingabe verglichen. Ein Label, das diesen Rücklauf nicht übersteht, ist nicht das Label, das es vorgibt zu sein; eines, das zu einem Steuerzeichen oder zu nichts dekodiert, wird als solches gemeldet, statt stillschweigend verworfen zu werden.
  5. Fragen Sie, was jedes Zeichen ist. Seinen Codepunkt, seine UTF-8-Bytes, die Schrift, zu der es gehört, ob es in einer Gruppe gleich aussehender Zeichen liegt und welche anderen Mitglieder diese Gruppe hat. Hier hört ein kyrillisches a auf, „ein Buchstabe“ zu sein, und wird zu „einem Buchstaben, der wie ein lateinischer geformt ist“.
  6. Falten Sie den Namen auf die Form, die er imitiert. Jedes Look-alike-Zeichen wird durch das Zeichen ersetzt, dem es ähnelt; so wird аpple.com zu apple.com. Diese gefaltete Lesart ist die nützlichste Zeile der Seite, denn apple.com lässt sich verwenden, „ein kyrillisches a“ dagegen nicht.
  7. Sammeln Sie die Befunde und melden Sie den schwerwiegendsten. Jeder Befund wird einmal gemeldet, mit den Labels, in denen er vorkommt. Ein Name, der nur ungewöhnlich aussieht, erzeugt Hinweise statt Befunde: Die Mischung von Han und Kana oder ein abschließender Wurzelpunkt sind gewöhnliche Schreibweisen und kein Grund zur Sorge.

Die Stufen und was sie behaupten

keine hier war nichts erwähnenswert — niedrig derselbe Name, zweimal anders geschrieben — mittel ein Zeichen, das DNS nicht überträgt, oder eines, das auf einen einfachen Buchstaben faltet — hoch ein Name, der so gebaut ist, dass er als anderer Name gelesen wird, oder einer, der gar nicht gesendet werden kann.

Eine Stufe ist das Schlimmste, was die Befunde bedeuten könnten — keine Wahrscheinlichkeit und kein Urteil über die Website. Ein völlig ehrlicher Name kann „mittel“ sein, weil er ein Zeichen außerhalb des Host-Namen-Alphabets enthält, und ein feindseliger Name kann „hoch“ sein, ohne mehr als einen kyrillischen Buchstaben darin. Die Liste unter der Stufe sagt, warum, eine Zeile pro Befund; diese Liste ist der Teil, der sich zu lesen lohnt.

Die Prüfungen, eine nach der anderen

Die Tabelle unten wird aus derselben Liste aufgebaut, aus der die Seite berichtet, sodass eine Zeile hier und ein Befund in einem Ergebnis nicht auseinanderlaufen können. Eine Prüfung, die nichts gefunden hat, wird als nein aufgeführt: Der Sinn der Tabelle ist, dass Sie sehen, dass die Frage gestellt und beantwortet wurde, statt sich zu fragen, ob sie überhaupt gestellt wurde.

Prüfung Schlimmstes, was es bedeuten kann Wonach gesucht wird

Dieselbe Liste treibt die Hinweise an, die gar keine Stufe tragen: ein Label ohne Punkt, ein abschließender Wurzelpunkt, eine Top-Level-Domain, die nicht ASCII ist, ein anderer Trenner als ein Punkt, ein Name in Großbuchstaben, beim Bereinigen entfernte Zeichen und eine URL, die auf ihren Host reduziert wurde.

Die Grenzen, die DNS durchsetzt

Ein Name ist eine Liste von Labels, und jedes davon wird in Bytes gezählt, nicht in Zeichen. Diese Unterscheidung ist der ganze Grund, warum es Punycode gibt: 中文 sind zwei Zeichen und sechs Bytes, und seine xn---Form hat fünfzehn Zeichen — die kodierte Schreibweise muss also passen. Die Seite wendet beide Obergrenzen an und meldet, welche davon Sie erreicht haben.

Grenze Wert Was an der Grenze passiert
Warum ein Browser manchmal xn-- anzeigt

Sie haben vielleicht bemerkt, dass ein Name auf Chinesisch oder Kyrillisch in Ihrer Adressleiste manchmal als xn---Kauderwelsch statt als erwartete Zeichen erscheint. Das ist der Browser, der die schöne Form nicht anzeigt, nicht die Website, die sich nicht registriert hat. Ein Browser wendet eine eigene Regel auf einen Namen an, den er noch nie gesehen hat, und diese Regel gibt es aus genau dem Grund, aus dem diese ganze Seite existiert: аpple.com als аpple.com anzuzeigen ist genau das, was ein Angreifer will. Ein ungewohnter Name mit gemischter Schrift wird deshalb in seiner kodierten Schreibweise angezeigt, bis er oft genug gesehen wurde, um als vertrauenswürdig zu gelten.

Wo der Name erscheint Was angezeigt wird Warum

Was diese Seite nicht tut
Dies ist eine Sammlung von Prüfungen, kein Urteil und keine Sperrliste. Sie meldet, woraus ein Name besteht; sie weiß nicht, was eine Website tut. Ein Name kann alle Prüfungen hier bestehen und dennoch eine Phishing-Seite sein, und ein Name kann als Mischschrift-Name markiert werden und dennoch eine ganz gewöhnliche Website eines Menschen sein, der seine eigene Sprache schreibt. Die Formgruppen sind eine von Hand gepflegte Auswahl aus den Confusables in UTS #39; ein Zeichenpaar, das diese Seite nicht kennt, wird also nicht gemeldet. Und hier wird nichts aufgelöst, heruntergeladen oder nachgeschlagen: Der eingegebene Name verlässt den Browser nie, was auch bedeutet, dass die Seite nicht wissen kann, ob ein Name existiert.
Woher die Regeln stammen

Punycode ist RFC 3492, und der Selbsttest auf dieser Seite führt als erste Prüfung die elf in diesem Dokument abgedruckten Beispiel-Labels aus. Der Kodierer hier wird also an den Beispielen des Standards gemessen und nicht an sich selbst. Die Verarbeitungsregeln, die ein IDN durchläuft, sind RFC 5891 mit den Zeichentabellen aus RFC 5892; die Kompatibilitätsschicht, die Browser tatsächlich anwenden, ist UTS #46 mit dem nicht-übergangsweisen Flag. Diese Seite sagt Ihnen, was diese Regeln bewirken, statt so zu tun, als würde sie sie umsetzen; und die Faltung, die sie tatsächlich anwendet — NFC, dann Kleinschreibung, dann RFC 3492 — ist dieselbe kurze Folge, die ein Client ausführt, bevor ein Name gesendet wird. Die Formgruppen, die Schriftbereiche und die Tabellen unsichtbarer Zeichen in dieser Seitenfamilie wurden eigens für sie von Hand erstellt; die Standards werden genannt, damit Sie sie selbst lesen können, und Text aus ihnen wird hier nicht wiedergegeben.

Fragen

Ist ein Name mit gemischter Schrift immer ein Angriff?

Nein, und es so zu behandeln, wäre in einer Weise falsch, die wichtig ist. Japanisch schreibt Han-Zeichen und Kana im selben Wort, und Koreanisch schreibt Han-Zeichen innerhalb von Hangul. Was keine gewöhnliche Erklärung hat, ist Lateinisch gemischt mit Kyrillisch oder Griechisch in einem Label, denn diese Schriften werden in keiner Sprache zusammen verwendet. Die Seite zieht diese Grenze, statt jede Mischung zu markieren. Deshalb kommen die japanischen und koreanischen Zeilen in der Fallliste oben sauber zurück.

Warum zeigt dann mein eigener Name „mittel“?

Höchstwahrscheinlich, weil er ein Zeichen enthält, das im Host-Namen-Alphabet nicht vorkommt — ein Unterstrich, ein Leerzeichen, ein als Kompatibilitätszeichen geschriebener Akzent — und das ist „mittel“, weil der Name so, wie er ist, nicht gesendet werden kann. Mittel heißt „das sollte man sich ansehen“, nicht „das ist eine Fälschung“. Der Befund unter der Stufe nennt das genaue Zeichen und seine Position.

Sagt mir die Seite, ob ein Name gefährlich, registriert oder erreichbar ist?

Nein, bei allen dreien. Die Seite berührt das Netzwerk nie und löst nichts auf; sie kann also nicht wissen, ob ein Name existiert oder wem er gehört, und sie sagt bewusst nichts darüber, was eine Website tut. Sie beantwortet eine engere Frage, die Sie selbst prüfen können: Aus welchen Zeichen besteht dieser Name, und was ergibt er, wenn ich die Look-alikes auf die Buchstaben falte, die sie imitieren?

Mein Name steht auf Chinesisch, und die Seite sagt, die Top-Level-Domain sei nicht ASCII. Stimmt da etwas nicht?

Es ist nichts falsch. Eine chinesische Top-Level-Domain wird als eigenes xn---Label übertragen; das letzte Label des Namens steht daher in kodierter Form, und die Seite vermerkt das. Hinweise tragen keine Stufe, weil sie einen Sachverhalt beschreiben und kein Problem.

Warum zeigt die Zeile „liest sich als“ manchmal denselben Namen, den ich eingegeben habe?

Weil die Seite eine gefaltete Lesart nur dann zeigt, wenn das Falten tatsächlich etwas ändert. Wenn jedes Zeichen im Namen bereits die Form hat, die es imitiert, sind die gefaltete Lesart und der Name dieselbe Zeichenkette, und es gibt nichts, was sie Ihnen mitteilen könnte.

Was sind ein A-Label und ein U-Label?

Ein A-Label ist die ASCII-Schreibweise, die übertragen wird: xn--fiq228c. Ein U-Label ist dasselbe Label in der Schrift geschrieben, zu der es gehört: 中文. Es sind zwei Schreibweisen desselben Labels, und die Seite zeigt für jedes dekodierte Label beide, damit Sie sehen, was ein kodiertes Label verbirgt.