Een homograafaanval registreert een domein dat is opgebouwd uit tekens die er identiek uitzien als die in een echt domein, maar dat niet zijn - een Cyrillische "a" die de plaats inneemt van een Latijnse "a", bijvoorbeeld - zodat het adres dat iemand leest en het adres dat een browser herleidt twee verschillende dingen zijn. Het trucje werkt omdat het domeinnaamsysteem alleen ASCII begrijpt, dus elk non-ASCII-domein wordt vertaald naar een ASCII-vorm die punycode heet, gemarkeerd met een xn---voorvoegsel, voordat het ooit DNS raakt. Browsers decoderen dat terug naar de leesbare versie voor weergave, en precies in die decodeerstap schuilt het bedrog.
Moderne browsers vangen de voor de hand liggende gevallen nu op en vallen terug op het tonen van ruwe punycode wanneer een label schriften op een verdachte manier mengt, waardoor de meeste van de makkelijke aanvallen die tien jaar geleden nog werkten, worden afgesloten. Maar die bescherming reikt niet verder dan de adresbalk van de browser.
Ik bekijk merkvervalsingszaken beroepshalve, en de goede vervalsingen trekken nog altijd een halve seconde mijn blik voordat het verraderlijke detail doordringt. Dit artikel behandelt hoe een homograafaanval werkt, waar de verdediging van de browser ophoudt, en wat je eraan kunt doen - of je nu op het punt staat te klikken, of het domein bezit dat wordt vervalst. Voor de bredere vraag of korte links zelf te vertrouwen zijn, behandelt zijn URL-verkorters veilig dat terrein; dit artikel gaat over het domein dat onder de link zit.
Wat punycode is en waarom het bestaat
DNS is gebouwd voor ASCII, punt uit. Het heeft geen native manier om de letters met accenten, of de Cyrillische, Arabische of Chinese tekens op te slaan waaruit de meeste schriftsystemen ter wereld bestaan, en dat was een reëel probleem zodra domeinregistratie zich buiten Engelstalige markten opende.
Punycode is de oplossing: een omkeerbare codering, gestandaardiseerd als RFC 3492, die een Unicode-label omzet in ASCII-letters, cijfers en koppeltekens die DNS kan dragen zonder enige wijziging aan het wire-protocol. Een Duitse bakkerij die een domein met een umlaut registreert, of een Oekraïense retailer die er een in het Cyrillisch registreert, krijgt een werkende geïnternationaliseerde domeinnaam die precies als elke andere wordt herleid, omdat het daaronder gewoon weer een ASCII-label is. De gecodeerde vorm begint altijd met xn--, wat aangeeft: "dit is punycode, decodeer het voordat je het aan een mens toont."
Niets daarvan is op zichzelf een kwetsbaarheid - geïnternationaliseerde domeinnamen zijn een echte, noodzakelijke functie, geen workaround die iemand zou moeten uitschakelen. Het probleem begint een laag hoger, op het moment dat een browser beslist hoe die gedecodeerde naam weer aan jou wordt getoond.
Hoe een homograafaanval werkt
Een homograafaanval maakt gebruik van de kloof tussen wat een domein bevat en hoe het eruitziet zodra het wordt weergegeven. In de praktijk komen twee varianten voor, en ze zijn niet even gebruikelijk.
De hele-schrift-versie registreert een compleet domein in een niet-Latijns schrift waarvan de lettervormen toevallig lijken op het doelmerk. Die is opvallend om te bouwen en makkelijker voor verdedigers om op te sporen, omdat het hele label vreemd is.
De gemengd-schrift-versie is degene die daadwerkelijk gebruikt wordt, omdat er maar één vervanging nodig is. Neem een domein als novacloud.com. Wissel de Latijnse "o" om voor de visueel identieke Cyrillische "о" (U+043E) en je krijgt nоvacloud.com - dezelfde vorm, dezelfde lengte, een ander code point, en een domein dat codeert naar xn--nvacloud-nbh.com. Al het andere in het label blijft ongewijzigd, dus het oog heeft bijna niets om op te merken. Beveiligingsonderzoekers noemen dit soort lookalike-paar een "confusable", en een handvol daarvan dekt het grootste deel van het Latijnse alfabet.
Zodra het domein geregistreerd is, is de rest van de aanval gewone phishing: een inlogpagina die pixel voor pixel is gekopieerd, een dringend bericht dat naar de vervalste link wijst, en een doelwit dat geen reden heeft om te twijfelen aan een adres dat er precies goed uitziet.
Wat browsers er vandaag aan doen
Browserleveranciers hebben de makkelijke versie van deze aanval jaren geleden grotendeels afgesloten met een regel over welke schriften in één label gemengd mogen worden. Het beleid van Chrome, gedocumenteerd in de IDN-handling guide, controleert of elk teken in een label plausibel tot één schrift behoort, of tot een kleine set schriftcombinaties die legitiem samen voorkomen, zoals Japanse kanji met hiragana. Meng schriften buiten die toegestane set en de browser toont de ruwe xn---vorm in plaats van die te decoderen - het beste wapen van de aanval, een domein dat er volkomen normaal uitziet, verandert weer terug in een overduidelijk gecodeerde string. Firefox voert een vergelijkbare controle uit, beschreven in Mozilla's IDN display-algoritme, en Safari past zijn eigen versie toe.
Het is geen volledige bescherming. Een gemengd-schrift-label dat alleen is opgebouwd uit tekens binnen één toegestane combinatie kan nog steeds doorglippen als een leesbare, misleidende naam, en de regel wordt browser voor browser gehandhaafd, zonder een gedeelde autoriteit die bepaalt wat als veilig geldt.
Waar die bescherming ophoudt
De controle op schriftvermenging zit in de rendercode van de adresbalk van de browser. Die reist nergens anders mee met de URL, en in dat gat richt een vervalst domein nog altijd echte schade aan.
E-mailclients vormen de grootste blootstelling: een bericht kan elke ankertekst boven een link tonen, ongeacht de bestemming, en de meeste mailapps voeren helemaal geen confusable-controle uit. Chatapps vouwen een gedeelde link uit tot een previewkaart die is opgebouwd uit paginametadata, geen punycode-bewuste renderer. QR-codes laten de tekststap helemaal weg, een gat dat we behandelen in zijn QR-codes veilig, en gedrukt materiaal heeft geen softwarelaag tussen het oog en het bedrog.
| Kanaal | Toont echte bestemming voordat je handelt | Typische blootstelling |
|---|---|---|
| Moderne desktopbrowser | Meestal, via regels voor schriftvermenging | Laag voor gangbare browsers, up-to-date gehouden |
| E-mailclient | Zelden - ankertekst kan van alles zeggen | Hoog, vooral in mobiele mailapps |
| Chat- en berichtenapps | Zelden - linkpreviews gebruiken paginametadata | Hoog, link-unfurls zien er identiek uit |
| QR-code | Nee - er wordt niets weergegeven tot na de scan | Hoog, de beslissing gebeurt in een fractie van een seconde |
| Gedrukt materiaal | Nooit - er komt geen software aan te pas | Hoogst, geen technische controle mogelijk |
Als je team links verstuurt onder een domein dat je klanten al herkennen, heeft een vervalste lookalike veel minder ruimte om je overtuigend na te bootsen op al die kanalen tegelijk. Bekijk hoe een custom branded domein werkt op Elido als je nog steeds links verstuurt vanaf een gedeeld of generiek domein.
Waarom een branded domein je beste verdediging is
Een homograafaanval werkt door misbruik te maken van herkenbaarheid - hij heeft een herkenbaar merk nodig om na te maken. Dat klinkt als een argument tegen het bouwen van een herkenbaar domein van jezelf, maar het is precies het tegenovergestelde. Een onderscheidende branded korte link die je publiek al met jou associeert, is iets waarmee ze een verdacht bericht kunnen vergelijken; een generiek of geleend shortener-domein geeft een aanvaller sowieso een sjabloon dat klanten niet van de echte provider kunnen onderscheiden, omdat geen van beide eruitziet als "jij."
Een custom domein voor korte links instellen betekent dat elke link die je verstuurt een naam draagt die ontvangers herkennen, wat de lat hoger legt voor iedereen die het probeert na te maken. De moeite waard om te onderscheiden van link cloaking en URL-masking, een bewuste, openlijke keuze om links via je eigen domein te routeren. Een homograafaanval is de tegenovergestelde zet - de identiteit van de aanvaller verbergen terwijl die de jouwe nabootst - en de verdediging is transparantie over welk domein daadwerkelijk van jou is.
De registrar-controls die er echt toe doen
Twee controls doen het meeste echte werk zodra je een domein bezit dat het waard is om te beschermen, en ze opereren op verschillende niveaus van de stack.
Registrar lock is de alledaagse - een statusvlag, vaak getoond als clientTransferProhibited, die routinematige geautomatiseerde overdrachtsverzoeken binnen het eigen dashboard van je registrar blokkeert. Elk domein dat je actief gebruikt zou dit aan moeten hebben; het kost niets. Registry lock zit een niveau hoger en schakelt de registeroperator rechtstreeks in, zodat elke wijziging, overdracht of verwijdering handmatige verificatie buiten de band vereist - een telefoontje of een beveiligde wachtwoordzin - voordat het van kracht wordt. Die wrijving hoort bij het ene of de twee domeinen waar een ongeautoriseerde wijziging echt duur zou uitpakken, wat voor de meeste bedrijven op zijn minst het primaire merkdomein betekent.
Geen van beide locks houdt iemand tegen om een lookalike-domein naast het jouwe te registreren. Daarvoor is actieve monitoring nodig: nieuwe domeinregistraties en publieke certificate-transparency-logs in de gaten houden op namen die visueel dicht bij je merk liggen, zodat je het kunt melden bij de registrar of klanten kunt waarschuwen voordat een campagne die ervan gebruikmaakt iemand bereikt.
Wat je in een brand-protection-beleid zet
Als je een domein bezit dat het waard is om te vervalsen, moet het beveiligingsonderdeel van je brand-protection-beleid specifiek genoeg zijn dat iemand die net in het team komt het kan uitvoeren zonder je eerst iets te hoeven vragen.
- Registrar transfer lock op elk domein dat het bedrijf bezit, met registry lock toegevoegd op het primaire merkdomein en alles dat betalingen of logins afhandelt.
- Een terugkerend ritme voor het scannen van nieuwe domeinregistraties en certificate-transparency-logs op namen die visueel dicht bij je merk liggen, geen eenmalige controle.
- Defensieve registratie van de lookalike-labels met het hoogste risico en verwarrende topleveldomeinen die je kunt verantwoorden, geprioriteerd naar hoe dicht ze bij je primaire domein liggen.
- Een aangewezen eigenaar en een escalatiepad voor het melden van een ontdekt lookalike-domein bij de registrar, plus interne richtlijnen zodat supportmedewerkers het patroon herkennen wanneer een klant er een meldt. De beveiligingschecklist voor het kiezen van een linkprovider behandelt de aanpalende leverancierscontroles.
Een verificatierecept dat iedereen kan volgen
Je hoeft punycode niet te begrijpen om een link veilig te controleren. Vier stappen, in volgorde uitgevoerd, vangen bijna alles op waar een homograafaanval op leunt.
- Vouw de link eerst uit, in plaats van er direct op te klikken. Hoe je ziet waar een korte URL naartoe gaat loopt de tools hiervoor door, en Elido's eigen link checker doet hetzelfde zonder je te vragen de bestemming eerst te vertrouwen.
- Lees het registreerbare domein - het deel direct voor het topleveldomein - in plaats van wat daarvoor staat. Dat is het deel dat een aanvaller volledig moet beheersen.
- Controleer op een xn---voorvoegsel, hetzij in de ruwe uitgevouwen URL, hetzij in de adresbalk van je browser. Als je er een ziet waar je een gewone merknaam verwachtte, stop dan en behandel het als een lookalike totdat het tegendeel bewezen is.
- Bevestig de certificaatnaam op de bestemmingssite. Een certificaat geeft weer wat daadwerkelijk aan een domeineigenaar is uitgegeven, wat een lastiger ding is om overtuigend te vervalsen dan een weergegeven label.
Geen van deze stappen kost meer dan een paar seconden zodra ze een gewoonte zijn geworden, en je kunt alle vier aan een niet-technische collega leren in de tijd die het kost om deze sectie één keer te lezen.
Een homograafaanval is een weergaveprobleem in een beveiligingskostuum. Punycode doet precies waarvoor het ontworpen is; het bedrog gebeurt in de kloof tussen wat een domein is en wat een stuk software je in plaats daarvan toont. Browsers hebben het grootste deel van die kloof gedicht voor de adresbalk. Overal elders staat de kloof nog open, en daarom blijft het uitvouwen van een link en het lezen van het registreerbare domein de gewoonte die werkt, ongeacht welk kanaal de link voor je neus zette.
Gerelateerd op de blog
Veelgestelde vragen
Wat is een IDN-homograafaanval?
Een IDN-homograafaanval registreert een domein met tekens uit een ander schrift die er identiek of bijna identiek uitzien als die in een echt domein, zodat een lezer de twee niet op het oog uit elkaar kan houden. Het klassieke geval wisselt één Latijnse letter om voor een Cyrillische of Griekse lookalike, bijvoorbeeld de Cyrillische a voor de Latijnse a, terwijl al het andere in het domein ongewijzigd blijft. Omdat het vervangende teken een ander onderliggend code point heeft, zijn de twee domeinen technisch gezien verschillend en kunnen ze door verschillende eigenaren geregistreerd en beheerd worden. De aanval slaagt puur op basis van uiterlijk, en daarom richt hij zich op herkenbare, vertrouwde merknamen in plaats van obscure.
Wat is punycode en waarom bestaat het?
Punycode is de codering die non-ASCII-domeinlabels omzet in een ASCII-string die het domeinnaamsysteem kan opslaan en herleiden, vastgelegd in RFC 3492. Het bestaat omdat DNS alleen een beperkte ASCII-tekenset begrijpt, dus een domein dat in het Cyrillisch, Arabisch, Chinees of met Latijnse letters met accenten is geschreven, moet naar die vorm vertaald worden voordat het opgezocht kan worden. Het gecodeerde label begint altijd met het xn---voorvoegsel, dat resolvers en browsers vertelt dat wat volgt een met punycode gecodeerde string is en geen gewone ASCII-naam. Browsers decoderen het vervolgens terug naar het oorspronkelijke schrift voor weergave, wat een legitieme en noodzakelijke functie is, niet op zichzelf de kwetsbaarheid.
Wat betekent het xn---voorvoegsel in een URL?
Het xn---voorvoegsel markeert een domeinlabel als ASCII Compatible Encoding, geproduceerd door punycode, en signaleert dat de leesbare naam vertaald is uit non-ASCII-tekens. Alles na het voorvoegsel is de gecodeerde vorm van het oorspronkelijke label - xn--nvacloud-nbh.com decodeert bijvoorbeeld naar een domein dat eruitziet als novacloud.com met één letter omgewisseld voor een lookalike. De xn---vorm zien waar je een gewone merknaam verwachtte, is precies het signaal waarmee browsers je waarschuwen, omdat het betekent dat het label schriften mengde op een manier die de browser niet veilig genoeg vond om als de mooie versie weer te geven. Een domein zonder non-ASCII-tekens levert nooit een xn---vorm op, dus als je er een ziet, is dat altijd de moeite van een tweede blik waard.
Beschermen browsers tegen homograafaanvallen?
Moderne browsers passen regels voor schriftvermenging toe die de meeste pogingen tot een homograafaanval opvangen en terugvallen op het tonen van de ruwe punycode-vorm in plaats van de misleidende versie. Chrome en Firefox controleren allebei of de tekens van een domeinlabel plausibel tot één schrift behoren, of tot een kleine set schriften die vaak samen gebruikt worden, en zo niet, dan tonen ze de xn---versie in plaats van die te decoderen tot iets dat kan doorgaan voor een bekende naam. Dat sluit de makkelijkste hele-schrift-aanvallen uit als overtuigende bedriegers, al kunnen aanvallers binnen de toegestane sets nog steeds tekens vinden die visueel verwarrend lijken op Latijnse letters. De bescherming beperkt zich bovendien strikt tot de adresbalk van de browser - niets anders in de stack erft dit automatisch.
Hoe kan ik zien of een link een lookalike-domein is voordat ik erop klik?
Vouw de link eerst uit, zodat je de volledige bestemming ziet in plaats van een korte of afgekapte versie, en lees dan het registreerbare domein in plaats van wat daarvoor staat. Als de adresbalk of de uitvouwtool een xn---voorvoegsel toont waar je een gewone merknaam verwachtte, behandel dat dan als een lookalike-domein totdat het tegendeel bewezen is. Het certificaat van de bestemmingssite controleren is een nuttige laatste stap, omdat een certificaat weergeeft wat daadwerkelijk is uitgegeven en niet slechts wat wordt getoond. Niets hiervan vereist speciale software - alleen de gewoonte om het te doen voordat je een wachtwoord of kaartnummer invoert.
Wat is registry lock en heeft mijn domein dat nodig?
Registry lock is een beheersmaatregel op het niveau van het domeinregister die elke wijziging, overdracht of verwijdering van een domein blokkeert totdat die handmatig en buiten de band wordt geverifieerd, doorgaans telefonisch of met een beveiligde wachtwoordzin, waardoor zelfs een gecompromitteerd registrar-account het domein niet kan verplaatsen. Het is een sterkere garantie dan de gebruikelijkere registrar lock, die alleen routinematige geautomatiseerde overdrachten binnen je eigen registrar-dashboard voorkomt. Registry lock is de bescheiden jaarlijkse kosten waard voor elk domein waarvan downtime of kaping duur zou uitpakken, wat voor de meeste bedrijven op zijn minst het primaire merkdomein betekent. Het houdt niemand tegen om een soortgelijk ogend domein naast het jouwe te registreren - dat is een apart probleem dat wordt opgelost door monitoring, niet door locking.
Probeer Elido
Plak een URL, krijg een werkende korte link
Geen aanmelding nodig. Link blijft 30 dagen actief. Meld je aan om hem voor altijd te bewaren.
Gratis, geen aanmelding nodig · 2 per dag