Chromium IDN 스푸핑 방어, 설득력 있는 유사 도메인을 놓치다

기만적인 Unicode 주소를 드러내기 위해 수년간 마련된 보호 장치에도 불구하고, Chromium의 IDN 스푸핑 방어는 등록된 유사 도메인 20개를 놓쳤다. 개념 증명용 도메인 하나는 xn--로 시작하는 눈에 띄는 Punycode 형식이 아니라 읽기 쉬운 Unicode 형태로 표시되면서 apple.com과 매우 흡사했다.

이 발견이 공격자가 Apple의 도메인을 등록했거나 그 인프라를 침해했다는 뜻은 아니다. Have I Been Squatted(HIBS)의 연구진은 “apple”의 라틴 문자와 닮은 키릴 문자를 사용하는 별도의 도메인을 등록했다. 이들의 테스트는 신중하게 선택한 문자가 Chromium의 표시 규칙과 별도의 탐색 시점 방어를 통과할 수 있음을 보여준다.

이 결과는 국제화 도메인 이름이 널리 사용되기 시작한 이래 브라우저가 관리해 온 충돌을 다시 부각한다. 웹에는 사람들이 실제로 사용하는 언어로 작성된 주소가 필요하다. 하지만 같은 문자 다양성은 공격자에게 신뢰받는 브랜드, ID 제공업체, 결제 서비스를 모방할 더 많은 방법을 제공한다.

Chromium은 이미 업계에서 가장 상세한 방어 시스템 중 하나를 적용하고 있다. 스크립트, 의심스러운 문자 조합, 알려진 도메인, 탐색 기록을 점검한다. 새 사례가 이러한 보호를 무효화하는 것은 아니다. 대신 각각 조금씩 다른 판단을 내리는 여러 계층 사이로 몇몇 문자가 빠져나갈 수 있음을 보여준다.

연구진이 발견한 새로운 Chromium IDN 스푸핑 엣지 케이스

중요한 변화는 잊힌 공격 기법의 재등장이 아니라, 현재 Chromium 검사도 설득력 있는 새로운 변형을 여전히 허용한다는 증거다.

HIBS 연구진 Ian Muscat과 Leanne Briffa는 2026년 10월 3일 분석 결과를 공개했다. 이들은 국제화 도메인이 Chromium 기반 브라우저에서 Unicode로 표시된 상태로 유명한 라틴 문자 주소를 닮을 수 있는지 조사했다.

국제화 도메인 이름(IDN)은 기본 영문 알파벳을 벗어나는 문자를 포함한다. 애플리케이션은 DNS 요청을 보내기 전에 이러한 문자를 Punycode라는 ASCII 호환 표현으로 변환한다. 따라서 xn--로 시작하는 도메인이 자동으로 위험한 것은 아니다. 이는 기존 도메인 이름 시스템에 필요한 인코딩 형태다.

브라우저는 표시를 위해 이 인코딩 형태를 읽기 쉬운 Unicode로 다시 변환하는 경우가 많다. 이는 아랍어, 키릴 문자, 중국어 및 여러 다른 문자 체계의 합법적인 주소를 지원한다. 보안 문제는 서로 다른 문자가 거의 같은 모양을 공유할 때 나타난다.

연구진은 일반적인 글꼴에서 apple.com과 비슷하게 보일 수 있는 аррӏө.com에 주목했다. 이 도메인의 문자는 키릴 문자이며, 라틴 “a” 모양의 문자, 두 개의 “p” 문자, 그리고 “l” 모양의 문자를 포함한다. 마지막 키릴 문자 ө는 주소창 크기로 표시될 때 둥근 “e”와 유사해 보인다.

이 주소는 apple.com이 아니다. 인코딩된 형태는 xn--80a6aa68c8d.com이며, DNS는 이를 별개의 이름으로 처리한다. 그러나 읽기 쉬운 버전은 방문자가 Apple의 도메인에 접속했다는 시각적 인상을 만들 수 있다.

HIBS는 이 도메인과 추가 유사 도메인 19개를 개념 증명으로 등록했다. 목록은 OpenAI, Skype, SharePoint, SpaceX, Shell, Xerox, Kaspersky, Okta, Nike 및 다른 잘 알려진 조직과 연관된 이름을 모방했다.

원본 IDN 연구에 따르면 Chrome 154는 유효한 인증서와 함께 Apple 유사 도메인을 Unicode로 표시했다. 또한 연구진이 평가한 탐색 검사를 통과했으며 유사 도메인 경고를 표시하지 않았다.

