Vào ngày 4 tháng 8 năm 2026, các nhà nghiên cứu Mysk đã công bố phân tích ba cơ chế của WebKit, cho phép gửi lưu lượng truy cập vượt qua proxy đã được cấu hình - trực tiếp từ thiết bị. Tất cả các trình duyệt iOS với chế độ proxy, bao gồm cả trình duyệt Tor, và dịch vụ riêng của Apple - iCloud Private Relay - đều bị ảnh hưởng. Proxy đã được bật, giao diện hiển thị quốc gia khác, nhưng trang web vẫn thấy địa chỉ IP thực của bạn và bộ giải quyết DNS tại nhà của bạn.
Đây không phải là một lỗ hổng kỳ lạ dành cho những người hoài nghi. Đây là một minh chứng rõ ràng cho quy tắc kiến trúc mà mọi người làm việc qua proxy nên ghi nhớ: proxy ở cấp độ ứng dụng chỉ bảo vệ lưu lượng mà đi qua ngăn xếp mạng của ứng dụng đó. Mọi thứ mà hệ điều hành hoặc dịch vụ hệ thống riêng lẻ tạo ra đều đi qua.
Cái gì đang rò rỉ
Nghiên cứu bắt đầu từ một tình huống thông thường: người dùng trình duyệt proxy Psylo đã phàn nàn với nhà phát triển về việc rò rỉ DNS. Phân tích khiếu nại đã phát hiện ba kênh rò rỉ độc lập - tất cả đều nằm trong chính WebKit, chứ không phải trong ứng dụng cụ thể.
1. DNS prefetching - đơn giản nhất và khó chịu nhất
Cơ chế: thẻ <link rel="dns-prefetch"> yêu cầu trình duyệt giải quyết trước tên máy chủ để tăng tốc độ tải trong tương lai. Vấn đề là WebKit trên iOS giải quyết những tên này qua đường dẫn DNS thông thường của thiết bị, chứ không phải qua proxy.
Safari trên máy tính đã hỗ trợ dns-prefetch từ thời Safari 5, nhưng iOS đã bỏ qua thẻ này - cho đến iOS 26.0 (tháng 9 năm 2025). Khi đó, WebKit đã kích hoạt nó trong khuôn khổ cùng một thay đổi đã loại bỏ việc dns-prefetching suy đoán cũ (lỗi 285744).
Cách thức khai thác: trang web nhúng vào các thẻ như vậy những tên máy chủ độc nhất cho mỗi khách truy cập, và sau đó đơn giản nhìn xem các yêu cầu đến từ máy chủ DNS ủy quyền của nó - từ địa chỉ thực của mạng của khách truy cập. Không cần JavaScript, không cần tương tác với người dùng. Chỉ cần mở trang.
2. WebAuthn Related Origin Requests - rò rỉ qua hộ chiếu từ passkey
Kênh này đã xuất hiện từ iOS 18.0. Khi trang web yêu cầu thông tin đăng nhập WebAuthn (tức là passkey), hệ thống sẽ kiểm tra tệp https://<rpId>/.well-known/webauthn - để đảm bảo rằng miền thực sự liên kết với bên thứ ba được chỉ định.
Chi tiết quan trọng: yêu cầu kiểm tra này không xuất phát từ ngăn xếp mạng của trình duyệt. Nó được thực hiện bởi dịch vụ thông tin đăng nhập của hệ điều hành, tự gửi yêu cầu HTTPS trực tiếp từ thiết bị. Proxy được cấu hình bên trong trình duyệt hoàn toàn không biết về nó (lỗi 268426).
Tức là chỉ cần trang khởi tạo yêu cầu passkey - và máy chủ của kẻ tấn công nhận được kết nối từ địa chỉ IP thực của bạn.
3. WebTransport - QUIC trực tiếp từ thiết bị
Kênh mới nhất. Lệnh new WebTransport(url) mở một kết nối QUIC trực tiếp từ thiết bị, bỏ qua cấu hình proxy. WebTransport trong WebKit đã bị tắt trong một thời gian dài và chính thức xuất hiện trên iOS 26.4 vào tháng 3 năm 2026 (các lỗi 260810 và 303453).
Ai bị ảnh hưởng
Apple yêu cầu tất cả các trình duyệt trên iPhone phải sử dụng WebKit. Do đó, mỗi trình duyệt iOS nào dựa vào API proxy của WebKit đều bị ảnh hưởng - bao gồm tất cả các phiên bản iOS của trình duyệt Tor và chính Psylo, nơi bắt đầu cuộc điều tra. Cùng với đó là Safari và iCloud Private Relay.
Điều không bị ảnh hưởng - các ứng dụng VPN. Chúng hoạt động ở cấp hệ thống và bao bọc toàn bộ lưu lượng của thiết bị, bao gồm cả những gì được tạo ra bởi các dịch vụ hệ thống. Đây chính là sự khác biệt: đường hầm hệ thống không có "đi qua". Một ngoại lệ riêng biệt - Onion Browser ở cấp độ bảo mật Silver với chế độ Lockdown được bật: nó không bị ảnh hưởng bởi rò rỉ qua WebTransport.
Phản ứng từ phía các nhà phát triển đã có. Trong Psylo 1.3.1, tất cả ba kênh đã được đóng lại: ứng dụng chặn các gợi ý dns-prefetch (trang không thể buộc thiết bị giải quyết các tên thuộc quyền kiểm soát của kẻ tấn công), và WebTransport cùng WebAuthn đều bị tắt theo mặc định - có thể bật chúng một cách riêng lẻ, bằng các công tắc riêng. Theo thông tin vào thời điểm công bố, Apple dự kiến sẽ khắc phục các vấn đề trong bản cập nhật tương lai; công ty chưa đưa ra thời gian cụ thể.
Tại sao vấn đề này chỉ nổi lên bây giờ
Thời gian ở đây rất đáng chú ý, và đáng để phân tích riêng - nó giải thích tại sao vấn đề này không được phát hiện sớm hơn.
- Tháng 9 năm 2024, iOS 18.0 - cơ chế WebAuthn Related Origin Requests xuất hiện. Kênh rò rỉ đã tồn tại gần hai năm và trong suốt thời gian này không ai thảo luận: việc kiểm tra miền cho passkey trông giống như một yếu tố bảo mật, chứ không phải là một cách để tiết lộ địa chỉ.
- Tháng 9 năm 2025, iOS 26.0 - WebKit kích hoạt hỗ trợ dns-prefetch trên thiết bị di động. Về mặt hình thức, đây là tối ưu hóa tốc độ tải; thực tế - trang web có khả năng buộc thiết bị truy cập vào một tên DNS tùy ý mà không qua proxy.
- Tháng 3 năm 2026, iOS 26.4 - WebTransport được công khai kích hoạt. Kênh thứ ba.
- Tháng 8 năm 2026 - khiếu nại của một người dùng về rò rỉ DNS dẫn đến một cuộc phân tích, phát hiện ra cả ba kênh cùng một lúc.
Điểm chung: không một trong những chức năng này được thiết kế như một kênh để làm lộ danh tính. Tất cả ba đều là những khả năng thông thường của nền tảng: tăng tốc độ giải quyết, kiểm tra passkey, vận chuyển hiện đại. Chúng chỉ trở thành rò rỉ khi kết hợp với chế độ proxy ở cấp độ ứng dụng, và đó chính là lý do tại sao không ai kiểm tra chúng trong nhiều năm qua.
Kết luận cho thực tiễn là đơn giản và khó chịu: việc không có tin tức về rò rỉ không có nghĩa là chúng không tồn tại. Cần phải kiểm tra bản thân và thường xuyên, chứ không phải chờ đợi ai đó công bố phân tích.
Làm thế nào để tự kiểm tra
Các nhà nghiên cứu đã công bố một trang thử nghiệm công khai - leaks.psylo.app. Nó kiểm tra ba điều: lưu lượng HTTPS thông thường (máy chủ thấy địa chỉ IP và các bộ giải quyết DNS nào), WebTransport và sự kết hợp WebAuthn + dns-prefetch. Mở trang với proxy được bật và so sánh kết quả với địa chỉ mà bạn mong đợi thấy.
Cũng cần kiểm tra sự vệ sinh cơ bản - địa chỉ IP, DNS và địa chỉ WebRTC có trùng khớp trong liên kết làm việc của bạn không. Nếu trước đây bạn chưa làm điều này một cách hệ thống, hãy bắt đầu với phân tích của chúng tôi: cách kiểm tra proxy để phát hiện rò rỉ DNS.
Kết luận thực tiễn: lớp có ý nghĩa
Câu chuyện với WebKit là một trường hợp riêng lẻ của quy tắc chung mà bạn nên ghi nhớ khi làm việc qua proxy, trên bất kỳ nền tảng nào.
- Proxy trong trình duyệt ≠ proxy trên thiết bị. Cấu hình bên trong ứng dụng chỉ bao phủ đúng lưu lượng mà ứng dụng tự gửi đi. Các dịch vụ hệ thống, quy trình nền, cập nhật, kết nối đẩy và, như đã phát hiện, dịch vụ passkey tích hợp - tất cả đều đi theo con đường riêng của chúng.
- Rò rỉ không chỉ xảy ra ở những "nơi đã biết". WebRTC đã được biết đến từ lâu, và người ta đã học cách bịt kín nó. Còn dns-prefetching và kiểm tra WebAuthn - đây là những chức năng về hiệu suất và bảo mật mà không ai xem xét như một kênh để làm lộ danh tính. Các tính năng mới của trình duyệt thường tạo ra những con đường vòng mới.
- Cập nhật nền tảng có thể âm thầm phá vỡ bảo mật của bạn. Điều này có thể thấy rõ qua các ngày tháng: dns-prefetching "được kích hoạt" trong iOS 26.0, WebTransport - trong iOS 26.4. Người dùng không thay đổi gì cả, nhưng bề mặt rò rỉ đã tự tăng lên.
Điều này có nghĩa là gì cho việc đa tài khoản và tự động hóa
Đối với những người quản lý nhiều tài khoản hoặc thu thập dữ liệu, rủi ro ở đây không phải là vấn đề riêng tư trừu tượng, mà là một vấn đề tài chính thực sự. Các hệ thống chống gian lận của các nền tảng so sánh các tín hiệu: nếu phiên làm việc tuyên bố một địa chỉ IP, nhưng yêu cầu liên quan đến từ một địa chỉ khác và từ bộ giải quyết tại nhà, đó là lý do hoàn hảo để liên kết các tài khoản với nhau hoặc đánh dấu phiên làm việc là nghi ngờ.
Hệ quả thực tiễn:
- Không thực hiện các phiên làm việc đa tài khoản trong các trình duyệt di động với chế độ proxy. Cho đến khi nền tảng khắc phục các lỗ hổng, lớp ứng dụng trên iOS không đáng tin cậy theo định nghĩa.
- Bao bọc lưu lượng một cách hệ thống. Nếu nhiệm vụ là môi trường di động, tốt hơn là thiết lập proxy ở cấp độ thiết bị hoặc định tuyến qua một cổng riêng, thay vì dựa vào cấu hình bên trong trình duyệt.
- Kiểm tra liên kết sau mỗi bản cập nhật lớn của hệ điều hành và trình duyệt. Ít nhất một lần mỗi quý. Hãy đưa điều này vào danh sách kiểm tra của bạn, chứ không phải "khi có điều gì đó không ổn".
- Tắt những gì bạn không sử dụng. WebTransport và WebAuthn trong hồ sơ làm việc cho việc phân tích hoặc SMM gần như chắc chắn không cần thiết - việc tắt chúng loại bỏ hai kênh rò rỉ trong ba kênh.
Chất lượng của chính địa chỉ IP vẫn là một biến số riêng: ngay cả khi cấu hình trung tâm dữ liệu kín, địa chỉ của trung tâm dữ liệu vẫn tiết lộ mình qua ASN. Đối với các kịch bản, nơi quan trọng là trông giống như một người dùng bình thường, các proxy cư trú hoạt động, và cho các ứng dụng di động và các nền tảng có hệ thống chống gian lận nghiêm ngặt nhất - proxy di động với IP của các nhà mạng thực. Nhưng không có loại proxy nào có thể cứu bạn nếu một phần lưu lượng vật lý đi qua nó - trước tiên là tính kín, sau đó là chất lượng địa chỉ.
Kết luận
Ba lỗi của WebKit - DNS prefetching, WebAuthn Related Origin Requests và WebTransport - đã chỉ ra rằng "proxy đã được bật" và "tất cả lưu lượng đi qua proxy" là hai tuyên bố khác nhau. Trên iOS, khoảng cách giữa chúng đã đủ rộng để một trang web thông thường mà không có một dòng JavaScript nào có thể biết địa chỉ thực của khách truy cập trình duyệt Tor.
Trong khi Apple chuẩn bị bản sửa lỗi, chiến lược duy nhất khả thi là kiểm tra, chứ không phải giả định. Mở trang thử nghiệm, so sánh địa chỉ, tắt các API không cần thiết. Và coi mỗi bản cập nhật lớn của hệ điều hành như một sự kiện, sau đó cần phải kiểm tra lại cấu hình. Sự khác biệt giữa tính riêng tư và ảo tưởng về nó thường chỉ nằm ở một câu hỏi không được đặt ra kịp thời: "liệu tất cả lưu lượng có thực sự đi qua không?". Cũng hữu ích khi hiểu những tín hiệu nào khác đang tiết lộ bạn ngoài địa chỉ - về điều này chúng tôi đã viết trong tài liệu về bảo vệ chống lại việc nhận dạng trình duyệt.