IDN 동형이자 공격
도메인 이름에 시각적으로 유사한 유니코드 문자를 사용하여 합법적인 사이트를 사칭하는 공격. аpple.com(키릴 а)은 apple.com처럼 보입니다. 브라우저는 Punycode 표시 규칙으로 방어합니다.
What is an IDN Homograph Attack?
An IDN homograph attack is a phishing technique that exploits the Internationalized Domain Names in Applications (IDNA) standard to register domain names that look visually identical to legitimate domains but are composed of different Unicode characters. The attack was formally described by Evgeniy Gabrilovich and Alex Gontmakher in a 2002 paper, though the vulnerability had been anticipated when the IDN standard was being developed.
The term combines two concepts: IDN (Internationalized Domain Names, which allow non-ASCII characters in domain names) and homograph (a word that looks like another word but has different meaning — here applied to individual characters).
How IDNA Works
The Domain Name System (DNS) was designed for ASCII characters only. IDNA extends this by encoding non-ASCII domain names as ASCII-compatible encoding (ACE) using Punycode. For example:
- The domain
münchen.deis stored in DNS asxn--mnchen-3ya.de - The domain
中文.comis stored asxn--fiq228c.com
This allows speakers of all languages to register domains in their native scripts. Unfortunately, it also enables attackers to register domains that, when rendered as Unicode, are visually indistinguishable from existing domains.
Attack Mechanics
Consider the following real-world demonstration from 2017:
Security researcher Xudong Zheng registered аррlе.com — a domain where all five characters are Cyrillic lookalikes for the Latin letters a, p, p, l, e. The Punycode form is xn--80ak6aa92e.com. When Chrome and Firefox rendered this domain in their address bars (before the patch), users saw apple.com — indistinguishable from the genuine Apple website.
The attack succeeds because:
- IDNA2008 (the current standard) does not prohibit mixing visually similar characters across scripts
- Browsers historically displayed the Unicode form of domain names, not Punycode
- TLS certificates can be issued for IDN domains, so the padlock icon provides false assurance
Real-World Examples
- 2005: The first documented IDN phishing attempts targeting PayPal and eBay
- 2017: Xudong Zheng's
xn--80ak6aa92e.comdemonstration forced Chrome and Firefox to update their rendering policies - Ongoing: Security researchers regularly discover registered IDN lookalikes for banking, social media, and government domains
Browser Defenses
Browsers apply various heuristics to decide whether to display a domain as Unicode or Punycode:
- Firefox: Displays Punycode for any domain containing characters from multiple scripts unless the domain's TLD operator has whitelisted it
- Chrome: Uses a script-mixing heuristic combined with a block-list of known confusable patterns
- Safari: Converts to Punycode for mixed-script domains
These heuristics are not foolproof. Single-script attacks (all Cyrillic lookalikes) may still render as Unicode in some browsers.
Registrar Defenses
Some domain registrars and TLD operators implement IDNA-aware screening:
- Prohibiting registration of domains that are confusable with existing popular domains
- Restricting IDN registrations to a single script per label
- Requiring additional verification for IDN registrations
The .com and .net TLDs managed by Verisign apply mixed-script restrictions. However, enforcement varies widely across registrars and TLDs.
Quick Facts
| Property | Value |
|---|---|
| First described | Gabrilovich & Gontmakher, 2002 |
| Notable demonstration | Xudong Zheng, April 2017 |
| Encoding mechanism abused | IDNA / Punycode (RFC 3492) |
| Primary target | Web domain names for phishing |
| Browser mitigation | Punycode fallback for mixed-script domains |
| Certificate authority role | CAs issue certs for IDN domains — padlock does not indicate safety |
| Related standard | Unicode TR39 confusables, IDNA2008 (RFC 5891) |
관련 용어
보안의 더 많은 용어
Exploiting Unicode bidirectional control characters to disguise malicious code or filenames. The …
Exploiting Unicode normalization to bypass security filters. Input validated before normalization may …
U+200D. 인접 문자의 결합을 요청합니다. 이모지 시퀀스에 필수적입니다(👩+ZWJ+💻=👩💻). 인도 문자에서는 합자 형성을 …
U+200C. 인접 문자의 결합을 방지합니다. 페르시아어/아랍어에서 올바른 글자 형태를 위해 필수적이며, 데바나가리에서 …
서로 다른 문자 체계에서 동일하거나 매우 유사하게 보이는 문자. 예: 라틴 'a'와 …
유니코드 양방향 재정의 문자(U+202A~U+202E, U+2066~U+2069)를 사용하여 악성 파일 이름이나 코드를 위장하는 공격. …
유니코드 기능을 사용하여 사용자를 속이는 것: 가짜 도메인을 위한 동형이자, 가짜 파일 …
confusables.txt(UCD)에 정의된 시각적으로 혼동될 수 있는 문자 쌍에 대한 유니코드 공식 용어. …
서로 다른 문자 체계의 문자를 혼합하는 텍스트를 식별합니다(예: 라틴 + 키릴). 동형이자 …