Beyond Normalization: Khi cách xử lý Unicode khác nhau trở thành điểm yếu của ứng dụng web

Trong một ứng dụng web hiện đại, dữ liệu do người dùng gửi lên hiếm khi đi thẳng tới khâu xử lý, nó có thể được giải mã URL, kiểm tra UTF-8, đi qua Web Application Firewall (WAF), máy chủ web, framework, cơ sở dữ liệu rồi mới được trình duyệt diễn giải để hiển thị. Mỗi lớp có thể dùng thư viện và quy tắc Unicode khác nhau.

Đó là câu hỏi trung tâm trong nghiên cứu “Beyond Normalization: The Expanding Unicode Attack Surface” của Ryan Barnett và Isabella Barnett, trình bày tại Black Hat USA 2026 [1]. Thay vì chỉ bàn về chuẩn hóa ký tự, hai tác giả nhìn vấn đề ở cấp kiến trúc: một quyết định bảo mật sẽ còn giá trị đến đâu nếu lớp bảo vệ và thành phần xử lý phía sau không cùng hiểu dữ liệu?

Điểm đáng chú ý là không nhất thiết phải có một thành phần “xử lý sai”. WAF có thể làm đúng nhiệm vụ theo bộ quy tắc của nó, framework cũng xử lý đúng theo thư viện riêng, nhưng kết quả cuối cùng vẫn khác. Khoảng cách giữa hai cách diễn giải mới là nơi quyết định bảo mật có thể mất hiệu lực.

Hình 1. Một chuỗi Unicode có thể được diễn giải nhiều lần trước khi tới thành phần cuối (Nguồn: Tác giả tổng hợp)

Khi WAF và ứng dụng không nhìn thấy cùng một dữ liệu

WAF được đặt trước ứng dụng để nhận diện các đầu vào có dấu hiệu của SQL Injection, XSS hoặc những mẫu tấn công quen thuộc. Cơ chế này dựa trên một giả định tưởng như hiển nhiên: dữ liệu mà WAF kiểm tra phải có cùng ý nghĩa với dữ liệu mà ứng dụng sử dụng.

Với Unicode, giả định đó có lúc không còn đúng. Một chuỗi có thể không khớp mẫu nguy hiểm tại WAF, nhưng sau khi framework chuẩn hóa, giải mã hoặc thay thế ký tự, biểu diễn của nó thay đổi. Nếu trình duyệt hoặc thành phần cuối tiếp tục diễn giải theo cách khác, nội dung đã được cho qua ở lớp đầu có thể mang ý nghĩa mà lớp bảo vệ chưa từng kiểm tra.

Nghiên cứu tại Black Hat cho thấy sai khác có thể xuất hiện ở nhiều khâu, từ giải mã và chuẩn hóa Unicode đến cách trình duyệt hay cơ sở dữ liệu so sánh ký tự [1], [2]. Các trường hợp tiêu biểu gồm UTF-8 không hợp lệ, chuyển surrogate sang ký tự thay thế U+FFFD, khoảng trắng Unicode và chuẩn hóa không đồng nhất giữa WAF với trình duyệt. Điểm chung không nằm ở một ký tự “nguy hiểm” riêng lẻ, mà ở việc dữ liệu có thể tiếp tục biến đổi sau khi hệ thống đã quyết định cho phép.

Bảng 1. Một số nguồn gây sai khác khi xử lý Unicode (Nguồn: Tổng hợp từ nghiên cứu Beyond Normalization)

Cơ sở dữ liệu là một ví dụ dễ bị bỏ qua. Collation quyết định cách ký tự được so sánh và sắp xếp; vì thế hai chuỗi nhìn khác nhau ở tầng ứng dụng vẫn có thể được cơ sở dữ liệu xem là tương đương. Điều này đặc biệt nhạy cảm với tên tài khoản, khóa định danh, đường dẫn hoặc những trường dữ liệu mà quy tắc nghiệp vụ phụ thuộc vào phép so sánh chính xác.

Không chỉ là câu chuyện vượt WAF

Nếu chỉ nhìn các trường hợp trên như một một kỹ thuật vượt WAF, phần quan trọng nhất của nghiên cứu sẽ bị bỏ qua. Một yêu cầu HTTP ngày nay có thể trải qua nhiều lần giải mã và biến đổi trước khi tạo ra kết quả cuối. Kiểm tra an toàn ở một điểm không bảo đảm dữ liệu vẫn giữ nguyên ý nghĩa ở điểm kế tiếp.

Một hướng mở rộng đáng chú ý của nghiên cứu nằm ở các hệ thống AI. Trước khi tới mô hình, văn bản thường còn đi qua khâu tiền xử lý, bộ tách token (tokenizer) và các bộ lọc an toàn; những lớp này không nhất thiết diễn giải mọi biến thể Unicode giống nhau. Black Hat cho biết nhóm tác giả cũng xem xét variation selector và một số biểu diễn Unicode đặc biệt trong bối cảnh bộ lọc LLM [1], [2]. Phát hiện này chưa đồng nghĩa Unicode có thể vượt qua mọi cơ chế bảo vệ AI, nhưng cho thấy bài toán sai khác trong diễn giải dữ liệu không chỉ tồn tại ở ứng dụng web truyền thống.

