Obrony Chromium przed spoofingiem IDN nie wykrywają przekonujących domen sobowtórów

Mechanizmy Chromium chroniące przed spoofingiem IDN nie wykryły 20 zarejestrowanych domen sobowtórów, mimo wieloletnich zabezpieczeń zaprojektowanych do ujawniania zwodniczych adresów Unicode. Jedna z domen typu proof of concept do złudzenia przypominała apple.com, wyświetlając się jako czytelny Unicode, a nie rzucający się w oczy format Punycode rozpoczynający się od xn--.

Odkrycie nie oznacza, że atakujący zarejestrowali domenę Apple ani naruszyli jego infrastrukturę. Badacze z Have I Been Squatted, czyli HIBS, zarejestrowali inną domenę, której znaki cyrylicy przypominają łacińskie litery w słowie „apple”. Ich testy pokazują, jak starannie dobrane znaki mogą przejść zarówno reguły wyświetlania Chromium, jak i odrębne mechanizmy ochrony podczas nawigacji.

Wynik ten ponownie ożywia konflikt, z którym przeglądarki mierzą się od czasu upowszechnienia umiędzynarodowionych nazw domen. Internet potrzebuje adresów zapisanych w językach, którymi ludzie faktycznie się posługują. Ta sama różnorodność znaków daje jednak atakującym więcej sposobów na podszywanie się pod zaufane marki, dostawców tożsamości i usługi płatnicze.

Chromium stosuje już jeden z najbardziej rozbudowanych systemów ochrony w branży. Sprawdza systemy pisma, podejrzane kombinacje znaków, znane domeny i historię przeglądania. Nowe przykłady nie przekreślają tych zabezpieczeń. Pokazują, jak kilka znaków może znaleźć się pomiędzy warstwami, z których każda podejmuje nieco inne decyzje.

Badacze znaleźli nowy przypadek brzegowy spoofingu IDN w Chromium

Istotna zmiana nie polega na powrocie zapomnianego ataku, lecz na dowodzie, że obecne kontrole Chromium nadal dopuszczają przekonujące nowe warianty.

Badacze HIBS, Ian Muscat i Leanne Briffa, opublikowali swoją analizę 3 października 2026 roku. Sprawdzili, czy umiędzynarodowiona domena może przypominać znany adres zapisany alfabetem łacińskim, a jednocześnie wyświetlać się jako Unicode w przeglądarkach opartych na Chromium.

Umiędzynarodowiona nazwa domeny, czyli IDN, zawiera znaki wykraczające poza podstawowy alfabet angielski. Aplikacje przed wysłaniem zapytania DNS tłumaczą te znaki na zgodną z ASCII reprezentację zwaną Punycode. Domena rozpoczynająca się od xn-- nie jest więc automatycznie niebezpieczna. To zakodowana forma niezbędna dla obecnego systemu DNS.

Przeglądarki często przekształcają tę zakodowaną formę z powrotem w czytelny Unicode na potrzeby wyświetlania. Obsługuje to prawidłowe adresy w języku arabskim, cyrylicy, chińskim i wielu innych systemach pisma. Problem bezpieczeństwa pojawia się wtedy, gdy różne znaki mają niemal identyczne kształty.

Badacze skupili się na аррӏө.com, domenie, która w powszechnie używanych krojach pisma może przypominać apple.com. Jej litery są cyrylickie, w tym znaki przypominające łacińskie „a”, dwa znaki „p” oraz „l”. Ostatni znak cyrylicki, ө, przy rozmiarze wyświetlanym na pasku adresu przypomina zaokrąglone „e”.

Adres nie jest apple.com. Jego zakodowana forma to xn--80a6aa68c8d.com, a DNS traktuje go jako odrębną nazwę. Mimo to czytelna wersja może sprawiać wizualne wrażenie, że użytkownik trafił do domeny Apple.

HIBS zarejestrowało tę domenę oraz 19 dodatkowych sobowtórów jako proof of concept. Lista naśladowała nazwy związane z OpenAI, Skype, SharePoint, SpaceX, Shell, Xerox, Kaspersky, Okta, Nike i innymi rozpoznawalnymi organizacjami.

Oryginalne badanie IDN podaje, że Chrome 154 wyświetlał sobowtóra Apple w Unicode z prawidłowym certyfikatem. Domena przeszła również sprawdzane przez badaczy kontrole nawigacji bez wyświetlenia ostrzeżenia o domenie sobowtórze.