유효한 인증서가 도메인이 닮은 브랜드에 속한다는 사실을 증명하지는 않는다. 이는 브라우저가 해당 인증서에 명시된 도메인과 암호화된 연결을 수립했음을 확인할 뿐이다. 공격자는 기만적인 도메인을 포함해 자신이 합법적으로 제어하는 도메인에 대한 인증서를 받을 수 있다.

이 사례들은 통제된 등록으로, 언급된 모든 기업의 고객을 겨냥한 캠페인의 증거는 아니다. 기술적으로 가능한 스푸핑이 자동으로 진행 중인 피싱 작전을 의미하지는 않기 때문에 이 구분은 중요하다.

그럼에도 기술적 실현 가능성 자체가 이 발견의 핵심이다. 기만적인 도메인은 실제 웹사이트, HTTPS, 이메일, 리디렉션 및 기타 일반적인 인터넷 서비스를 지원할 수 있다. 공격자는 시각적 유사성에 검색 광고, 사기성 이메일, QR 코드, 단축 링크 또는 복제 로그인 페이지를 결합할 수 있다.

이 연구는 10월 18일 더 폭넓은 보도에서 다뤄졌으며, 타이포스쿼팅 조사는 키릴 문자 대체가 Chromium의 규칙을 통과한 방식을 자세히 설명했다. 이 시점은 브라우저가 의심스러운 항목을 감지하지 않는 한 많은 사용자가 보지 못하는 방어 기능에 다시 주목하게 한다.

이는 이 글의 핵심 긴장을 만든다. Chromium은 기만적인 시각적 대체와 수백만 명이 사용하는 합법적인 단어를 구별해야 한다. 모든 유사성을 포착할 만큼 광범위한 규칙은 평범한 국제 주소도 읽고 신뢰하기 어렵게 만들 수 있다.

Chromium Unicode 유사 문자가 여러 검사를 통과하는 방식

Apple 유사 도메인이 살아남는 이유는 사용자에게 전달되는 전체 시각적 인상을 단일 Chromium 규칙이 평가하지 않기 때문이다.

Chromium은 단순히 도메인에 Unicode가 포함됐는지 묻지 않는다. 읽기 쉬운 문자를 표시할지, 아니면 내부 Punycode 레이블을 표시할지 결정하기 전에 IDN을 여러 테스트로 처리한다.

첫 번째 주요 계층은 Unicode용 국제 구성 요소 스푸핑 검사기를 사용한다. Chromium은 이를 “Highly Restrictive” 수준으로 구성하며, 이는 의심스러운 문자 체계 조합을 제한한다.

라틴 문자 사이에 키릴 문자 하나를 포함한 혼합 레이블은 일반적으로 이 테스트를 통과하지 못한다. 예를 들어 apple.com에서 첫 번째 “a”만 바꾸면 Chromium은 xn--pple-43d.com을 표시한다. 인코딩된 주소는 원본으로 오인될 가능성이 훨씬 낮다.

새 Apple 유사 도메인은 .com 앞의 모든 문자가 키릴 문자이므로 이 결과를 피한다. 이는 라틴 문자와 키릴 문자가 명백히 섞인 경우가 아니라 단일 문자 체계 레이블이다.

Chromium은 허용 문자 집합도 유지한다. 위험하거나 혼동을 유발할 수 있는 표시에 연관된 여러 Unicode 블록과 개별 코드 포인트를 제외한다. аррӏө.com의 문자는 실제 언어에서 사용되는 합법적인 글자이기 때문에 일부 이유로 여전히 허용된다.

이후 여러 표적 검사가 뒤따른다. Chromium은 관련 국가 도메인 외에서 아이슬란드어 thorn과 eth를 제한한다. 아제르바이잔어 schwa를 제한하고 카탈루냐어 가운데점에는 특정 규칙을 적용한다. 이러한 제한 가운데 어느 것도 개념 증명의 키릴 문자 시퀀스를 다루지 않는다.

가장 관련성 높은 방어는 Chromium의 전체 문자 체계 혼동 가능성 검사다. 이는 모두 라틴 문자와 닮은 키릴 문자로만 작성된 레이블을 찾는다.

Chromium은 널리 논의된 2017년 시연 이후 이 보호 기능을 도입했다. 보안 연구원 Xudong Zheng은 브라우저가 실제 주소의 매우 유사한 시각적 복사본으로 표시한 apple.com의 전체 키릴 문자 버전을 등록했다.

