IDN-homográf ellenőrző

A nevek az első két évtizedben csak ASCII-ban léteztek, ezért minden róluk szóló állítás betűkben és bájtokban van mérve: csak betűkből, számjegyekből és kötőjelekből álló címkék, legfeljebb 63 bájt címkénként, legfeljebb 255 bájt összesen. Egy nemzetközi domainnév (IDN) akkor keletkezik, amikor a szabályokat kinyitják a Unicode többi részére; a punycode (RFC 3492) pedig az írásszabály, amely a régi gépezetet működőképesen tartja: minden ASCII-n kívüli tartalmú címke xn-- címkeként íródik, egy ASCII-karakterlánc, amely ugyanazokat a karaktereket redukált formában hordozza. A 中文.com úgy utazik, mint xn--fiq228c.com, és mindkét írásmód ugyanazt a gazdagépet nevezi meg.

Ami itt számít, az az, amit a punycode nem tesz. Csak a helyesírást alakítja át, mást nem. Nincs véleménye arról, hogy a аpple.com megengedett-e az apple.com mellett, és nem is lehetne megkérdezni, mert ez a kérdés szemekről és betűkészletekről szól, nem bájtokról. A regisztrátor dönti el, mely karaktereket árulja, a böngésző dönti el, hogyan jelenít meg egy biztonságosnak tartott nevet, az olvasó pedig, hogy kattint-e. Ez az oldal a három alatti kérdésre válaszol: pontosan milyen karakterekből áll ez a név, és mit jelent, ha így olvassuk?

Az alábbi minden sort az oldal betöltéskor futtatja, és az Önellenőrzés gombbal újra lefuttatható. Az oldalnak pontosan azt kell jelentenie, amit a sor állít: ugyanazokat a találatokat, ugyanazt a szintet, ugyanazt a DNS-alakot, ugyanazt a bájtszámot, sem többet, sem kevesebbet. Ettől az itteni tiszta válasz valamit ér: az a kódútvonal, amely egy hétköznapi nevet átenged, ugyanaz, mint amely az alábbi trükköket elkapja.

1. A nevet kiemeljük a beillesztett szövegből. Egy puszta név úgy használatos, ahogy van; egy URL esetén a gazdagép kerül kivonásra, a séma, a port, az útvonal és a lekérdezés elvetésre kerül, és az oldal jelzi, melyik esetről van szó, ahelyett hogy csendben egy perjelet elemezne név részeként.
2. A tisztítás úgy történik, ahogy egy kliens tenné. A vezérlőkarakterek, a nulla szélességű karakterek és a bájtsorrend-jelölő (BOM) eltávolításra kerülnek, a teljes szélességű vagy ideografikus pont pontként számít, a záró pont pedig a gyökér jele, nem hiba. Minden így eltávolított vagy újraértelmezett karakter jelentésre kerül, mert a csendben eldobott nulla szélességű szóközről tudni kell.
3. A nevet címkékre bontjuk, és mindegyiket megmérjük. Egy címke nem lehet üres, nem kezdődhet és nem végződhet kötőjellel, és a harmadik és negyedik pozícióban nem állhat két kötőjel, kivéve ha xn-- címke. Minden címkét UTF-8 bájtban mérünk a 63 bájtos határhoz, az egész nevet pedig a 255-höz.
4. Minden xn-- címke visszafejtése a karakterekre. A visszafejtett címke újra kódolásra kerül, és összevetjük a beírt szöveggel. Az a címke, amely nem éli túl ezt az oda-vissza utat, nem az a címke, amelyet jelöl; amely vezérlőkarakterre vagy üres szövegre dekódolódik, az jelentésre kerül, és nem dobódik el csendben.
5. Mindegyik karakterről megállapítható: a kódpontja, az UTF-8 bájtjai, az írásrendszer, amelyhez tartozik, hogy van-e olyan karakterek csoportjában, amelyek hasonlóan néznek ki, és a csoport többi tagja. Itt derül ki, hogy egy cirill a nem „betű”, hanem „a latin betűhöz hasonló alakú betű”.
6. A név az utánzott alakra redukálva. Minden hasonló karakter arra a karakterre cserélődik, amelyhez hasonlít, így a аpple.com apple.com-má alakul. Ez a redukált olvasat a lap legfontosabb sora, mert az apple.com olyan, amire lehet reagálni, míg az „egy cirill a” nem.
7. A találatok összegyűjtése, és a legsúlyosabb jelentése. Minden találat egyszer szerepel, azokkal a címkékkel együtt, amelyekben előfordul. A szokatlannak látszó nevek megjegyzéseket eredményeznek, nem találatokat: a Han és a Kana keveredése vagy a gyökérponttal való végződés hétköznapi írásmód, nem ok az aggodalomra.

nincs itt nem volt említésre méltó semmi — alacsony ugyanaz a név egy második módon írva — közepes olyan karakter, amelyet a DNS nem visz tovább, vagy amely sima betűre redukálódik — magas olyan név, amelyet más névnek való olvasásra építettek, vagy amely egyáltalán nem küldhető el.

A szint a találatok legrosszabb lehetséges jelentése, nem valószínűség és nem ítélet az oldalról. Egy teljesen becsületes név lehet közepes, mert tartalmaz egy karaktert a gazdagépnév-ábécén kívülről, egy rosszindulatú pedig magas is lehet egyetlen cirill betűvel. A szint alatti lista soronként megindokolja a találatokat; ezt a listát érdemes elolvasni.