Prawidłowy certyfikat nie dowodzi, że domena należy do marki, którą przypomina. Potwierdza, że przeglądarka ustanowiła szyfrowane połączenie z domeną wskazaną w tym certyfikacie. Atakujący mogą uzyskać certyfikaty dla domen, które zgodnie z prawem kontrolują, także tych zwodniczych.

Przykłady były kontrolowanymi rejestracjami, a nie dowodem kampanii wymierzonej w klientów każdej z wymienionych firm. To rozróżnienie jest istotne, ponieważ technicznie możliwe podszycie się nie oznacza automatycznie aktywnej operacji phishingowej.

Mimo to właśnie techniczna wykonalność jest tu kluczowym ustaleniem. Zwodnicza domena może obsługiwać prawdziwą stronę internetową, HTTPS, e-mail, przekierowania i inne zwykłe usługi internetowe. Atakujący mogliby następnie połączyć wizualne podobieństwo z reklamą w wyszukiwarce, fałszywym e-mailem, kodem QR, skróconym linkiem lub skopiowaną stroną logowania.

Badanie pojawiło się w szerszym omówieniu 18 października, gdy śledztwo dotyczące typosquattingu szczegółowo opisało, w jaki sposób cyrylickie podstawienia przetrwały reguły Chromium. Ten moment ponownie zwraca uwagę na zabezpieczenia, których wielu użytkowników nigdy nie widzi, o ile przeglądarka nie wykryje czegoś podejrzanego.

Tworzy to centralne napięcie artykułu. Chromium musi odróżniać zwodnicze wizualne podstawienia od prawidłowych słów używanych przez miliony ludzi. Reguła wystarczająco szeroka, by wychwycić każde podobieństwo, utrudniałaby też odczytywanie i zaufanie do zwykłych międzynarodowych adresów.

Jak sobowtóry Unicode w Chromium przechodzą przez wiele kontroli

Sobowtór Apple przechodzi kontrole, ponieważ żadna pojedyncza reguła Chromium nie ocenia pełnego wizualnego wrażenia docierającego do użytkownika.

Chromium nie pyta po prostu, czy domena zawiera Unicode. Przetwarza IDN-y za pomocą kilku testów, zanim zdecyduje, czy pokazać czytelne znaki, czy bazową etykietę Punycode.

Pierwsza istotna warstwa korzysta z mechanizmu sprawdzającego spoofing w International Components for Unicode. Chromium konfiguruje go na poziomie „Highly Restrictive”, który ogranicza podejrzane kombinacje systemów pisma.

Mieszana etykieta zawierająca jeden znak cyrylicki pośród liter łacińskich zwykle nie przejdzie tego testu. Zastąpienie na przykład tylko pierwszego „a” w apple.com powoduje, że Chromium wyświetla xn--pple-43d.com. Zakodowany adres znacznie rzadziej zostanie pomylony z oryginałem.

Nowy sobowtór Apple unika tego rezultatu, ponieważ każda litera przed .com jest cyrylicka. To etykieta zapisana jednym systemem pisma, a nie oczywista mieszanina znaków łacińskich i cyrylickich.

Chromium utrzymuje też zestaw dozwolonych znaków. Usuwa różne bloki Unicode i pojedyncze punkty kodowe związane z ryzykownym lub mylącym sposobem wyświetlania. Znaki w аррӏө.com pozostają dopuszczalne, częściowo dlatego, że są prawidłowymi literami używanymi w rzeczywistych językach.

Następnie stosowanych jest kilka ukierunkowanych kontroli. Chromium ogranicza użycie islandzkich znaków thorn i eth poza odpowiednimi domenami krajowymi. Ogranicza azerbejdżański schwa i stosuje szczególną regułę wobec katalońskiej środkowej kropki. Żadne z tych ograniczeń nie dotyczy cyrylickiej sekwencji zastosowanej w proof of concept.

Najbardziej istotną ochroną jest kontrola znaków mylących w obrębie całego systemu pisma w Chromium. Wykrywa ona etykiety zapisane wyłącznie znakami cyrylickimi, które wszystkie przypominają litery łacińskie.

Chromium wprowadziło tę ochronę po szeroko komentowanej demonstracji z 2017 roku. Badacz bezpieczeństwa Xudong Zheng zarejestrował całkowicie cyrylicką wersję apple.com, którą przeglądarki wyświetlały jako bliską wizualną kopię prawdziwego adresu.

