Tóm tắt nhanh
- Chromium có thể hiển thị một số tên miền IDN gần giống thương hiệu bằng Unicode thay vì Punycode, do các trường hợp ký tự hiếm lọt qua hai lớp so khớp.
- HIBS đăng ký 20 tên miền làm bằng chứng thử nghiệm; con số 161.894 là các cặp tên .com có khả năng giống nhau, không phải số vụ lừa đảo đã xác nhận.
- Thanh địa chỉ và cảnh báo lúc mở trang là hai kiểm tra riêng. Người dùng doanh nghiệp nên theo dõi tên miền giả, bảo vệ email và dùng passkey cho tài khoản quan trọng.
Một ký tự Cyrillic không nằm trong danh sách ký tự dễ nhầm lẫn của Chromium có thể giúp tên miền bắt chước Apple hiện dưới dạng Unicode trên thanh địa chỉ, thay vì chuỗi Punycode cảnh báo. Nghiên cứu do Ian Muscat và Leanne Briffa đăng trên Have I Been Squatted (HIBS) ngày 3/10/2026 mô tả cách một số trường hợp biên đi qua bước hiển thị; đây là giới hạn cụ thể của cơ chế, không phải bằng chứng rằng mọi tên miền Unicode đều nguy hiểm.
Một ký tự lạ có thể làm bộ lọc toàn-chữ mất tác dụng
Tên miền quốc tế hóa (IDN) cho phép dùng ký tự thuộc nhiều hệ chữ viết. Điều đó giúp tên miền phản ánh cách viết bản địa, nhưng cũng tạo điều kiện để ký tự Cyrillic hoặc Latin có dấu trông gần giống chữ Latin trong tên thương hiệu. Hệ thống vẫn phân biệt chúng là các ký tự khác nhau.
Trình duyệt Chromium, nền tảng của Chrome, Edge và một số trình duyệt khác, chọn giữa dạng Unicode dễ đọc và dạng ASCII mã hóa gọi là Punycode. Quyết định này có hai chặng. Chặng đầu, SafeToDisplayAsUnicode(), kiểm tra từng nhãn tên miền theo bảy quy tắc; chặng sau so sánh dạng rút gọn của toàn hostname với danh sách 8.462 tên miền phổ biến được tích hợp sẵn. Không qua một trong hai chặng thì tên miền được hiển thị bằng Punycode.
Ví dụ nghiên cứu tập trung vào аррӏө.com, dùng các ký tự Cyrillic để mô phỏng apple.com. Ký tự cuối ө trông gần chữ o/e nhưng không có trong danh sách ký tự Cyrillic được Chromium dùng để nhận diện dạng giả mạo toàn-chữ. Quy tắc này chỉ kích hoạt khi mọi ký tự trong nhãn đều thuộc danh sách. Chỉ cần một ký tự nằm ngoài danh sách, phép kiểm tra có thể bỏ qua cả nhãn.
Chặng so khớp hostname cũng không bắt buộc chặn tên đó. Khi tạo “skeleton” để đối chiếu, ө được ánh xạ thành chữ o kèm một dấu ngang kết hợp. Dấu này còn lại sau bước chuẩn hóa, khiến chuỗi không khớp chính xác với apple.com trong danh sách. Kết quả là ví dụ thử nghiệm vượt được cả kiểm tra hiển thị lẫn so khớp tên phổ biến.
HIBS còn ghi nhận một hướng tương tự với ký tự Latin có móc như ƙ: dấu móc tồn tại trong chuỗi so sánh, nên kết quả không trùng hoàn toàn với tên thật. Tuy nhiên, chuyện một địa chỉ trông giống thương hiệu không tự chứng minh chủ sở hữu có ý đồ xấu; tên miền tương tự có thể là đăng ký phòng vệ, trang đa ngôn ngữ hoặc doanh nghiệp không liên quan.
Tên Unicode hiện trên thanh địa chỉ vẫn có thể bị cảnh báo khi mở
Hiển thị Unicode không phải là bước kiểm tra cuối cùng. Khi người dùng mở trang, Chromium còn có cơ chế cảnh báo tương tự tên miền phổ biến, có thể chặn bằng trang trung gian hoặc hiện gợi ý an toàn. Cơ chế này so sánh theo lịch sử truy cập của người dùng và mức độ gần nhau của chuỗi, vì thế kết quả không chỉ phụ thuộc vào nội dung tên miền.
Với аррӏө.com, skeleton cách apple.com hai chỉnh sửa, trong khi bước kiểm tra gần của Chromium xem xét khoảng cách một ký tự hoặc một lần đổi chỗ hai ký tự liền nhau. Một số tên miền ngắn như okta.com còn nằm ngoài kiểm tra gần này vì có dưới năm ký tự trước đuôi miền. Do đó, việc không thấy cảnh báo không thể được hiểu là địa chỉ đã được xác minh an toàn.
Đây là điểm người dùng dễ bỏ sót nhất: thanh địa chỉ trả lời câu hỏi “trình duyệt có thể hiển thị tên này dưới dạng chữ thường không?”, còn cảnh báo điều hướng cân nhắc tên đang mở có giống website người dùng thường truy cập hay không. Hai cơ chế có tiêu chí riêng, và không cơ chế nào thay thế việc kiểm tra đúng tên miền trước khi nhập mật khẩu.
161.894 cặp tên miền không đồng nghĩa có 161.894 vụ lừa đảo
HIBS phân tích zone file .com lấy qua ICANN CZDS trong tháng 10/2026. Tập dữ liệu có 167.226.216 tên miền đã được ủy quyền, trong đó 733.509 tên ở dạng IDN. Nhóm nghiên cứu thay ký tự phi ASCII bằng ký tự Latin mà chúng trông giống, rồi tìm các tên ASCII tương ứng cũng có trong zone file.
Kết quả là 161.894 cặp có khả năng gây nhầm lẫn, bao gồm 154.567 tên IDN và 133.953 tên ASCII riêng biệt. Đây là phép so hình thức giữa các tên đã đăng ký, không phải thống kê tên miền độc hại, chiến dịch phishing hay nạn nhân. Một số tên có thể do chủ thương hiệu đăng ký để phòng vệ; dữ liệu không xác nhận mục đích của từng chủ sở hữu.
Phân biệt này quan trọng khi diễn giải rủi ro. Con số lớn cho thấy bề mặt có thể bị lợi dụng để giả mạo thương hiệu, nhưng không cho biết bao nhiêu tên đang phục vụ trang lừa đảo hay email độc hại. Muốn xác định một tên cụ thể có nguy hiểm hay không vẫn cần xem nội dung, hạ tầng và hành vi của nó.
Email có thể hiển thị tên người gửi khác với trình duyệt
Trình duyệt kiểm tra hostname trong thanh địa chỉ; giao diện email lại do ứng dụng thư quyết định cách trình bày địa chỉ người gửi. Trong thử nghiệm trên 20 địa chỉ gửi quốc tế hóa do HIBS thiết lập, Gmail hiển thị cả 20 dưới dạng Unicode, còn Outlook Web hiển thị cả 20 bằng A-label/Punycode. Phép thử không đo khả năng lọc thư rác, đánh giá uy tín người gửi hay quét liên kết.
Vì vậy, nhìn thấy một địa chỉ Unicode trong dòng From chưa đủ để kết luận Gmail thiếu các lớp bảo vệ email khác. Nghiên cứu chỉ quan sát cách giao diện hiển thị địa chỉ trong cấu hình thử nghiệm mặc định. Với tổ chức, bộ lọc giả mạo thương hiệu trên cổng thư và chính sách xác thực email vẫn cần được cấu hình riêng; đừng dựa vào một kiểu hiển thị để thay thế chúng.
Doanh nghiệp nên quản lý tên miền giống như một phần của phòng thủ email
Với tổ chức có thương hiệu dễ bị giả mạo, đăng ký phòng vệ một số biến thể Unicode rủi ro cao có thể thu hẹp cơ hội cho đối tượng khác sử dụng chúng. Việc này nên dựa trên danh sách tên miền trọng yếu và đánh giá rủi ro, thay vì cố mua mọi biến thể có thể tưởng tượng được.
Nhóm bảo mật cũng có thể theo dõi các đăng ký IDN mới có dạng Punycode bắt đầu bằng xn--, bật tính năng chống giả mạo tên miền trên cổng email, gắn nhãn thư ngoài tổ chức và đưa tên miền IDN chưa được cho phép vào quy trình rà soát. Các bước này giúp phát hiện tín hiệu đáng chú ý trong DNS, proxy hoặc thư đến; chúng không tự chứng minh một miền là độc hại.
Passkey là một lớp bảo vệ hữu ích cho tài khoản quan trọng vì thông tin xác thực gắn với origin của website. Passkey đăng ký cho tên miền thật sẽ không xác thực trên một tên miền bắt chước khác, kể cả khi địa chỉ trên màn hình trông tương tự. Biện pháp này giảm rủi ro đánh cắp thông tin đăng nhập, nhưng không thay thế quy trình bảo vệ email, giám sát tên miền hay xác minh yêu cầu thanh toán.
Trường hợp HIBS nêu ra cho thấy “hãy nhìn thanh địa chỉ” vẫn là lời khuyên có ích nhưng không đủ để giao toàn bộ trách nhiệm cho người dùng. Trình duyệt phải cân bằng khả năng đọc tên miền bản địa với việc ngăn giả mạo; còn phía tổ chức cần quản lý tên miền thương hiệu và cấu hình các lớp bảo vệ độc lập. Danh sách ký tự và thuật toán có thể thay đổi theo phiên bản trình duyệt, nên kết quả của một thử nghiệm không nên được khái quát thành quy tắc vĩnh viễn.
Nguồn tham khảo: Have I Been Squatted; The Register