Chromium은 Chrome 58에서 대응했다. 전체 문자 체계 검사는 라틴 문자와 닮은 키릴 문자 29개 집합을 식별한다. 단일 문자 체계 레이블의 모든 글자가 이 집합에 속하면 Chromium은 도메인을 Punycode로 표시할 수 있다.

이 방어는 2017년 버전을 포착한다. 그러나 ө는 나열된 29개 문자에 포함되지 않으므로 새 변형은 포착하지 못한다. 전체 레이블이 여전히 “apple”과 닮았더라도, 집합 밖의 문자 하나가 전체 문자 체계 조건을 해제한다.

브라우저는 이 문자가 만들어진 기호가 아니므로 어딘가에서는 허용해야 한다. 키릴 문자 ө는 카자흐어, 몽골어, 타타르어 및 다른 언어에서 사용된다. 이를 모든 곳에서 차단하면 합법적인 사용자에게 사용성 부담을 줄 수 있다.

그다음 Chromium은 보호 대상 도메인에 대해 스켈레톤 비교를 사용한다. 스켈레톤은 시각적으로 연관된 문자를 정규화된 표현으로 축소해 소프트웨어가 알려진 이름과 비교할 수 있게 한다.

이 과정은 유용하지만 사람의 시각을 완벽하게 재현할 수는 없다. 이 사례에서 ө를 가로지르는 막대는 정규화 후에도 남는다. 그 결과 스켈레톤은 예상되는 라틴 “e”가 아니라 결합 표시가 더해진 “o” 기반 형태로 끝난다.

작은 표시 하나의 차이로 apple.com의 스켈레톤과 정확히 일치하지 않게 된다. 그 표시는 작은 브라우저 인터페이스에서 보기 어려워질 수 있어도 계산상의 결과를 바꾸기에 충분하다.

라틴 문자 사례는 관련된 약점을 드러낸다. 연구진은 ƙ처럼 갈고리가 있는 라틴 문자를 사용해 Okta와 Nike를 포함한 이름의 “k”를 모방했다. 악센트가 있는 라틴 문자 도메인은 흔하고 합법적이므로 Chromium은 라틴 문자에 광범위한 전체 문자 체계 경고를 적용할 수 없다.

대신 Chromium은 주요 도메인의 묶음 목록에 더 강한 스켈레톤 보호를 제공한다. HIBS는 이 목록에서 상위 우선순위 그룹의 836개를 포함해 8,462개 이름을 발견했다. 그러나 추가 표시를 보존하는 문자는 정확한 스켈레톤 일치를 막을 수 있다.

Chromium 표시 지침은 근본적인 균형을 인정한다. Chrome은 IDN 표시 규칙이 동형 문자 위험을 식별하면 Punycode를 표시하지만, ASCII가 아닌 모든 주소를 적대적인 것으로 취급하지는 않는다.

이 균형은 Chromium IDN 스푸핑을 단순한 차단 목록 문제가 아닌 분류 문제로 만든다. 새 규칙은 합법적인 국제 이름을 읽기 어려운 인코딩 문자열로 바꾸지 않으면서 악의적인 유사성을 포착해야 한다.

브라우저 경고는 제한이 있는 두 번째 방어선이다

Unicode로 표시되는 도메인도 탐색 검사를 거치지만, 이러한 검사는 정확한 비교, 이름 길이, 방문자의 기록에 의존한다.

Chromium은 주소 표시와 탐색 시점 보호를 분리한다. 첫 번째 시스템은 주소창에서 호스트 이름이 보이는 방식을 결정한다. 두 번째 시스템은 사용자가 이동한 후 방문을 중단시키거나 주석을 표시할 수 있다.

Chromium의 유사 도메인 탐색 구성 요소는 방문한 주소를 인기 도메인 및 사용자가 정기적으로 방문하는 사이트와 비교한다. 일치 유형에 따라 Chrome은 전체 페이지 인터스티셜 또는 덜 방해적인 Safety Tip을 표시할 수 있다.

유사 도메인 경고 설계는 이러한 검사를 Google Safe Browsing과 별개인 추가 계층으로 설명한다. 인기와 사용자의 이전 이용 기록은 브라우저가 의심스러운 대안을 식별하는 기준점을 제공한다.

HIBS는 우선순위가 가장 높은 836개 도메인 중 하나와 정확한 스켈레톤 일치가 발생하면 인터스티셜이 표시된다고 보고했다. 다른 묶음 도메인과 정확히 일치하면 Safety Tip이 표시될 수 있다.