Chromium zareagowało w Chrome 58. Jego kontrola całego systemu pisma identyfikuje zestaw 29 znaków cyrylickich przypominających znaki łacińskie. Gdy każda litera etykiety zapisywanej jednym systemem pisma należy do tego zestawu, Chromium może wyświetlić domenę jako Punycode.

Ta ochrona wykrywa wersję z 2017 roku. Nie wykrywa nowego wariantu, ponieważ ө nie należy do 29 wymienionych znaków. Jeden znak spoza zestawu powoduje, że warunek dla całego systemu pisma przestaje obowiązywać, choć kompletna etykieta nadal przypomina „apple”.

Przeglądarka musi dopuścić ten znak w pewnych sytuacjach, ponieważ nie jest on wymyślonym symbolem. Cyrylickie ө jest używane w języku kazachskim, mongolskim, tatarskim i innych językach. Blokowanie go wszędzie narzucałoby koszt użyteczności prawowitym użytkownikom tych języków.

Następnie Chromium stosuje porównanie szkieletów dla chronionych domen. Szkielet redukuje wizualnie powiązane znaki do znormalizowanej reprezentacji, którą oprogramowanie może porównać ze znanymi nazwami.

Proces ten jest użyteczny, lecz nie może doskonale odtworzyć ludzkiego widzenia. W tym przypadku kreska w ө pozostaje po normalizacji. Powstały szkielet kończy się formą opartą na „o” oraz znaku łączącym, zamiast oczekiwanego łacińskiego „e”.

Ta różnica zapobiega dokładnemu dopasowaniu do szkieletu apple.com. Jeden drobny znak wystarcza, by zmienić wynik obliczeniowy, nawet jeśli staje się on trudny do zauważenia w kompaktowym interfejsie przeglądarki.

Przykłady zapisane alfabetem łacińskim ujawniają pokrewną słabość. Badacze użyli znaków takich jak ƙ, łacińskiej litery z haczykiem, aby naśladować „k” w nazwach obejmujących Okta i Nike. Chromium nie może stosować szerokiego ostrzeżenia dla całego systemu pisma wobec znaków łacińskich, ponieważ domeny z akcentowanymi literami łacińskimi są powszechne i prawidłowe.

Zamiast tego Chromium zapewnia silniejszą ochronę opartą na szkieletach dla dołączonej listy znanych domen. HIBS znalazło na tej liście 8462 nazwy, w tym 836 w grupie o wyższym priorytecie. Jednak znak zachowujący dodatkowy element może uniemożliwić dokładne dopasowanie szkieletu.

Wytyczne Chromium dotyczące wyświetlania uznają leżącą u podstaw równowagę. Chrome pokazuje Punycode, gdy jego reguły wyświetlania IDN wykryją ryzyko homografu, lecz nie traktuje każdego adresu spoza ASCII jako wrogiego.

Ta równowaga sprawia, że spoofing IDN w Chromium jest problemem klasyfikacji, a nie prostym problemem czarnej listy. Każda nowa reguła musi wychwytywać złośliwe podobieństwo bez zamieniania prawidłowych międzynarodowych nazw w nieczytelne zakodowane ciągi.

Ostrzeżenia przeglądarki zapewniają drugą linię obrony, ale mają ograniczenia

Domena wyświetlana w Unicode nadal podlega kontrolom podczas nawigacji, lecz zależą one od dokładnych porównań, długości nazwy i historii użytkownika.

Chromium oddziela wyświetlanie adresu od ochrony podczas nawigacji. Pierwszy system określa, jak nazwa hosta wygląda na pasku adresu. Drugi może przerwać lub opatrzyć wizytę adnotacją po przejściu użytkownika na stronę.

Komponent Chromium do wykrywania sobowtórów podczas nawigacji porównuje odwiedzany adres z popularnymi domenami i witrynami, które użytkownik regularnie odwiedza. W zależności od dopasowania Chrome może wyświetlić pełnoekranową stronę pośrednią lub mniej inwazyjną wskazówkę bezpieczeństwa.

Projekt ostrzeżeń o sobowtórach opisuje te kontrole jako dodatkową warstwę obok Google Safe Browsing. Popularność oraz wcześniejsze interakcje użytkownika dają przeglądarce punkty odniesienia do identyfikowania podejrzanych alternatyw.

