UTS #39: Khi Unicode trở thành vũ khí — và cách phòng thủ

Unicode mở ra khả năng hiển thị hàng trăm nghìn ký tự thuộc mọi hệ chữ trên thế giới, nhưng chính sự phong phú đó lại tạo ra lỗ hổng bảo mật tinh vi. Tiêu chuẩn kỹ thuật UTS #39 của Unicode Consortium quy định các cơ chế phát hiện và ngăn chặn những rủi ro này, đặc biệt trong bối cảnh tấn công giả mạo tên miền và định danh ngày càng phổ biến.

Bài viết này tổng hợp những điểm cốt lõi của UTS #39, một tài liệu tham chiếu chuẩn mực được các trình duyệt, hệ thống đăng ký tên miền và nền tảng nhắn tin sử dụng rộng rãi.

Minh họa ví dụ tiếng Ba Tư với ký tự ZWNJ

Vì sao định danh lại là điểm nóng bảo mật?

Định danh (identifier) là chuỗi ký tự dùng để tham chiếu tới một thực thể cụ thể trong một ứng dụng. Địa chỉ URL, tên tài khoản, địa chỉ email hay tên miền đều là định danh. Máy tính phân biệt hai chuỗi khác nhau một cách dễ dàng, nhưng con người thì không — và kẻ tấn công khai thác chính khoảng trống này.

Một kịch bản quen thuộc: người dùng truy cập một trang web trông giống hệt dịch vụ ngân hàng, nhưng thực chất tên miền đã bị thay bằng ký tự Kirin hoặc Hy Lạp có hình dạng gần như trùng khớp với chữ Latin. Đây là dạng tấn công đồng hình (homograph), và UTS #39 ra đời để cung cấp công cụ phát hiện.

Việc chủ động giới hạn ký tự được phép dùng trong định danh là một kỹ thuật bảo mật quan trọng. Việc loại trừ ký tự khỏi định danh không ảnh hưởng đến việc dùng các ký tự đó cho mục đích khác, chẳng hạn như văn bản thông thường trong tài liệu.

Hồ sơ bảo mật cho định danh

UTS #39 định nghĩa nhiều hồ sơ bảo mật (security profile) khác nhau. Hồ sơ chung (General Security Profile) loại bỏ các ký tự hiếm dùng, ký tự đã lỗi thời, ký tự kỹ thuật hoặc ký tự vô hình khỏi tập được phép.

Các thuộc tính chính gồm:

• Identifier_Status: cho biết ký tự được phép (Allowed) hay bị hạn chế (Restricted)
• Identifier_Type: phân loại lý do hạn chế như Not_Character, Deprecated, Default_Ignorable, Limited_Use, Uncommon_Use, Technical

Đáng chú ý, từ Unicode 15.0, hai ký tự điều khiển nối ZWJ và ZWNJ đã bị chuyển sang trạng thái Restricted. Đây là thay đổi gây tranh luận, bởi các ký tự này cần thiết để hiển thị đúng nhiều từ trong tiếng Ả Rập, Hindi, Malayalam hay Sinhala.

Bài toán ký tự nối trong ngữ cảnh hẹp

Thay vì cấm tuyệt đối, UTS #39 cho phép ZWNJ và ZWJ trong những ngữ cảnh giới hạn được định nghĩa bằng biểu thức chính quy, nhằm đảm bảo chúng chỉ xuất hiện khi thực sự tạo ra khác biệt về mặt hiển thị.

Minh họa tiếng Malayalam với ZWNJ

Ba quy tắc chính gồm:

• A1: ZWNJ khi phá vỡ liên kết chữ thảo, ví dụ giữa ký tự có Joining_Type là Left_Joining và Right_Joining
• A2: ZWNJ trong ngữ cảnh liên kết phụ âm (conjunct) của các hệ chữ Ấn Độ
• B: ZWJ trong ngữ cảnh liên kết phụ âm, như trường hợp chữ "Sri Lanka" trong tiếng Sinhala

Ví dụ nổi bật là từ tiếng Ba Tư: không có ZWNJ, cụm ký tự mang nghĩa "tên của"; có ZWNJ chèn giữa, nghĩa chuyển thành "một lá thư". Chỉ một ký tự vô hình mà thay đổi hoàn toàn ngữ nghĩa.

Minh họa tiếng Sinhala với ZWJ

Phát hiện ký tự gây nhầm lẫn