브라우저는 사용자가 충분한 빈도로 방문하는 사이트도 고려한다. 새 주소가 그러한 자주 방문한 사이트 중 하나와 정확히 닮았다면, Chromium은 탐색을 차단하고 방문자가 익숙한 도메인을 열려 했는지 물을 수 있다.

근접 일치는 더 제한적으로 처리된다. Chromium은 문자 하나가 삽입, 삭제 또는 교체된 스켈레톤을 감지할 수 있다. 인접한 문자 사이에서 한 번의 순서 교환도 인식할 수 있다.

이 비교는 균일하게 적용되지 않는다. 연구에 따르면 근접 일치 테스트는 최상위 도메인 앞의 대상 레이블이 다섯 글자보다 짧으면 건너뛴다. 이는 짧은 이름을 가진 브랜드에 중요하다.

ƙ를 사용하는 Okta 유사 도메인은 실제 이름에서 한 번의 수정 거리만큼 떨어져 있지만, “okta”는 네 글자다. 연구진은 이 때문에 관련 근접 일치 검사에는 너무 짧다고 설명한다.

Apple 사례는 다른 이유로 실패합니다. ө가 “o”와 유지되는 막대로 정규화되기 때문에, 그 스켈레톤은 apple.com과 두 번의 편집 차이에 있습니다. 유사 일치 비교는 한 번의 편집만 허용합니다.

그 결과 테스트된 도메인은 유니코드로 표시되었고, 유사 도메인 경고 없이 로드되었습니다. HIBS는 실제 Apple 웹사이트를 정기적으로 방문한 사용자에게도 이 결과가 동일했다고 말합니다.

이러한 결과를 방문을 둘러싼 모든 보호 장치에 대한 완전한 감사로 해석해서는 안 됩니다. Safe Browsing, 위협 인텔리전스 피드, 엔드포인트 소프트웨어, DNS 필터링, 이메일 게이트웨이, 평판 서비스는 여전히 악성 도메인을 탐지할 수 있습니다.

HIBS는 원격 허용 목록, 평판 검사, 특정 리디렉션 동작을 비롯한 일부 변수를 평가에서 제외했습니다. 따라서 무기화된 사이트는 개념 증명이 시험하지 않은 다른 방어 체계와 마주할 수 있습니다.

반대 상황도 마찬가지입니다. 새로 생성된 피싱 도메인에는 처음에는 평판 데이터가 거의 없을 수 있습니다. 공격자는 자동화 시스템이 해당 인프라를 분류하거나 방어자가 차단을 완료하기 전의 이 기간을 흔히 악용합니다.

이 때문에 여러 안전장치가 존재하더라도 이 엣지 케이스는 중요합니다. 계층형 보안은 실패가 서로 독립적일 때 가장 효과적입니다. 여기서는 여러 검사가 밀접하게 관련된 스켈레톤 표현과 도메인 목록에 의존하므로, 신중하게 선택한 문자 하나가 둘 이상의 판단에 영향을 줄 수 있습니다.

기록 기반 보호는 두 사용자가 서로 다른 처리를 받을 수 있음을 의미하기도 합니다. 보호되는 서비스를 정기적으로 방문한 사용자의 경우 브라우저에는 비교할 알려진 도메인이 있습니다. 처음 방문하는 사용자는 내장된 인기 도메인 목록만 보유할 수 있습니다.

이 차이는 채용 사이트, 지역 은행, 비즈니스 소프트웨어, 공급업체 포털에서 특히 중요합니다. 직원은 한 번도 방문한 적 없는 서비스 링크를 받을 수 있으며, 이 경우 브라우저에는 비교할 개인 방문 기록이 더 적습니다.

가장 안전한 결론은 Chromium이 아무런 보호 기능도 제공하지 않는다는 것이 아닙니다. Chromium의 규칙은 많은 일반적인 문자 대체를 사용자에게 도달하기 전에 차단합니다. 교훈은 주소 표시줄의 외관과 경고가 없다는 사실만으로는 진위를 판단할 수 없다는 것입니다.

IDN 동형 문자 공격은 주소 표시줄을 넘어 확장된다

브라우저는 하나의 표시 표면일 뿐이며, 기만적인 도메인은 이메일, 메시징 애플리케이션, 문서, 검색 결과를 통해 사용자에게 도달할 수 있다.