HIBS podaje, że dokładne dopasowanie szkieletu do jednej z 836 domen o najwyższym priorytecie wywołuje stronę pośrednią. Dokładne dopasowanie do innej dołączonej domeny może wywołać wskazówkę bezpieczeństwa.

Przeglądarka uwzględnia również strony, które użytkownik odwiedza z wystarczającą częstotliwością. Jeśli nowy adres dokładnie przypomina jedną z takich często odwiedzanych witryn, Chromium może zablokować nawigację i zapytać, czy użytkownik zamierzał otworzyć znaną domenę.

Bliskie dopasowania są traktowane w węższym zakresie. Chromium może wykryć szkielet różniący się jednym dodanym, usuniętym lub zastąpionym znakiem. Może też rozpoznać pojedynczą zamianę sąsiadujących znaków.

Porównania te nie są stosowane jednolicie. Według badania test bliskiego dopasowania pomija docelowe etykiety krótsze niż pięć znaków przed domeną najwyższego poziomu. Ma to znaczenie dla marek o krótkich nazwach.

Sobowtór Okta wykorzystujący ƙ różni się od prawdziwej nazwy jedną zmianą, lecz „okta” ma cztery znaki. Badacze twierdzą, że czyni to nazwę zbyt krótką dla odpowiedniej kontroli bliskiego dopasowania.

Przykład Apple zawodzi z innego powodu. Jego szkielet różni się od apple.com o dwie zmiany, ponieważ ө normalizuje się do „o” z zachowaną kreską. Porównanie niemal zgodnych nazw dopuszcza tylko jedną zmianę.

W rezultacie testowana domena była wyświetlana jako Unicode i ładowała się bez ostrzeżenia o domenie łudząco podobnej. HIBS twierdzi, że pozostawało to prawdą nawet w przypadku osoby, która regularnie odwiedzała autentyczną stronę Apple.

Tych ustaleń nie należy interpretować jako kompletnego audytu wszystkich zabezpieczeń towarzyszących wizycie. Safe Browsing, źródła danych o zagrożeniach, oprogramowanie endpointowe, filtrowanie DNS, bramki pocztowe i usługi reputacyjne nadal mogą oznaczyć złośliwą domenę.

HIBS wykluczył też z oceny niektóre zmienne, w tym zdalne listy dozwolonych, kontrole reputacji i określone zachowania przekierowań. Uzbrojona witryna mogłaby zatem napotkać inne mechanizmy obronne, których proof of concept nie testował.

Prawdziwe jest również przeciwieństwo. Nowo utworzona domena phishingowa może początkowo mieć niewiele danych reputacyjnych. Atakujący często wykorzystują ten okres, zanim zautomatyzowane systemy sklasyfikują infrastrukturę lub obrońcy przeprowadzą jej wyłączenie.

To wyjaśnia, dlaczego przypadek brzegowy ma znaczenie nawet wtedy, gdy istnieje wiele zabezpieczeń. Bezpieczeństwo warstwowe działa najlepiej, gdy awarie są niezależne. Tutaj kilka kontroli opiera się na ściśle powiązanych reprezentacjach szkieletów i listach domen, więc starannie dobrany znak może wpłynąć na więcej niż jedną decyzję.

Ochrona oparta na historii oznacza również, że dwóch użytkowników może zostać potraktowanych inaczej. Regularny odwiedzający chronioną usługę daje przeglądarce znaną domenę do porównania. Użytkownik odwiedzający ją po raz pierwszy może mieć jedynie wbudowaną listę popularności.

To rozróżnienie jest szczególnie istotne dla serwisów rekrutacyjnych, banków regionalnych, oprogramowania biznesowego i portali dostawców. Pracownicy mogą otrzymać link do usługi, której nigdy wcześniej nie odwiedzili, przez co przeglądarka ma mniej osobistej historii do porównania.

Najbezpieczniejszy wniosek nie brzmi, że Chromium nie zapewnia żadnej ochrony. Jego reguły zatrzymują wiele powszechnych podstawień, zanim dotrą one do użytkowników. Lekcja jest taka, że wygląd paska adresu i brak ostrzeżenia nie mogą same w sobie potwierdzać autentyczności.

Ataki homograficzne IDN wykraczają poza pasek adresu

