Sprawdzanie homograficzne IDN

Nazwy były wyłącznie ASCII przez pierwsze dwie dekady DNS, dlatego wszystko, co je dotyczy, mierzy się w bajtach i literach: etykiety z liter, cyfr i myślników, najwyżej 63 bajty każda, najwyżej 255 bajtów w sumie. Międzynarodowa nazwa domeny (IDN) to to, co dzieje się, gdy zasady otwiera się na resztę Unicode, a punycode (RFC 3492) to reguła zapisu, która utrzymuje stary mechanizm w ruchu: etykieta zawierająca cokolwiek poza ASCII zapisywana jest jako etykieta xn--, ciąg ASCII niosący te same znaki w sprowadzonej formie. 中文.com podróżuje jako xn--fiq228c.com, a obie formy nazywają ten sam host.

Ważne jest tutaj to, czego punycode nie robi. Konwertuje pisownię i nic poza tym. Nie ma zdania o tym, czy аpple.com powinna mieć wolno stać obok apple.com, i nie można by o to zapytać, bo to pytanie dotyczy oczu i czcionek, a nie bajtów. Rejestr decyduje, jakie znaki sprzeda, przeglądarka decyduje, jak wyświetli nazwę, którą uzna za bezpieczną, a czytelnik decyduje, czy kliknąć. Ta strona odpowiada na pytanie pod wszystkimi trzema: z jakich znaków naprawdę składa się ta nazwa i co przez to oznacza?

Każdy wiersz poniżej jest uruchamiany przez tę stronę przy ładowaniu i ponownie przez przycisk Autotest, a strona musi raportować dokładnie to, co wiersz deklaruje — te same ustalenia, ten sam poziom, ta sama forma DNS, ta sama liczba bajtów, ani więcej, ani mniej. Dzięki temu czysty wynik ma wartość: ścieżka kodu, która przepuszcza zwykłą nazwę, jest tą samą, która wychwytuje poniższe sztuczki.

1. Wyjmij nazwę z tego, co wklejono. Goła nazwa jest używana tak, jak stoi; z adresu URL wyjmowany jest host, a schemat, port, ścieżka i zapytanie są odrzucane, a strona mówi, które z tych zrobiła, zamiast po cichu analizować ukośnik jak część nazwy.
2. Oczyść ją tak, jak zrobiłby to klient. Znaki sterujące, znaki zerowej szerokości i znacznik kolejności bajtów są usuwane, pełnoszerokościowa lub ideograficzna kropka liczy się jak kropka, a końcowa kropka to korzeń, a nie błąd. Każdy znak usunięty lub zinterpretowany inaczej jest zgłaszany, bo cicho usunięta spacja zerowej szerokości to dokładnie to, o czym trzeba wiedzieć.
3. Podziel na etykiety i zmierz każdą. Etykieta nie może być pusta, nie może zaczynać ani kończyć się myślnikiem ani mieć dwóch myślników na pozycjach trzeciej i czwartej, chyba że jest etykietą xn--. Każda etykieta jest mierzona w bajtach UTF-8 względem sufitu 63 bajtów, a cała nazwa względem 255.
4. Zdekoduj każdą etykietę xn-- z powrotem do znaków. Zdekodowaną etykietę koduje się ponownie i porównuje z tym, co wpisano. Etykieta, która nie przechodzi tej podróży w obie strony, nie jest tym, za co się podaje, a taka, która dekoduje się do znaku sterującego lub do niczego, jest zgłaszana jako taka, zamiast po cichu usunięta.
5. Zapytaj, czym jest każdy znak. Jego punkt kodowy, bajty UTF-8, pismo, do którego należy, czy znajduje się w grupie znaków rysowanych tak samo, i jakie są pozostali członkowie tej grupy. Tu cyrylicka a przestaje być „literą” i staje się „literą o kształcie łacińskiego”.
6. Sprowadź nazwę do kształtu, który naśladuje. Każdy podobny znak zostaje zastąpiony znakiem, który przypomina, co zamienia аpple.com w apple.com. To sprowadzone odczytanie jest najbardziej użyteczną linią na stronie, bo apple.com to coś, na czym można działać, a „cyrylicka a” nie.
7. Zbierz ustalenia i zgłoś najgorsze. Każde ustalenie jest zgłaszane raz, wraz z etykietami, w których występuje. Nazwa, która jest tylko nietypowa, daje uwagi, a nie ustalenia: mieszanie znaków Han i kany albo kończenie kropką korzenia to zwyczajny zapis, a nie powód do obaw.

brak nic tu nie było warte wzmianki — niski ta sama nazwa zapisana w drugi sposób — średni znak, którego DNS nie przeniesie, albo taki, który sprowadza się do zwykłej litery — wysoki nazwa zbudowana tak, by czytać ją jako inną nazwę, albo taka, której nie da się wysłać w ogóle.

Poziom to najgorsze, co mogą znaczyć ustalenia, a nie prawdopodobieństwo ani ocena strony. Zupełnie uczciwa nazwa może mieć poziom średni, bo zawiera jeden znak spoza alfabetu nazw hostów, a nieprzyjazna może mieć poziom wysoki z niczym bardziej wyrafinowanym niż cyrylicka litera. Lista pod poziomem mówi, dlaczego, po jednej linii na ustalenie, i to właśnie ta lista jest warta przeczytania.