IDN 동형 문자 공격은 다른 식별자를 사칭하기 위해 서로 비슷하게 보이는 서로 다른 문자를 사용합니다. 타이포스쿼팅은 단순한 철자 오류와 시각적으로 기만적인 문자를 포함해, 합법적 도메인과 혼동하기 쉬운 대안을 등록하는 더 넓은 관행입니다.

새 연구는 이 두 범주가 겹치는 지점에 놓여 있습니다. 해당 도메인은 일반적인 키보드 입력 오류는 아니지만, 시각적 유사성으로 빠른 읽기, 작은 화면, 익숙한 브랜드 형태를 악용할 수 있습니다.

이메일은 특히 까다로운 인계 지점을 만듭니다. Chromium의 주소 규칙은 브라우저 인터페이스가 렌더링하는 호스트명을 보호합니다. 하지만 웹메일 애플리케이션이 메시지 헤더 안에 배치하는 유니코드 텍스트까지 자동으로 관리하지는 않습니다.

HIBS는 웹용 Gmail과 Outlook에서 국제화된 발신자 도메인 20개를 테스트했습니다. 연구진은 Chromium 주소 표시줄이라면 Punycode로 표시했을 도메인을 포함해 Gmail이 20개 모두를 유니코드로 표시했다고 보고합니다.

테스트에 따르면 Gmail은 인코딩된 형식을 별도의 mailed-by 필드에 유지했습니다. 대부분의 수신자는 기술적인 전송 정보를 펼쳐 보기보다 눈에 잘 띄는 발신자 줄을 확인할 가능성이 높습니다.

연구진의 테스트에서 웹용 Outlook은 반대 방식을 취했습니다. café.com 및 zürich.com 같은 일반적인 국제 도메인을 포함해 발신자 도메인 20개 모두를 ASCII 호환 레이블로 표시했습니다.

어느 방식도 근본적인 절충을 완전히 해결하지는 못합니다. 모든 항목을 디코딩하면 사용자는 읽기 쉬운 국제 주소를 볼 수 있지만 시각적 모호성은 유지됩니다. 모든 항목을 인코딩하면 차이가 드러나지만, 정당한 다국어 주소는 낯설고 해석하기 어려워집니다.

메시징 애플리케이션과 문서도 같은 간극을 만들 수 있습니다. 플랫폼은 브라우저가 선택된 목적지를 받기 전에 유니코드 링크를 일반 텍스트로 렌더링할 수 있습니다. 사용자는 하나의 표시를 평가한 뒤 다른 보안 시스템을 통해 이동합니다.

검색 결과와 광고도 또 다른 경로를 추가합니다. 기만적인 도메인은 익숙한 브랜딩과 복제된 페이지 제목 옆에 나타날 수 있습니다. 주소가 약간 다르더라도 주변 맥락은 사용자가 시각적 패턴을 완성하도록 유도할 수 있습니다.

QR 코드는 스캔이 발생할 때까지 보이는 목적지를 거의 완전히 제거합니다. 모바일 브라우저는 호스트명을 표시할 공간도 더 적으며, 인터페이스는 전체 주소보다 페이지 제목을 더 강조할 수 있습니다.

Unicode Consortium은 혼동 가능 IDN에 대한 여러 방어책을 권고합니다. 여기에는 허용 문자 집합 제한, 위험한 스크립트 혼용 방지, 문맥상 언어 제약 적용, 기존 레이블과 유사한 등록 차단이 포함됩니다.

IDN 보안 지침은 중요한 단서도 강조합니다. Unicode 혼동 문자는 피싱의 극히 일부에 불과합니다. secure-brand-login.com 같은 단순한 도메인이 여전히 더 흔하며, 특이한 문자가 필요하지도 않습니다.

이러한 맥락은 새 발견이 Unicode가 온라인 사기의 대부분을 만들었다는 주장으로 번지는 것을 막습니다. 공격자는 대개 효과가 있는 가장 저렴한 방법을 선택합니다. 친숙한 단어, 오해를 부르는 하위 도메인, 탈취된 계정, 침해된 합법 사이트는 정교한 IDN을 구성하는 것보다 더 쉬울 수 있습니다.

그러나 낮은 발생 빈도가 고가치 표적의 위험을 없애지는 않습니다. ID 플랫폼, 금융 서비스, 클라우드 콘솔, 직원 포털은 공격자에게 가치 있는 자격 증명을 제공합니다. 시각적으로 강력한 사칭은 추가 노력을 들일 가치가 있을 수 있습니다.

