Перевірка гомографів IDN

Імена були лише ASCII перші два десятиліття DNS, тому все про них вимірюється в байтах і літерах: мітки з літер, цифр і дефісів, не більше 63 байтів кожна, не більше 255 байтів загалом. Інтернаціоналізоване доменне ім'я (IDN) — це те, що відбувається, коли правила відкривають для решти Unicode, а punycode (RFC 3492) — правило запису, яке зберігає працездатність старого механізму: мітка, що містить щось поза ASCII, записується як мітка xn--, рядок ASCII з тими самими символами у згорнутій формі. 中文.com подорожує як xn--fiq228c.com, і обидва записи означають той самий хост.

Важливо тут те, чого punycode не робить. Він перетворює написання і більше нічого. Він не має думки про те, чи можна дозволити аpple.com поруч із apple.com, і його не можна про це спитати, бо це питання про очі та шрифти, а не про байти. Реєстр вирішує, які символи продаватиме, браузер вирішує, як показувати ім'я, яке вважає безпечним, а читач вирішує, чи клікати. Ця сторінка відповідає на питання під усіма трьома: з яких символів насправді складається це ім'я і що це робить, коли воно пишеться?

Кожен рядок нижче виконується цією сторінкою під час завантаження і знову кнопкою Самотест, і сторінка має повідомляти саме те, що зазначає рядок: ті самі висновки, той самий рівень, та сама форма DNS, та сама кількість байтів, не більше і не менше. Саме це робить чисту відповідь тут цінною: шлях коду, який пропускає звичайне ім'я, той самий, що ловить трюки нижче.

1. Витягніть ім'я з того, що ви вставили. Голе ім'я використовується як є; з URL хост витягується, а схема, порт, шлях і запит відкидаються, і сторінка каже, що з двох вона зробила, а не тихо аналізує скісну рису як частину імені.
2. Очистіть його так, як це зробив би клієнт. Керувальні символи, символи нульової ширини і мітка порядку байтів відкидаються, повноширинна або ідеографічна крапка рахується як крапка, а кінцева крапка — це корінь, а не помилка. Кожен символ, видалений або переінтерпретований так, повідомляється, бо непомітно відкинутий пробіл нульової ширини — саме те, про що вам треба знати.
3. Розділіть на мітки і виміряйте кожну. Мітка не може бути порожньою, починатися або закінчуватися дефісом, або мати два дефіси на позиціях три і чотири, якщо вона не є міткою xn--. Кожна мітка вимірюється в байтах UTF-8 проти стелі 63 байти, а все ім'я — проти 255.
4. Декодуйте кожну мітку xn-- назад у її символи. Декодована мітка потім кодується вдруге і порівнюється з тим, що ви ввели. Мітка, яка не проходить цей цикл, — не та мітка, за яку себе видає, а така, що декодується в керувальний символ або в нічого, повідомляється як така, а не тихо відкидається.
5. Запитайте, що є кожен символ. Його кодова точка, його байти UTF-8, скрипт, до якого він належить, чи входить він до групи символів, що малюються однаково, і що ще є в цій групі. Тут кирилична а перестає бути «літерою» і стає «літерою, схожою на латинську».
6. Згорніть ім'я до форми, яку воно імітує. Кожен схожий символ замінюється символом, на який він схожий, і аpple.com стає apple.com. Це згорнуте прочитання — найкорисніший рядок на сторінці, бо apple.com є чимось, на що можна діяти, тоді як «кирилична а» ні.
7. Зберіть висновки і повідомте найгірший. Висновки повідомляються по одному разу, з мітками, де вони трапляються. Ім'я, яке лише виглядає незвично, дає примітки, а не висновки: змішування ханьцзі з кана або закінчення коренем — звичайне письмо, а не привід для занепокоєння.

немає нічого тут не варте згадки — низький те саме ім'я, написане вдруге іншим способом — середній символ, який DNS не перенесе, або який згортається до звичайної літери — високий ім'я, створене так, щоб його прочитали як інше ім'я, або яке взагалі не можна надіслати.

Рівень — це найгірше, що можуть означати висновки, а не ймовірність і не судження про сайт. Цілком чесне ім'я може бути середнім рівнем через один символ поза алфавітом імен хостів, а ворожне — високим, маючи лише кириличну літеру. Список під рівнем пояснює, чому, по одному рядку на висновок, і саме цей список варто читати.

Таблиця нижче побудована зі того самого списку, з якого сторінка повідомляє, тож рядок тут і висновок у результаті не можуть розходитися. Перевірка, яка нічого не знайшла, позначається як ні: сенс таблиці в тому, щоб ви бачили, що питання було поставлене і отримало відповідь, а не гадали, чи його взагалі ставили.