Phòng thủ phải theo cả đường đi của dữ liệu

Với lớp rủi ro này, bổ sung thêm một quy tắc nhận diện vào WAF chỉ giải quyết phần ngọn. Vấn đề cốt lõi là hạn chế sự khác biệt trong cách các thành phần của hệ thống diễn giải cùng một dữ liệu.

Ứng dụng nên kiểm tra chặt chẽ UTF-8 và từ chối sớm dữ liệu không hợp lệ thay vì để từng thư viện tự sửa theo cách riêng [3], [4]. Điều quan trọng là dữ liệu sau khi chuẩn hóa phải được kiểm tra nhất quán ở lớp bảo vệ và các thành phần xử lý phía sau, tránh tình trạng một chuỗi đã được WAF cho phép lại tiếp tục biến đổi trước khi ứng dụng sử dụng. Ở lớp cơ sở dữ liệu, các trường nhạy cảm cũng cần được rà soát quy tắc đối chiếu, thay vì mặc nhiên cho rằng phép so sánh chuỗi ở ứng dụng sẽ cho kết quả giống hệt ở backend.

Kiểm thử vì thế cần nhìn theo toàn bộ đường đi của dữ liệu, thay vì chỉ đánh giá từng thành phần riêng lẻ. Việc quan sát dữ liệu tại các điểm chuyển tiếp – từ gateway, framework đến cơ sở dữ liệu và trình duyệt – giúp phát hiện những sai khác giữa các bộ phân tích. Với đầu ra HTML hoặc JavaScript, mã hóa theo đúng ngữ cảnh vẫn là lớp bảo vệ bắt buộc; chuẩn hóa dữ liệu không thể thay thế biện pháp này [3].

Hình 2. Sai khác trong diễn giải dữ liệu: Lớp bảo vệ và ứng dụng có thể hiểu cùng một chuỗi theo hai cách khác nhau (Nguồn: Tác giả tổng hợp)

Một cảnh báo rộng hơn từ Unicode

Beyond Normalization cho thấy vấn đề đáng quan tâm không nằm ở một ký tự Unicode riêng lẻ, mà ở khoảng cách giữa các cách diễn giải dữ liệu trong cùng một hệ thống. Khi ứng dụng ngày càng được ghép từ nhiều lớp – gateway, WAF, framework, cơ sở dữ liệu, trình duyệt và cả thành phần AI – việc kiểm soát dữ liệu chỉ tại điểm đầu vào sẽ ngày càng khó bảo đảm an toàn. Với người phát triển và chuyên gia bảo mật, câu hỏi vì thế không chỉ là dữ liệu nào được phép đi vào hệ thống mà còn là dữ liệu ấy sẽ trở thành gì sau khi đi qua lớp xử lý cuối cùng.

Kết luận

Nghiên cứu “Beyond Normalization: The Expanding Unicode Attack Surface” cho thấy một vấn đề ngày càng đáng lưu ý trong các hệ thống hiện đại: Dữ liệu không chỉ được kiểm tra một lần tại điểm đầu vào mà còn liên tục được giải mã, chuẩn hóa và diễn giải qua nhiều lớp xử lý khác nhau. Khi WAF, framework, cơ sở dữ liệu, trình duyệt hay các thành phần AI có cách hiểu Unicode không hoàn toàn thống nhất, khoảng cách giữa các cách diễn giải có thể trở thành một điểm yếu khiến quyết định bảo mật ở lớp trước mất hiệu lực ở lớp sau.

Vì vậy, bảo vệ hệ thống trước các rủi ro liên quan đến Unicode không nên chỉ dừng ở việc bổ sung các mẫu nhận diện cho WAF. Cần kiểm soát chặt chẽ tính hợp lệ của dữ liệu, thống nhất cách chuẩn hóa và xử lý giữa các thành phần, đồng thời kiểm thử theo toàn bộ vòng đời của dữ liệu từ đầu vào đến đầu ra. Đặc biệt, với sự gia tăng của các kiến trúc đa lớp và việc tích hợp AI vào ứng dụng, việc hiểu dữ liệu sẽ trở thành gì sau mỗi bước xử lý cần được xem là một yêu cầu quan trọng trong thiết kế an toàn. Nói cách khác, thách thức mới không chỉ nằm ở việc ngăn dữ liệu độc hại đi vào hệ thống, mà còn ở việc bảo đảm mọi lớp trong hệ thống cùng hiểu dữ liệu theo một cách nhất quán. Đây sẽ là một yêu cầu ngày càng quan trọng đối với kiến trúc ứng dụng, kiểm thử bảo mật và quản trị rủi ro trên không gian mạng.