Tabela poniżej jest zbudowana z tej samej listy, z której strona raportuje, więc wiersz tutaj i ustalenie w wyniku nie mogą się rozjechać. Sprawdzenie, które niczego nie znalazło, jest wymienione jako nie: sens tabeli polega na tym, by było widać, że pytanie zostało zadane i odpowiedziano na nie, zamiast zastanawiać się, czy w ogóle je zadano.

Ta sama lista napędza uwagi, które nie mają żadnego poziomu: etykieta bez kropki, końcowa kropka korzenia, domena najwyższego poziomu niebędąca ASCII, separator inny niż kropka, nazwa pisana wielkimi literami, znaki usunięte podczas czyszczenia i adres URL zredukowany do hosta.

Nazwa to lista etykiet i każda z nich jest liczona w bajtach, nie w znakach. Właśnie to rozróżnienie jest powodem istnienia punycode: 中文 to dwa znaki i sześć bajtów, a jego forma xn-- ma piętnaście znaków, więc zakodowana forma to ta, która musi się zmieścić. Strona stosuje oba limity i mówi, który z nich został przekroczony.

Być może zauważono, że nazwa zapisana po chińsku lub cyrylicą czasem pojawia się w pasku adresu jako bełkot xn-- zamiast znaków, których się oczekuje. To przeglądarka odmawia wyświetlenia ładnej formy, a nie strona, która nie zarejestrowała nazwy. Przeglądarka stosuje własną regułę do nazwy, której wcześniej nie widziała, a reguła istnieje z tego samego powodu co cała ta strona: wyświetlanie аpple.com jako аpple.com to dokładnie to, czego chce atakujący, więc nieznana nazwa z mieszanym pismem jest pokazywana w zakodowanej formie, dopóki nie zostanie zobaczona dostatecznie często, by jej zaufać.

Punycode to RFC 3492, a autotest tej strony uruchamia jako pierwsze sprawdzenie jedenaście przykładowych etykiet podanych w tym dokumencie, więc koder jest sprawdzany względem przykładów ze standardu, a nie względem samego siebie. Reguły przetwarzania, przez które przechodzi IDN, to RFC 5891 z tabelami znaków RFC 5892, a warstwa zgodności, którą faktycznie stosują przeglądarki, to UTS #46 z flagą nietranzycyjną; ta strona mówi, co te reguły robią, zamiast udawać, że je wdraża, a sprowadzanie, które stosuje — NFC, potem małe litery, potem RFC 3492 — to ta sama krótka sekwencja, którą klient wykonuje przed wysłaniem nazwy. Grupy kształtów, zakresy pism i tabele niewidocznych znaków w tej rodzinie stron napisano ręcznie dla tej rodziny: standardy są wymienione po nazwie, byś mógł je przeczytać samodzielnie, a z ich tekstu nic tu nie jest powielane.

Czy nazwa z mieszanym pismem jest zawsze atakiem?

Nie, i traktowanie tego jako takiego byłoby błędem, który ma znaczenie. Japoński zapisuje znaki Han i kanę w tym samym słowie, a koreański zapisuje znaki Han wewnątrz znaków hangul. Bez zwykłego wyjaśnienia jest mieszanie łacińskiego z cyrylicą lub greką w jednej etykiecie, bo te pisma nie są używane razem w żadnym języku, a strona wyznacza tę granicę zamiast oznaczać każdą mieszankę. Dlatego wiersze japońskie i koreańskie w tabeli przypadków powyżej wychodzą czyste.

Dlaczego więc moja nazwa wychodzi jako średnia?

Najprawdopodobniej zawiera jeden znak, którego alfabet nazw hostów nie obejmuje — podkreślnik, spację, akcent zapisany jako znak zgodności — a to jest średnie, bo nazwy nie da się wysłać w obecnej postaci. Średni oznacza „warto się przyjrzeć”, a nie „to podróbka”. Ustalenie pod poziomem nazywa dokładny znak i jego pozycję.

Czy strona mówi mi, czy nazwa jest niebezpieczna, zarejestrowana albo osiągalna?

Nie, we wszystkich trzech punktach. Nigdy nie dotyka sieci i niczego nie rozwiązuje, więc nie może wiedzieć, czy nazwa istnieje ani kto jest jej właścicielem, i celowo nic nie mówi o tym, co robi strona. Odpowiada na węższe pytanie, które można sprawdzić samodzielnie: z jakich znaków składa się ta nazwa i co wyjdzie, gdy podobne znaki sprowadzi się do liter, które naśladują?

Moja nazwa jest po chińsku i strona mówi, że domena najwyższego poziomu nie jest ASCII. Czy coś jest nie tak?

Nic złego. Chińska domena najwyższego poziomu podróżuje jako własna etykieta xn--, więc ostatnia etykieta nazwy jest zapisana w formie zakodowanej, a strona to odnotowuje. Uwagi nie mają poziomu, bo opisują fakt, a nie problem.

Dlaczego wiersz „czyta się jako” czasem pokazuje tę samą nazwę, którą wpisano?

Strona pokazuje sprowadzone odczytanie tylko wtedy, gdy sprowadzanie faktycznie coś zmienia. Jeśli każdy znak w nazwie już ma kształt, który naśladuje, sprowadzone odczytanie i nazwa to ten sam ciąg i nie ma tu nic, co można by zgłosić.

Czym jest etykieta A, a czym etykieta U?

Etykieta A to zapis ASCII, który podróżuje: xn--fiq228c. Etykieta U to ta sama etykieta zapisana w piśmie, do którego należy: 中文. To dwa zapisy jednej etykiety, a strona pokazuje oba dla każdej zdekodowanej etykiety, żebyś widział, co ukrywa zakodowana etykieta.