국제화 자체가 결함은 아닙니다. 인터넷은 기본 라틴 알파벳 밖의 문자로 작성된 이름을 지원해야 합니다. 모든 그런 주소를 적대적인 것으로 취급하면 정당한 사용자와 기업에 부담이 전가됩니다.

해결되지 않은 문제는 각 방어 체계가 어디에서 작동해야 하는지입니다. 브라우저는 표시와 탐색 경고를 제어합니다. 레지스트리는 등록 가능한 레이블을 제어합니다. 이메일 서비스는 발신자 표시를 제어합니다. 브랜드 소유자는 의심스러운 등록을 모니터링하고, 보안팀은 이를 필터링하고 조사합니다.

어떤 참여자도 전체 공격 경로를 보지는 못합니다. 이러한 분절화 때문에 한 인터페이스에서 거부된 도메인이 다른 인터페이스에서는 설득력 있게 보일 수 있습니다.

레지스트리는 Chromium IDN 스푸핑을 브라우저에만 맡길 수 없다

가장 지속적인 방어는 탐색 전에 시작되지만, 레지스트리 정책은 언어와 최상위 도메인에 따라 여전히 분절되어 있다.

레지스트리가 등록을 허용하지 않는 한 도메인은 독립적인 웹사이트나 사서함을 지원할 수 없습니다. 따라서 레지스트리 통제는 브라우저가 표시 방법을 판단하기 전에 기만적인 이름을 차단할 수 있습니다.

국제화 도메인 정책은 흔히 IDN 테이블을 사용합니다. 이 테이블은 최상위 도메인이 허용하는 Unicode 문자와 특별한 처리가 필요한 조합 또는 변형을 정의합니다.

Unicode Consortium은 혼동 가능한 레이블을 묶거나 차단할 것을 권고합니다. 묶기는 관련 변형을 같은 등록자에게 할당합니다. 차단은 하나의 레이블은 존재하도록 허용하면서 혼동하기 쉬운 대안의 등록은 막습니다.

ICANN의 IDN 구현 가이드라인은 사이버스쿼팅과 소비자 혼동을 줄이기 위한 일반적 기대치를 정합니다. 실제 정책은 서로 다른 레지스트리가 각기 다른 언어, 스크립트, 지역 요구사항을 지원하기 때문에 여전히 다릅니다.

.com 레지스트리는 HIBS의 개념 증명 등록을 허용했습니다. 그렇다고 .com이 모든 Unicode 시퀀스를 허용한다는 뜻은 아닙니다. 테스트된 문자와 조합이 적용되는 등록 규칙에 부합했다는 뜻입니다.

HIBS는 2026년 10월 ICANN의 Centralized Zone Data Service를 통해 확보한 .com 존 파일도 분석했습니다. 연구진은 위임된 .com 이름 167,226,216개를 집계했으며, 이 중 733,509개가 IDN 형식으로 표현되었습니다.

이들의 방법론은 IDN을 시각적으로 유사한 위임된 ASCII 도메인과 연결했습니다. 그 결과 133,953개의 고유 ASCII 이름을 포괄하는 161,894개의 유사 도메인 쌍이 산출되었습니다.

이 수치는 악성 도메인의 개수가 아닙니다. 연구진은 시각적 쌍이 방어 목적의 등록, 다국어 웹사이트 또는 무관한 조직을 나타낼 수 있다고 명시적으로 경고합니다.

이 구분은 필수적입니다. 악센트 문자가 포함된 도메인은 우연히 ASCII 이름과 유사할 수 있습니다. 소유권, 콘텐츠, DNS 동작, 인증서, 이메일 구성, 리디렉션은 악의적 의도를 보여 주는 더 강력한 증거를 제공합니다.

그럼에도 이 규모는 브라우저 목록이 모든 관련 표적을 열거할 수 없는 이유를 보여 줍니다. Chromium의 내장 보호 기능은 수천 개의 주요 이름을 포괄하는 반면, .com 존에는 사칭의 표적이 될 수 있는 수백만 개의 기업과 조직이 있습니다.

소규모 기업은 특히 노출될 수 있습니다. 이들의 도메인은 전 세계 인기 목록에 포함될 가능성이 낮지만, 고객은 회사 이름이 포함된 청구서, 공급업체 포털, 비밀번호 재설정 메시지를 신뢰할 수 있습니다.