Phần lõi của UTS #39 là cơ chế Confusable Detection dựa trên khái niệm skeleton. Mỗi chuỗi đầu vào được biến đổi qua các bước chuẩn hóa NFD, loại bỏ ký tự mặc định bị bỏ qua, ánh xạ sang ký tự nguyên mẫu (prototype) và sắp xếp lại. Hai chuỗi được coi là xung đột (confusable) nếu skeleton của chúng trùng nhau.

UTS #39 phân biệt ba loại xung đột:

• Single-script confusable: hai chuỗi nhầm lẫn nhưng cùng hệ chữ, ví dụ "ljeto" và "ljeto" trong tiếng Croatia
• Mixed-script confusable: như "paypal" và "pаypаl" với chữ "а" Kirin
• Whole-script confusable: toàn bộ chuỗi thuộc một hệ chữ nhưng bắt chước hệ chữ khác, ví dụ "scope" Latin và "ѕсоре" Kirin

Điểm quan trọng: phép biến đổi bidiSkeleton còn tính đến thuật toán hai chiều (bidi), bởi thứ tự hiển thị trong văn bản RTL có thể khiến hai chuỗi trông giống nhau dù cấu trúc mã điểm khác biệt.

Phát hiện trộn bộ chữ và mức hạn chế

Cơ chế Mixed-Script Detection dựa trên tập hợp script mở rộng của từng ký tự và phép giao. Nếu giao của tất cả các tập là rỗng, chuỗi bị coi là trộn bộ chữ. Ví dụ, chuỗi "〆切" vẫn là đơn bộ chữ vì tập resolved chứa nhiều hệ chữ CJK cùng lúc — một điểm dễ gây hiểu nhầm.

Từ đó, UTS #39 định nghĩa 6 mức hạn chế (Restriction Levels):

• Level 1 — ASCII-Only: chỉ ký tự ASCII
• Level 2 — Single Script: một hệ chữ duy nhất, không có ký tự gây nhầm lẫn
• Level 3 — Highly Restrictive: cho phép một số hệ chữ được khuyến nghị kết hợp
• Level 4 — Moderately Restrictive
• Level 5 — Minimally Restrictive
• Level 6 — Unrestricted

Các mức này được dùng rộng rãi trong chính sách đăng ký tên miền quốc tế (IDN) và hệ thống xác thực tài khoản.

Phát hiện trộn hệ số

Một điểm ít được chú ý nhưng nguy hiểm không kém: trộn hệ số đếm. Unicode có nhiều bộ chữ số thập phân, và chúng có thể bị nhầm lẫn. Chữ số Ả Rập‑Ấn Độ U+0660 (٠) trông gần giống U+06F0 (۰), hay chữ số Bengal U+09EA (৪) dễ bị nhầm với số "8" thông thường.

Thuật toán kiểm tra chỉ cho phép các ký tự có General_Category = Decimal_Number (Nd) và yêu cầu toàn bộ chữ số trong định danh phải thuộc cùng một hệ thống đếm, xác định qua ký tự "số không" tương ứng.

Ý nghĩa thực tiễn với người dùng Việt Nam

Với tiếng Việt, vấn đề trộn bộ chữ ít nghiêm trọng hơn vì chữ Quốc ngữ dùng Latin mở rộng khá nhất quán. Tuy nhiên, rủi ro vẫn hiện hữu ở hai điểm:

• Tên miền giả mạo: các ký tự Latin có dấu hoặc dấu kết hợp có thể bị dùng để bắt chước thương hiệu Việt, đặc biệt khi kết hợp với ký tự Kirin hoặc Hy Lạp
• Tên tài khoản và email: ZWJ/ZWNJ có thể bị chèn vào tên hiển thị trên mạng xã hội, khiến hai tài khoản trông giống hệt nhau nhưng hệ thống lại nhận là khác biệt

Các nền tảng lớn như trình duyệt Chrome, Firefox hay hệ thống DNS đã tích hợp một phần UTS #39. Với các nhà phát triển ứng dụng, việc áp dụng hồ sơ định danh an toàn ngay từ khâu thiết kế — thay vì vá sau khi có sự cố — là cách tiếp cận đúng đắn.

Dữ liệu chuẩn cho các cơ chế này được công bố trong bộ tệp idmod và confusables của Unicode Character Database, cập nhật theo từng phiên bản Unicode. Khi nâng cấp phiên bản Unicode, các hệ thống lưu trữ skeleton cần tính toán lại, bởi kết quả không ổn định giữa các phiên bản.