Той самий список керує примітками, які взагалі не мають рівня: одна мітка без крапки, кінцева крапка кореня, домен верхнього рівня, що не ASCII, роздільник, відмінний від крапки, ім'я у верхньому регістрі, символи, видалені під час очищення, і URL, зведений до свого хоста.

Ім'я — це список міток, і кожна з них рахується в байтах, а не в символах. Саме ця різниця є причиною існування punycode: 中文 — два символи і шість байтів, а його форма xn-- — п'ятнадцять символів, тож має вміщатися закодований запис. Сторінка застосовує обидві стелі і повідомляє, яку з них ви перевищили.

Можливо, ви помітили, що ім'я, написане китайською або кирилицею, іноді з'являється в адресному рядку як незрозумілі xn-- замість символів, яких ви очікуєте. Це браузер відмовляється показувати гарну форму, а не сайт, який не зареєстрував її. Браузер застосовує власне правило до імені, якого ще не бачив, і це правило існує з тієї самої причини, з якої існує вся ця сторінка: показувати аpple.com як аpple.com — саме те, чого хоче зловмисник, тож незнайоме ім'я зі змішаним скриптом показується у закодованому записі, доки його не побачать досить часто, щоб довіряти.

Punycode — це RFC 3492, і самотест цієї сторінки запускає одинадцять зразкових міток, надрукованих у цьому документі, як свою першу перевірку, тож кодувальник тут перевіряється за прикладами стандарту, а не за самим собою. Правила обробки, через які проходить IDN, — RFC 5891 з таблицями символів RFC 5892, а шар сумісності, який фактично застосовують браузери, — UTS #46 з прапорцем без перехідного режиму; ця сторінка каже, що роблять ці правила, а не вдає, що їх реалізує, і згортання, яке вона застосовує, — NFC, потім нижній регістр, потім RFC 3492, — та сама коротка послідовність, яку виконує клієнт перед надсиланням імені. Групи форм, діапазони скриптів і таблиці невидимих символів у цій родині сторінок написані вручну для цієї родини: стандарти названо, щоб ви могли прочитати їх самі, і жодного тексту з них тут не відтворено.

Чи завжди ім'я зі змішаним скриптом є атакою?

Ні, і ставитися так було б помилково в суттєвий спосіб. Японська пише ханьцзі й кана в одному слові, а корейська пише ханьцзі всередині хангиля. Без звичайного пояснення лишається латиниця, змішана з кирилицею або грецькою в одній мітці, бо ці скрипти не використовуються разом у жодній мові, і сторінка проводить цю межу, а не позначає кожну суміш. Тому японські й корейські рядки в таблиці випадків вище повертаються чистими.

Тоді чому моє ім'я показується як середнє?

Найімовірніше, воно містить один символ, якого алфавіт імен хостів не містить — підкреслення, пробіл, акцент, записаний як символ сумісності, — а це середній рівень, бо ім'я не можна надіслати як є. Середній рівень означає «це варто перевірити», а не «це підробка». Висновок під рівнем називає точний символ і його позицію.

Чи повідомляє сторінка, чи ім'я небезпечне, зареєстроване або доступне?

Ні, у всіх трьох. Вона ніколи не торкається мережі і нічого не розв'язує, тож не може знати, чи існує ім'я або хто його володіє, і навмисно нічого не каже про те, що робить сайт. Вона відповідає на вужче питання, яке ви можете перевірити самостійно: з яких символів складається це ім'я, і якщо я згорну схожі символи до літер, які вони імітують, що воно пише?

Моє ім'я китайською, і сторінка каже, що домен верхнього рівня не ASCII. Щось не так?

Нічого не не так. Китайський домен верхнього рівня подорожує як окрема мітка xn--, тож остання мітка імені записана у закодованій формі, і сторінка це відзначає. Примітки не мають рівня, бо описують факт, а не проблему.

Чому рядок «читається як» іноді показує те саме ім'я, яке я ввів?

Сторінка показує згорнуте прочитання лише тоді, коли згортання справді щось змінює. Якщо кожен символ у імені вже має форму, яку він імітує, згорнуте прочитання і ім'я — той самий рядок, і нема чого вам повідомити.

Що таке A-мітка і U-мітка?

A-мітка — це ASCII-запис, який подорожує: xn--fiq228c. U-мітка — та сама мітка, записана в тому скрипті, до якого вона належить: 中文. Це два записи однієї мітки, і сторінка показує обидва для кожної декодованої мітки, щоб ви бачили, що приховує закодована мітка.