레지스트리는 새로 식별된 문자를 특정 문맥에서 금지하는 방식으로 대응할 수 있습니다. 이 접근법은 하나의 엣지 케이스를 막을 수 있지만, 해당 문자에 의존하는 유효한 단어와 공동체까지 배제할 수 있습니다.

더 정밀한 정책은 언어별 관계에 따라 변형을 정의할 수 있습니다. 하지만 시각적 유사성은 글꼴, 크기, 인접한 문자, 독자의 친숙도에 따라 달라집니다. 영어 사용자에게 명백한 시퀀스가 다른 언어에서는 정당한 단어일 수 있습니다.

방어적 등록은 또 다른 선택지입니다. 브랜드는 유력한 변형을 등록하고 이를 실제 도메인으로 리디렉션할 수 있습니다. Chromium의 탐색 코드는 일부 안전한 리디렉션을 인식하므로 실제 조직이 관리하는 변형에 대한 경고를 피하는 데 도움이 됩니다.

이 전략은 완벽하게 확장되지 않습니다. Unicode에는 수많은 잠재적 대체 문자가 있으며, 등록 정책은 최상위 도메인마다 달라집니다. 상상할 수 있는 모든 유사 도메인을 구매하려면 지속적인 비용이 들고, 그래도 빈틈은 남습니다.

모니터링은 더 넓은 범위를 제공합니다. 보안팀은 중요한 도메인과 유사한 이름에 대해 신규 등록, 인증서 발급, DNS 변경, 호스팅 동작을 감시할 수 있습니다. 조기 탐지는 공격이 많은 사용자에게 도달하기 전에 차단 요청과 블록을 지원합니다.

조직은 브라우저 밖의 고위험 워크플로도 보호해야 합니다. 비밀번호 관리자는 정확한 오리진에 자격 증명을 일치시키므로 유사 도메인에서 자동 입력할 가능성이 낮습니다. 패스키는 인증을 합법적 사이트의 도메인에 바인딩하며, 일반적인 자격 증명 피싱에 저항합니다.

결제나 계정 복구를 처리하는 직원에게는 링크의 외관에 의존하지 않는 검증 경로가 필요합니다. 알려진 북마크, 관리형 애플리케이션 포털, 독립적으로 확인된 연락 채널은 시각적 도메인 인식에 대한 의존도를 낮춥니다.

이 조치는 Chromium Unicode 유사 도메인 이상의 문제를 해결합니다. 일반적인 철자 오류, 오해를 부르는 하위 도메인, 침해된 사서함, 복제된 로그인 페이지에도 도움이 됩니다.

따라서 압력은 여러 당사자에게 동시에 가해집니다. Chromium은 휴리스틱을 개선해야 합니다. 레지스트리는 더 강력한 변형 정책이 필요합니다. 메일 제공업체는 더 명확한 발신자 표시가 필요합니다. 조직에는 사용자가 때때로 주소를 잘못 읽을 것이라는 전제의 통제가 필요합니다.

다음 전개가 이 간극이 정말 닫히는지를 보여줄 것이다

이 연구가 지속적인 방어로 이어질지, 아니면 패치된 유사 도메인의 역사에 또 하나의 항목만 더할지는 세 가지 신호가 결정할 것이다.

첫 번째 신호는 Chromium 규칙 변경입니다. 가장 명확한 대응은 키릴 문자 ө, 라틴 문자 ƙ, 또는 목록에 없는 문자 하나가 전체 스크립트 평가를 우회하도록 하는 분기 로직을 해결하는 것입니다.

문자 두 개만 추가해도 공개된 사례는 막을 수 있습니다. 하지만 그것이 구조적 문제를 반드시 해결하는 것은 아닙니다. 눈에 보이는 표식이나 특이한 스켈레톤 매핑을 가진 다른 문자가 같은 결과를 재현할 수 있습니다.

더 광범위한 해결책으로는 추가적인 스켈레톤 변환을 통해 렌더링된 인상을 비교할 수 있다. 그러나 비교 기준을 느슨하게 하면, 특히 정당한 국제 이름에서 오탐이 늘어난다.

Chromium의 공개 코드와 테스트는 이 과정을 관찰할 수 있게 한다. 보안 연구자들은 패치가 영향을 받는 언어의 일반적인 도메인을 유지하면서 등록된 개념 증명을 차단하는지 검토할 수 있다.

두 번째 신호는 레지스트리의 조치다. 업데이트된 IDN 테이블은 특정 맥락에서 이 문자들을 변형 문자로 분류하거나, 확립된 ASCII 레이블을 모방하는 등록을 막을 수 있다.