Az alábbi táblázat ugyanabból a listából készül, amelyből az oldal a jelentéseit is, így egy sor a táblázatban és egy találat az eredményben nem mondhat ellent egymásnak. Az a vizsgálat, amely nem talált semmit, nem-ként szerepel: a táblázat lényege, hogy látható legyen, hogy a kérdést feltették és megválaszolták, nem pedig az, hogy kétséges-e, feltették-e egyáltalán.

Ugyanaz a lista vezérli a megjegyzéseket, amelyeknek egyáltalán nincs szintjük: egy pont nélküli címke, egy záró gyökérpont, nem ASCII legfelső szintű domain, a ponttól eltérő elválasztó, nagybetűs név, a tisztítás során eltávolított karakterek és egy URL, amelyet a gazdagépre redukáltak.

A név címkék listája, és mindegyik bájtban számolódik, nem karakterben. Ez a különbség az oka annak, hogy a punycode létezik: a 中文 két karakter és hat bájt, az xn-- alakja pedig tizenöt karakter, ezért a kódolt alakot kell megfelelni a határnak. Az oldal mindkét határt alkalmazza, és jelzi, melyiket érte el.

Előfordult már, hogy egy kínai vagy cirill nevet a címsorban xn-- érthetetlen szövegként látunk a várt karakterek helyett. Ez az, amikor a böngésző nem jeleníti meg a szép alakot, nem pedig az, hogy az oldal nem regisztrálta. A böngésző saját szabályt alkalmaz az addig nem látott nevekre, és ez a szabály ugyanazért létezik, amiért ez az egész lap: a аpple.com аpple.com-ként való megjelenítése pontosan az, amit egy támadó akar, ezért egy ismeretlen vegyes írásrendszerű nevet kódolt alakban mutat, amíg elég gyakran nem látták ahhoz, hogy megbízhatónak tekintsék.

A punycode az RFC 3492, és az oldal önellenőrzése első lépésként ennek a dokumentumnak a tizenegy mintacímkéjét futtatja, így a kódoló a szabvány példáihoz igazodik, nem önmagához. Az IDN-ekre alkalmazott feldolgozási szabályok az RFC 5891, az RFC 5892 karaktertáblázataival, a böngészők által ténylegesen alkalmazott kompatibilitási réteg pedig az UTS #46 nem-átmeneti jelzővel; az oldal azt mondja meg, mit tesznek ezek a szabályok, nem tesz úgy, mintha megvalósítaná őket, és az általa alkalmazott redukálás — NFC, majd kisbetűs alak, majd RFC 3492 — ugyanaz a rövid sorozat, amelyet a kliens elvégez egy név elküldése előtt. A csoportformák, az írásrendszer-tartományok és a láthatatlan karaktertáblázatok ebben a lapcsaládban kézzel készültek: a szabványok meg vannak nevezve, hogy el lehessen őket olvasni, szövegük pedig nincs idézve.

Mindig támadás a vegyes írásrendszerű név?

Nem, és ezt így kezelni komoly hiba volna. A japán a Han-karaktereket és a Kanát ugyanabban a szóban írja, a koreai pedig a Han-karaktereket a hangul betűkkel együtt. Az, aminek nincs hétköznapi magyarázata, a latin betűk keveredése görög vagy cirill betűkkel egy címkén belül, mert ezeket az írásrendszereket egyetlen nyelv sem használja együtt; az oldal ezt a vonalat húzza meg, nem minden keveréket jelöl meg. Ezért a fenti esettáblázat japán és koreai sorai tiszták.

Akkor miért lesz közepes szintű egy hétköznapi név?

Valószínűleg azért, mert tartalmaz egy karaktert, amelyet a gazdagépnév-ábécé nem tartalmaz — aláhúzásjel, szóköz, egy összetartó karakterként írt ékezet —, és ez közepes szintű, mert a név így nem küldhető el. A közepes azt jelenti: „ezt meg kell nézni”, nem azt, hogy „ez hamisítvány”. A szint alatti találat pontosan megnevezi a karaktert és a helyzetét.

Megmondja az oldal, hogy egy név veszélyes-e, regisztrálták-e, vagy elérhető-e?

Nem, mindhárom kérdésre. Soha nem fordul a hálózathoz, és semmit nem old fel, ezért nem tudhatja, létezik-e egy név vagy kié, és szándékosan nem mond semmit arról, mit csinál egy webhely. Egy szűkebb kérdésre válaszol, amelyet bárki ellenőrizhet: milyen karakterekből áll ez a név, és ha az utánzott betűkre redukáljuk a hasonló karaktereket, mit fog jelenteni?

Kínai a nevem, és az oldal azt jelzi, hogy a legfelső szintű domain nem ASCII. Van ebben valami hiba?

Nincs baj. A kínai legfelső szintű domain saját xn-- címkeként utazik, így a név utolsó címkéje kódolt alakban íródik, és az oldal ezt jelzi. A megjegyzések nem kapnak szintet, mert tényt írnak le, nem problémát.

Miért mutatja néha az olvasási sor ugyanazt a nevet, amelyet beírtak?

Mert az oldal csak akkor mutat redukált olvasatot, ha a redukálás ténylegesen változtat valamit. Ha minden karakter már az az alak, amelyet utánoz, akkor a redukált olvasat és a név ugyanaz a karakterlánc, és nincs mit jelezni.

Mi az A-címke és az U-címke?

Az A-címke a továbbított ASCII-alak: xn--fiq228c. Az U-címke ugyanaz a címke abban az írásrendszerben, amelyhez tartozik: 中文. Két írásmód egyetlen címkéhez; az oldal minden visszafejtett címkénél mindkettőt megmutatja, hogy látszódjon, mit rejt a kódolt címke.