Przeglądarka jest tylko jedną powierzchnią wyświetlania, podczas gdy zwodnicze domeny mogą docierać do użytkowników przez e-mail, komunikatory, dokumenty i wyniki wyszukiwania.

Atak homograficzny IDN wykorzystuje różne znaki, które wyglądają podobnie, aby podszyć się pod inny identyfikator. Typosquatting to szersza praktyka rejestrowania mylących alternatyw dla legalnej domeny, obejmująca proste błędy w pisowni i wizualnie zwodnicze znaki.

Nowe badania znajdują się na styku tych kategorii. Domeny nie są konwencjonalnymi błędami klawiaturowymi, lecz ich wizualne podobieństwo może wykorzystywać szybkie czytanie, małe ekrany i znajome kształty marek.

E-mail tworzy szczególnie trudne przekazanie. Reguły adresowe Chromium chronią nazwy hostów renderowane przez interfejs przeglądarki. Nie regulują automatycznie tekstu Unicode, który aplikacja webmail umieszcza w nagłówku wiadomości.

HIBS przetestował 20 umiędzynarodowionych domen nadawców w Gmailu i Outlooku w wersji webowej. Badacze podają, że Gmail wyświetlał wszystkie 20 w Unicode, w tym domeny, które pasek adresu Chromium renderowałby jako Punycode.

Według testu Gmail zachował zakodowaną formę w oddzielnym polu mailed-by. Większość odbiorców częściej sprawdzi wyróżnioną linię nadawcy, niż rozwinie techniczne informacje o dostarczeniu.

W teście badaczy Outlook w wersji webowej przyjął przeciwne podejście. Wyświetlał wszystkie 20 domen nadawców jako etykiety zgodne z ASCII, w tym zwykłe międzynarodowe nazwy, takie jak café.com i zürich.com.

Żadne z tych podejść nie rozwiązuje w pełni podstawowego kompromisu. Dekodowanie wszystkiego zapewnia użytkownikom czytelne międzynarodowe adresy, ale zachowuje wizualną niejednoznaczność. Kodowanie wszystkiego ujawnia różnice, jednocześnie czyniąc legalne wielojęzyczne adresy nieznajomymi i trudnymi do interpretacji.

Komunikatory i dokumenty mogą wprowadzać tę samą lukę. Platforma może renderować link Unicode jako zwykły tekst, zanim przeglądarka otrzyma wybrany adres docelowy. Użytkownik ocenia jeden widok, a następnie przechodzi przez inny system bezpieczeństwa.

Wyniki wyszukiwania i reklamy dodają kolejną drogę. Zwodnicza domena może pojawić się obok znajomego brandingu i skopiowanych tytułów stron. Nawet jeśli adres nieznacznie się różni, otaczający kontekst może zachęcić użytkownika do dopełnienia wizualnego wzorca.

Kody QR niemal całkowicie usuwają widoczny adres docelowy do momentu skanowania. Przeglądarki mobilne mają też mniej miejsca na nazwy hostów, a interfejsy mogą podkreślać tytuł strony zamiast pełnego adresu.

Konsorcjum Unicode zaleca kilka mechanizmów obrony przed mylącymi IDN. Obejmują one ograniczanie dozwolonych repertuarów znaków, zapobieganie ryzykownemu mieszaniu skryptów, stosowanie kontekstowych ograniczeń językowych i blokowanie rejestracji przypominających istniejące etykiety.

Jego wytyczne bezpieczeństwa IDN podkreślają też istotne zastrzeżenie. Mylące znaki Unicode stanowią jedynie niewielką część phishingu. Proste domeny, takie jak secure-brand-login.com, pozostają częstsze i nie wymagają nietypowych znaków.

Ten kontekst zapobiega przekształceniu nowych ustaleń w twierdzenie, że Unicode spowodował większość oszustw internetowych. Atakujący zwykle wybierają najtańszą skuteczną metodę. Znajome słowo, wprowadzająca w błąd subdomena, przejęte konto lub skompromitowana legalna witryna mogą być łatwiejsze niż tworzenie zaawansowanego IDN.

Mniejsza powszechność nie eliminuje jednak ryzyka dla celów o wysokiej wartości. Platformy tożsamościowe, usługi finansowe, konsole chmurowe i portale pracownicze oferują atakującym cenne dane uwierzytelniające. Wizualnie przekonujące podszycie się może być warte dodatkowego wysiłku.

