apple.com이 진짜 apple.com이 아닐 수도 있다 — 호모글리프 피싱의 원리
주소창에 apple.com이라고 정확히 찍혀 있는데도 가짜 사이트일 수 있습니다. 눈으로는 절대 구분되지 않는 두 문자가 실제로는 완전히 다른 유니코드 코드포인트를 갖기 때문입니다. 이 가이드는 이 착시가 어떻게 도메인 이름 시스템까지 파고드는지, 그리고 브라우저가 이를 어떻게 막고 있는지 정리합니다.
1. 호모글리프: 다른 문자인데 같아 보인다
라틴 알파벳 소문자 a(U+0061)와 키릴 문자 а(U+0430)는 대부분의 폰트에서 픽셀 단위로 구분이 안 될 정도로 똑같이 생겼습니다. 하지만 컴퓨터 입장에서는 완전히 다른 문자입니다 — 코드포인트가 다르므로 문자열로서 "a" !== "а"입니다. 이렇게 겉모습은 같지만 코드포인트가 다른 문자 쌍을 호모글리프(homoglyph)라고 부릅니다. 키릴 문자 외에도 그리스 문자, 아르메니아 문자 등 여러 문자 체계에 라틴 알파벳과 시각적으로 겹치는 글자가 존재합니다.
2. 도메인 이름도 유니코드를 쓸 수 있다: IDN
원래 DNS(도메인 네임 시스템)는 ASCII 문자만 처리하도록 설계됐습니다. 하지만 한글·일본어·아랍어 등 자국어 도메인에 대한 수요로 IDN(Internationalized Domain Name)이 도입되면서, 도메인 이름에 유니코드 문자를 쓸 수 있게 됐습니다. 이때 실제로 DNS에 저장되는 값은 Punycode(RFC 3492)라는 ASCII 호환 인코딩으로 변환된 문자열입니다 — 예를 들어 키릴 문자가 섞인 도메인은 내부적으로 xn--... 형태로 저장됩니다. 브라우저는 이 Punycode를 다시 원래 유니코드 문자로 디코딩해서 주소창에 보여주는데, 바로 이 디코딩·표시 단계에서 착시가 발생합니다.
3. IDN 호모그래프 공격: apple.com을 흉내 내는 법
а(키릴 문자)를 포함한 "аpple.com"을 도메인으로 등록합니다. DNS에는 xn--pple-43d.com 같은 Punycode로 저장되지만, 브라우저 주소창에는 유니코드로 디코딩되어 "аpple.com"으로 표시됩니다 — 육안으로는 진짜 apple.com과 구분이 불가능합니다. 사용자가 이 가짜 사이트에 로그인 정보를 입력하면 그대로 탈취됩니다.
이런 공격이 이론에 그치지 않고 실제로 발생했기 때문에(수년간 여러 유명 브랜드를 흉내 낸 IDN 호모그래프 도메인이 보안 연구자들에 의해 발견·보고됨), 브라우저 업계는 방어 로직을 도입했습니다.
4. 브라우저는 어떻게 막나
현대 브라우저(Chrome, Firefox, Safari 등)는 도메인 라벨(레이블) 안에 서로 다른 문자 체계가 의심스럽게 섞여 있으면, 디코딩된 유니코드 대신 원래의 Punycode 문자열(xn--...)을 그대로 주소창에 표시합니다. 즉 "аpple.com"처럼 자연스럽게 보이는 대신 "xn--pple-43d.com"이라는 낯선 문자열이 뜨면서 사용자가 뭔가 이상하다고 눈치챌 수 있게 만듭니다. 이 판정은 브라우저마다 세부 휴리스틱이 다르지만, 공통적으로 "한 라벨 안에 신뢰할 수 있는 단일 문자 체계로만 구성되어 있는가"를 기준으로 삼습니다. 일부 도메인 등록기관도 애초에 한 도메인 라벨 안에서 허용하는 문자 체계 조합을 제한합니다.
5. 직접 확인하는 법
브라우저 방어를 100% 신뢰할 수 없거나, 링크 텍스트·이메일 발신자 이름처럼 브라우저 주소창이 아닌 곳에서 의심스러운 문자를 마주칠 때는 유니코드 인스펙터에 붙여넣어 직접 확인할 수 있습니다. 이 도구는 텍스트의 각 문자를 코드포인트(U+XXXX) 단위로 분해해서 보여주므로, "a"처럼 보이는 문자가 실제로 U+0061(라틴)인지 U+0430(키릴)인지 즉시 구분할 수 있습니다. ZWSP(U+200B) 같은 폭 0 문자가 숨어 있는지 확인하는 데도 같은 원리로 쓸 수 있습니다.
자주 묻는 질문
Q. 호모글리프 공격은 한글 도메인에도 적용되나요?
A. 원리적으로는 가능합니다. 다만 한글은 자체 문자 체계가 뚜렷해 라틴 알파벳과 혼동되는 경우가 키릴·그리스 문자만큼 흔치는 않습니다. 오히려 한글 도메인은 숫자 0과 알파벳 O처럼 같은 스크립트 내 혼동 문자를 노리는 방식이 더 흔합니다.
Q. Punycode 표시(xn--...)가 뜨면 무조건 위험한가요?
A. 아닙니다. 정상적인 다국어 도메인(예: 실제 한글 도메인)도 Punycode로 인코딩되어 있으므로, xn--로 시작하는 문자열 자체가 위험 신호는 아닙니다. 다만 브라우저가 "디코딩해서 보여주는 게 안전하지 않다"고 판단해 Punycode 원문을 그대로 노출한 경우라면 각별히 주의해야 합니다.
Q. 이메일 발신자 주소도 같은 방식으로 속일 수 있나요?
A. 네, 이메일 클라이언트가 도메인을 디코딩해 표시하는 경우 동일한 원리로 발신자 도메인을 위장할 수 있습니다. 의심스러운 이메일의 발신 도메인 텍스트를 복사해 유니코드 인스펙터로 코드포인트를 확인하는 것이 확실한 검증 방법입니다.
Q. 이 문제를 근본적으로 막을 방법은 없나요?
A. 완전한 근절은 어렵지만, 브라우저의 Punycode 표시 정책과 등록기관의 문자 체계 제한 정책이 계속 강화되고 있습니다. 사용자 입장에서는 중요한 로그인 페이지일수록 북마크를 이용하거나 직접 타이핑하는 습관이 가장 안전합니다.