레지스트리의 조치는 표시 차이가 발생하기 전에 기만적인 이름을 차단하므로, 이 글의 핵심 판단을 강화할 것이다. 브라우저 전용 패치만으로는 서로 다른 렌더링 규칙을 사용하는 이메일 클라이언트와 기타 애플리케이션에서 해당 도메인을 계속 사용할 수 있게 된다.

세 번째 신호는 메일 표시 방식의 변화다. HIBS는 Gmail이 테스트한 모든 발신자 도메인을 디코딩한 반면, Outlook은 인코딩된 레이블을 표시했다는 사실을 확인했다. 향후 인터페이스 변경으로 두 형식을 모두 노출하거나, 혼합된 시각적 정체성을 표시하거나, 발신자가 알려진 도메인과 유사할 때 경고할 수 있다.

이 신호가 중요한 이유는 이메일이 여전히 자격 증명 탈취와 결제 사기의 자연스러운 전달 수단이기 때문이다. Chromium 패치로는 웹 애플리케이션 안에서 텍스트로 렌더링된 기만적인 발신자 이름을 보호할 수 없다.

연구자들은 업데이트 이후에도 결과를 다시 검증해야 한다. 원래 연구는 특정 시점의 브라우저 동작, 등록된 이름, 테스트 메일함을 살펴봤다. 모든 Chromium 빌드, 운영체제, 글꼴 또는 메일 애플리케이션이 문자를 동일하게 렌더링한다는 사실을 입증하지는 않았다.

글꼴 차이는 착시를 약화하거나 강화할 수 있다. 더 큰 크기에서는 ө를 가로지르는 막대가 더 쉽게 눈에 띈다. 좁은 주소 표시줄이나 발신자 필드 안에서는 그 차이가 덜 분명해질 수 있다.

보고된 등록 사례 역시 광범위한 악용이 아니라 가능성을 입증한다. 정확히 이 문자들을 사용하는 피싱 캠페인에 관한 공개 증거가 나온다면 긴급성은 높아질 것이다. 그러한 보고가 없다고 해서 이 허점이 무해하다는 뜻은 아니지만, 위험 우선순위에는 영향을 미칠 것이다.

사용자에게 당장의 교훈은 “Unicode를 절대 신뢰하지 말라”보다 더 좁다. 특히 자격 증명, 결제 또는 계정 복구와 관련된 예상치 못한 요청은 알려진 경로를 통해 확인해야 한다. 북마크나 비밀번호 관리자는 시각적 확인만으로 판단하는 것보다 더 나은 기준을 제공한다.

관리자는 가장 중요한 도메인을 목록화하고, 이들과 유사한 등록을 모니터링해야 한다. 민감한 시스템에는 피싱에 강한 인증을 요구해야 한다. 새로운 공급업체 또는 결제 정보는 일상적인 이메일 업무가 아니라 검증이 필요한 사건으로 취급해야 한다.

제품 팀은 애플리케이션이 국제화된 발신자 주소와 링크를 어떻게 표시하는지 테스트해야 한다. 인코딩된 형식에 접근할 수 없고 친숙한 Unicode 이름만 보여 주는 방식은 유용한 증거를 숨길 수 있다. Punycode만 표시하는 방식은 정당한 국제적 정체성을 불필요하게 불친절하게 만들 수 있다.

Chromium의 IDN 스푸핑 방어는 여전히 상당하지만, 이 연구는 상당하다고 해서 완전한 것은 아니라는 점을 보여 준다. 브라우저는 명백한 혼합 스크립트 대체와 알려진 전체 스크립트 기법을 차단한 뒤, 탐색 중 인기 있고 익숙한 목적지를 확인한다.

신중하게 선택한 문자는 급하게 판단하는 사람이 받는 인상을 바꾸지 않으면서도 기계 비교 결과는 바꿀 수 있다. 이 격차는 코드상으로는 작지만, 이름을 인식하는 일이 신뢰에 좌우되는 모든 곳에서 의미가 있다.

앞으로 몇 달 안에 Chromium, 레지스트리, 메일 제공업체가 이 사례들을 목록에 추가할 고립된 사례로 볼지, 아니면 각 계층에 다른 가정이 필요하다는 증거로 볼지가 드러날 것이다. 그때까지 조직은 자체 도메인을 테스트하고, 출처에 결부된 인증을 강화하며, 사용자가 오로지 서체만 보고 보안 결정을 내리도록 요구하는 일을 멈춰야 한다.