Sama internacjonalizacja nie jest wadą. Internet musi obsługiwać nazwy zapisywane poza podstawowym alfabetem łacińskim. Traktowanie każdego takiego adresu jako wrogiego przerzuciłoby ciężar na legalnych użytkowników i firmy.

Nierozstrzygnięte pozostaje pytanie, gdzie powinien działać każdy mechanizm obronny. Przeglądarki kontrolują wyświetlanie i ostrzeżenia nawigacyjne. Rejestry kontrolują, które etykiety można zarejestrować. Usługi pocztowe kontrolują prezentację nadawcy. Właściciele marek monitorują podejrzane rejestracje, a zespoły bezpieczeństwa je filtrują i badają.

Żaden uczestnik nie widzi całej ścieżki ataku. To rozproszenie pozwala domenie odrzuconej przez jeden interfejs wyglądać przekonująco w innym.

Rejestry nie mogą pozostawiać spoofingu IDN w Chromium przeglądarkom

Najtrwalsza obrona zaczyna się przed nawigacją, lecz polityki rejestrów pozostają rozdrobnione między językami i domenami najwyższego poziomu.

Domena nie może obsługiwać niezależnej witryny ani skrzynki pocztowej, jeśli rejestr nie zezwala na jej rejestrację. Kontrole rejestrów mogą więc blokować zwodnicze nazwy, zanim przeglądarki będą musiały zdecydować, jak je wyświetlać.

Polityki dotyczące umiędzynarodowionych domen powszechnie wykorzystują tabele IDN. Tabele te określają, które znaki Unicode akceptuje domena najwyższego poziomu oraz które kombinacje lub warianty wymagają szczególnego traktowania.

Konsorcjum Unicode zaleca łączenie lub blokowanie mylących etykiet. Łączenie przypisuje powiązane warianty temu samemu rejestrującemu. Blokowanie pozwala istnieć jednej etykiecie, jednocześnie uniemożliwiając rejestrację mylących alternatyw.

Wytyczne wdrażania IDN ICANN ustanawiają ogólne oczekiwania mające ograniczać cybersquatting i dezorientację konsumentów. Faktyczne polityki nadal się różnią, ponieważ poszczególne rejestry obsługują różne języki, skrypty i lokalne wymagania.

Rejestr .com zezwolił na rejestracje proof of concept HIBS. Nie oznacza to, że .com akceptuje każdą sekwencję Unicode. Oznacza, że testowane znaki i kombinacje mieściły się w obowiązujących zasadach rejestracji.

HIBS przeanalizował również plik strefy .com uzyskany za pośrednictwem Centralized Zone Data Service ICANN w październiku 2026 roku. Badacze naliczyli 167,226,216 delegowanych nazw .com, w tym 733,509 reprezentowanych w formie IDN.

Ich metodologia powiązała IDN z delegowanymi domenami ASCII, które wizualnie przypominały. Wygenerowała 161,894 par łudząco podobnych nazw obejmujących 133,953 odrębne nazwy ASCII.

Liczby te nie są liczbą złośliwych domen. Badacze wyraźnie zaznaczają, że wizualna para może reprezentować rejestrację obronną, wielojęzyczną witrynę lub niepowiązaną organizację.

To rozróżnienie jest kluczowe. Domena zawierająca znak diakrytyczny może przypadkowo przypominać nazwę ASCII. Własność, treść, zachowanie DNS, certyfikaty, konfiguracja poczty e-mail i przekierowania stanowią silniejsze dowody złośliwego zamiaru.

Mimo to skala pokazuje, dlaczego listy przeglądarek nie mogą wyliczyć każdego istotnego celu. Wbudowane zabezpieczenia Chromium obejmują tysiące rozpoznawalnych nazw, podczas gdy strefa .com zawiera miliony firm i organizacji, które mogą paść ofiarą podszywania się.

Małe firmy mogą być szczególnie narażone. Ich domeny rzadziej trafiają na globalne listy popularności, ale ich klienci mogą ufać fakturom, portalom dostawców i wiadomościom o resetowaniu haseł zawierającym nazwę firmy.

Rejestr mógłby odpowiedzieć zakazem używania nowo zidentyfikowanego znaku w określonych kontekstach. Takie podejście może zamknąć jeden przypadek brzegowy, ale może też wykluczyć prawidłowe słowa i społeczności, które opierają się na tym znaku.

Precyzyjniejsza polityka może definiować warianty na podstawie relacji charakterystycznych dla danego języka. Jednak wizualne podobieństwo zależy od krojów pisma, rozmiaru, sąsiednich liter i znajomości języka przez czytelnika. Sekwencja oczywista dla osoby anglojęzycznej może być legalnym słowem w innym języku.

Rejestracja obronna oferuje kolejną opcję. Marka może zarejestrować prawdopodobne warianty i przekierować je do autentycznej domeny. Kod nawigacji Chromium rozpoznaje niektóre bezpieczne przekierowania, co pomaga uniknąć ostrzeżeń dla wariantów kontrolowanych przez rzeczywistą organizację.

Ta strategia nie skaluje się idealnie. Unicode zawiera wiele potencjalnych podstawień, a polityki rejestracji różnią się między domenami najwyższego poziomu. Kupowanie każdego możliwego odpowiednika wiązałoby się z ciągłymi kosztami i nadal pozostawiałoby luki.

Monitorowanie zapewnia szerszy zasięg. Zespoły bezpieczeństwa mogą obserwować nowe rejestracje, wydawanie certyfikatów, zmiany DNS i zachowanie hostingu dla nazw przypominających ważne domeny. Wczesne wykrywanie wspiera wnioski o wyłączenie i blokady, zanim atak dotrze do wielu osób.

Organizacje powinny również chronić przepływy pracy wysokiego ryzyka poza przeglądarką. Menedżery haseł dopasowują dane uwierzytelniające do dokładnych originów, przez co rzadziej automatycznie wypełniają je w domenie łudząco podobnej. Passkeys wiążą uwierzytelnianie z domeną legalnej witryny i są odporne na konwencjonalny phishing danych uwierzytelniających.

Pracownicy obsługujący płatności lub odzyskiwanie kont potrzebują ścieżek weryfikacji, które nie opierają się na wyglądzie linku. Znane zakładki, zarządzane portale aplikacji i niezależnie potwierdzone kanały kontaktu zmniejszają zależność od wizualnego rozpoznawania domen.

Środki te dotyczą czegoś więcej niż łudząco podobnych nazw Unicode w Chromium. Pomagają również przeciwko zwykłym literówkom, wprowadzającym w błąd subdomenom, przejętym skrzynkom pocztowym i sklonowanym stronom logowania.

Presja spada więc jednocześnie na kilka stron. Chromium musi dopracować swoje heurystyki. Rejestry potrzebują silniejszych polityk wariantów. Dostawcy poczty potrzebują czytelniejszych prezentacji nadawcy. Organizacje potrzebują mechanizmów kontroli zakładających, że użytkownicy czasem błędnie odczytają adres.

To, co wydarzy się dalej, pokaże, czy luka naprawdę zostanie zamknięta

Trzy sygnały określą, czy te badania przyniosą trwałą ochronę, czy jedynie kolejny wpis w historii załatanych domen łudząco podobnych.

Pierwszym sygnałem będzie zmiana reguł Chromium. Najbardziej jednoznaczna odpowiedź dotyczyłaby cyrylickiego ө, łacińskiego ƙ lub logiki rozgałęzień, która pozwala jednemu niewymienionemu znakowi ominąć ocenę całego skryptu.

Samo dodanie dwóch znaków zatrzymałoby opublikowane przykłady. Nie musiałoby jednak rozwiązać problemu strukturalnego. Inny znak z widocznym oznaczeniem lub nietypowym mapowaniem szkieletu mógłby odtworzyć ten sam rezultat.

Szersza poprawka mogłaby porównywać wrażenie wizualne po dodatkowych przekształceniach szkieletu znaków. Luźniejsze porównania zwiększają jednak liczbę fałszywych alarmów, zwłaszcza w przypadku prawidłowych nazw międzynarodowych.

Publiczny kod i testy Chromium sprawiają, że proces ten można obserwować. Badacze bezpieczeństwa mogą sprawdzić, czy poprawka blokuje zarejestrowane dowody przy jednoczesnym zachowaniu zwykłych domen w językach, których problem dotyczy.

Drugim sygnałem są działania rejestrów. Zaktualizowane tabele IDN mogłyby klasyfikować te znaki jako warianty w określonych kontekstach lub uniemożliwiać rejestracje naśladujące uznane etykiety ASCII.

Działania rejestrów wzmocniłyby główną ocenę artykułu, ponieważ powstrzymują zwodnicze nazwy, zanim pojawią się różnice w wyświetlaniu. Poprawka dotycząca wyłącznie przeglądarki pozostawiłaby takie domeny dostępne dla klientów poczty i innych aplikacji stosujących inne reguły renderowania.

Trzecim sygnałem byłaby zmiana prezentacji poczty. HIBS stwierdził, że Gmail dekodował wszystkie testowane domeny nadawców, podczas gdy Outlook wyświetlał zakodowane etykiety. Przyszłe zmiany interfejsu mogą ujawniać obie formy, oznaczać mieszane tożsamości wizualne lub ostrzegać, gdy nadawca przypomina znaną domenę.

Ten sygnał ma znaczenie, ponieważ poczta e-mail pozostaje naturalnym kanałem dostarczania ataków służących kradzieży danych uwierzytelniających i oszustwom płatniczym. Poprawka Chromium nie może ochronić przed zwodniczą nazwą nadawcy renderowaną jako tekst wewnątrz aplikacji internetowej.

Badacze będą również musieli ponownie przetestować ustalenia po aktualizacjach. Oryginalna praca badała określone zachowanie przeglądarki, zarejestrowane nazwy i testowe skrzynki pocztowe w konkretnym czasie. Nie wykazała, że każda kompilacja Chromium, system operacyjny, czcionka lub aplikacja pocztowa będzie renderować te znaki identycznie.

Różnice między czcionkami mogą osłabiać lub wzmacniać iluzję. Przy większych rozmiarach pasek przecinający ө jest łatwiejszy do zauważenia. W kompaktowym pasku adresu lub polu nadawcy różnica ta może być mniej widoczna.

Opisane rejestracje dowodzą również możliwości, a nie powszechnego wykorzystywania. Publiczne dowody kampanii phishingowych używających dokładnie tych znaków zwiększyłyby pilność problemu. Brak takich zgłoszeń nie oznaczałby, że luka jest nieszkodliwa, lecz wpłynąłby na priorytetyzację ryzyka.

Dla użytkowników bezpośrednia lekcja jest węższa niż „nigdy nie ufaj Unicode”. Weryfikuj nieoczekiwane prośby za pośrednictwem znanego kanału, zwłaszcza gdy dotyczą danych uwierzytelniających, płatności lub odzyskiwania konta. Zakładka albo menedżer haseł stanowią lepszy punkt odniesienia niż sama kontrola wzrokowa.

Administratorzy powinni sporządzić inwentaryzację najważniejszych domen i monitorować rejestracje do nich podobne. Wymagaj uwierzytelniania odpornego na phishing w systemach wrażliwych. Traktuj nowe dane dostawcy lub dane płatnicze jako zdarzenie wymagające weryfikacji, a nie rutynowe zadanie wykonywane na podstawie e-maila.

Zespoły produktowe powinny testować sposób wyświetlania przez aplikacje umiędzynarodowionych adresów nadawców i linków. Pokazywanie przyjaznej nazwy Unicode bez możliwości dostępu do formy zakodowanej może ukrywać użyteczne dowody. Wyświetlanie wyłącznie Punycode może natomiast niepotrzebnie utrudniać korzystanie z prawidłowych tożsamości międzynarodowych.

Mechanizmy ochrony Chromium przed podszywaniem się pod IDN pozostają istotne, lecz badanie to pokazuje, że istotne nie znaczy kompletne. Przeglądarka blokuje oczywiste podstawienia znaków z różnych alfabetów i znane sztuczki wykorzystujące całe alfabet y, a następnie podczas nawigacji sprawdza popularne i znane miejsca docelowe.

Starannie dobrany znak może nadal zmienić porównanie wykonywane przez maszynę, nie zmieniając wrażenia odbieranego przez spieszącego się człowieka. Ta luka jest niewielka w kodzie, ale znacząca wszędzie tam, gdzie zaufanie zależy od rozpoznania nazwy.

Najbliższe miesiące powinny pokazać, czy Chromium, rejestry i dostawcy poczty potraktują te przykłady jako odosobnione uzupełnienia listy, czy jako dowód, że warstwy wymagają innych założeń. Do tego czasu organizacje powinny przetestować własne domeny, wzmocnić uwierzytelnianie powiązane z pochodzeniem i przestać wymagać od użytkowników podejmowania decyzji bezpieczeństwa wyłącznie na podstawie typografii.