Tấn công CSS mới vượt lớp bảo vệ Gmail và Outlook như thế nào?

CSS thường được xem là ngôn ngữ dùng để định dạng giao diện: đổi màu chữ, căn lề, bố trí phần tử hay tạo hiệu ứng. Vì vậy, nhiều hệ thống webmail cho phép một phần HTML và CSS trong email sau khi đưa nội dung qua bộ lọc an toàn. Nghiên cứu mới của PortSwigger cho thấy chính giả định “CSS chỉ để trình bày” có thể tạo ra một khoảng trống bảo mật đáng kể.

Trong nghiên cứu “CSS: the bomb inside your inbox”, được Gareth Heyes của PortSwigger công bố ngày 6/8/2026 và trình bày tại Black Hat USA 2026, nhà nghiên cứu đã xây dựng nhiều chuỗi proof-of-concept trên Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail và AOL Mail. Các kỹ thuật có thể khiến nội dung email vượt khỏi vùng hiển thị của chính nó, can thiệp vào giao diện webmail, tạo request ra ngoài, làm rò token và trong trường hợp Outlook kết hợp Firefox, dựng màn hình đăng nhập giả để ghi lại mật khẩu người dùng nhập.

Điều cần làm rõ là nghiên cứu không chứng minh Gmail và Outlook đều bị đánh cắp mật khẩu theo cùng một cơ chế. Chuỗi đánh cắp mật khẩu được trình diễn trên Outlook với Firefox. Trong khi đó, với Gmail, PortSwigger mô tả một cách lách lớp proxy hình ảnh bằng CSS, sau đó kết hợp với indirect prompt injection để chứng minh khả năng làm rò token trong một kịch bản có AI hỗ trợ. Đây là hai nhánh tấn công khác nhau nhưng cùng xuất phát từ một vấn đề căn bản: nội dung email không đáng tin cậy được render quá gần với giao diện và dữ liệu đáng tin cậy của ứng dụng webmail.

Vì sao HTML và CSS trong email lại là bài toán bảo mật khó?

Một dịch vụ webmail phải làm điều tưởng như mâu thuẫn. Nó cần hiển thị email HTML đủ đẹp để người dùng thấy đúng thiết kế của người gửi, nhưng đồng thời phải bảo đảm mã do người lạ gửi tới không thể tác động vào hộp thư, tài khoản hay dữ liệu khác của người nhận.

Giải pháp phổ biến là sử dụng HTML/CSS sanitizer. Bộ lọc sẽ loại JavaScript, thuộc tính hoặc CSS bị xem là nguy hiểm và chỉ giữ lại một danh sách thành phần được cho phép. Vấn đề là trình duyệt, sanitizer và mã JavaScript của chính webmail không phải lúc nào cũng diễn giải nội dung theo cùng một cách.

PortSwigger chỉ ra rằng một chuỗi CSS có thể được sanitizer đánh giá là an toàn, nhưng sau khi trình duyệt phân tích hoặc sau khi mã ứng dụng xử lý DOM, kết quả thực tế lại có khả năng vượt khỏi phạm vi mà bộ lọc dự tính. Khi email và giao diện webmail cùng tồn tại trong một vùng DOM tin cậy, sai khác nhỏ này có thể biến thành lỗi vượt ranh giới bảo mật.

Outlook: từ một email tới màn hình đăng nhập giả

Chuỗi Outlook là phần gây chú ý nhất vì nó cho thấy CSS có thể được kết hợp với HTML được cho phép để tạo ra trải nghiệm gần giống một trang đăng nhập Microsoft ngay bên trong giao diện webmail.

Nhà nghiên cứu phát hiện Outlook cho phép một số thuộc tính dữ liệu tùy chỉnh đi qua bộ lọc. Sau đó, thư viện JavaScript của chính ứng dụng xử lý các thuộc tính này và tạo thêm phần tử DOM với các giá trị CSS nằm ngoài danh sách mà sanitizer ban đầu cho phép. PortSwigger gọi dạng điểm tựa này là một CSS gadget.

CSS gadget quan trọng vì nó giúp nội dung email thoát khỏi vùng hiển thị thông thường. Thay vì chỉ thay màu hay font chữ bên trong thân thư, nội dung có thể được đặt ở vị trí che phủ phần lớn giao diện Outlook. Khi kết hợp với các điểm yếu khác trong bộ lọc CSS, nhà nghiên cứu có thể tạo một giao diện giả trông giống màn hình yêu cầu người dùng đăng nhập lại.

CSS không đọc trực tiếp mật khẩu — vậy nó lấy phím gõ bằng cách nào?

Một hiểu lầm phổ biến là CSS có thể đọc trực tiếp giá trị của bất kỳ ô mật khẩu nào. Trên thực tế, các kỹ thuật “CSS keylogger” cũ thường không hoạt động theo cách đó vì giá trị người dùng đang gõ trong DOM không tự động trở thành thuộc tính mà CSS có thể truy vấn.

Chuỗi của PortSwigger đi theo hướng khác. Thay vì dùng một ô mật khẩu tiêu chuẩn, proof-of-concept sử dụng một thành phần lựa chọn HTML được tạo hình để trông như ô nhập mật khẩu. Khi người dùng nhấn một phím, trình duyệt thay đổi lựa chọn bên trong thành phần này. CSS có thể phản ứng với trạng thái lựa chọn và kích hoạt một request tương ứng ra ngoài.

Nói đơn giản, CSS không “đọc” nội dung ô password. Nó biến quá trình người dùng nhấn phím thành một chuỗi thay đổi trạng thái mà stylesheet có thể nhận biết, sau đó dùng request tài nguyên để báo lại ký tự tương ứng.

PortSwigger còn phát hiện một hành vi đặc thù trên Firefox: bộ đếm thời gian liên quan tới việc lựa chọn trong thành phần này được đặt lại khi phần tử bị di chuyển ra ngoài màn hình rồi nhanh chóng đưa trở lại. Điều đó giúp proof-of-concept chuyển từ việc ghi phím có độ trễ sang gần thời gian thực.

Vượt CSS sanitizer của Outlook là mắt xích quyết định

Chỉ tạo được cơ chế ghi nhận phím vẫn chưa đủ để hình thành một màn hình phishing thuyết phục. Nhà nghiên cứu cần kiểm soát nhiều thuộc tính CSS hơn nhằm che giao diện Outlook và dựng lại trang đăng nhập.

Theo PortSwigger, một sai khác trong cách bộ lọc Outlook hiểu cú pháp media query đã cho phép stylesheet chứa nội dung mà sanitizer tưởng vẫn nằm trong một biểu thức an toàn, trong khi trình duyệt lại diễn giải phần sau thành các quy tắc CSS độc lập. Kết hợp điểm yếu này với CSS gadget nói trên, proof-of-concept có thể kiểm soát bố cục rộng hơn và phủ giao diện giả lên Outlook.

Kết quả cuối cùng được PortSwigger trình diễn là một email khi mở có thể khiến giao diện Outlook bị che bởi màn hình đăng nhập giả. Trên Firefox, mật khẩu người dùng nhập vào giao diện này có thể được ghi nhận gần thời gian thực thông qua chuỗi HTML/CSS.

Đây là ví dụ điển hình về tấn công ghép chuỗi. Không có một lỗi riêng lẻ nào tự nó tạo ra toàn bộ tác động. Rủi ro hình thành khi nhiều hành vi được cho là ít nguy hiểm — HTML label được phép, custom attribute, CSS gadget, parser quirk và hành vi của trình duyệt — được kết nối thành một đường tấn công hoàn chỉnh.

Gmail: vấn đề nằm ở image proxy và request ra ngoài

Gmail sử dụng cơ chế proxy hình ảnh để giảm khả năng người gửi theo dõi trực tiếp người nhận thông qua tài nguyên từ xa. Thay vì để trình duyệt người dùng tải ảnh trực tiếp từ máy chủ của người gửi trong mọi trường hợp, dịch vụ có thể đứng giữa quá trình tải tài nguyên.

PortSwigger cho biết họ tìm được cách sử dụng hàm CSS image-set() kết hợp với giá trị dự phòng của biến CSS để khiến Gmail tạo một request ra địa chỉ bên ngoài theo cách vượt qua kỳ vọng của bộ lọc. Trong nghiên cứu, kỹ thuật này trước hết được dùng để chứng minh khả năng theo dõi việc mở email.

Điểm đáng chú ý là request ra ngoài có thể trở thành kênh exfiltration nếu attacker kiểm soát được dữ liệu xuất hiện trong CSS. Vì vậy, PortSwigger kết hợp lỗ hổng này với một kịch bản indirect prompt injection nhắm vào một công cụ AI có kết nối Gmail.

Khi AI đọc email, CSS có thể trở thành kênh làm rò token

Trong proof-of-concept của PortSwigger, một email chứa chỉ dẫn được thiết kế để thao túng tác nhân AI. Khi AI đọc hộp thư và làm theo hướng dẫn, nó có thể đưa một token từ email khác vào nội dung bản nháp. Phần HTML của bản nháp đồng thời chứa CSS đã được chuẩn bị để tạo request ra ngoài.

Khi người dùng mở bản nháp để kiểm tra, request nền được kích hoạt và token có thể xuất hiện trong dữ liệu gửi tới máy chủ bên ngoài. Kịch bản này không có nghĩa Gmail tự động để CSS đọc mọi token trong hộp thư. Nó cần một chuỗi điều kiện gồm AI connector, prompt injection, việc AI đưa dữ liệu nhạy cảm vào email HTML và người dùng mở bản nháp.

Dù vậy, proof-of-concept cho thấy một vấn đề mới: khi AI agent được phép đọc nhiều email và tạo nội dung thay mặt người dùng, ranh giới bảo mật của email không còn chỉ nằm giữa “người gửi và webmail”. Một thông điệp độc hại có thể tìm cách tác động tới tác nhân AI, rồi dùng chính nội dung mà tác nhân tạo ra để đưa dữ liệu ra khỏi hệ thống.

Không phải một chiến dịch tấn công đang diễn ra ngoài thực tế

Các kỹ thuật PortSwigger công bố là nghiên cứu bảo mật và proof-of-concept. Báo cáo không đưa ra bằng chứng cho thấy những chuỗi này đã được tội phạm mạng sử dụng trong một chiến dịch thực tế để đánh cắp mật khẩu Gmail hoặc Outlook trên diện rộng.

Điều này rất quan trọng khi đánh giá mức độ rủi ro. Nghiên cứu chứng minh tính khả thi của một lớp tấn công và chỉ ra điểm yếu thiết kế trong cách webmail xử lý HTML/CSS, nhưng không nên được diễn giải thành tuyên bố rằng chỉ cần nhận một email là mọi người dùng Gmail hay Outlook đều sẽ mất mật khẩu.

Chuỗi Outlook được trình diễn với những điều kiện cụ thể, trong đó Firefox đóng vai trò quan trọng đối với khả năng ghi phím gần thời gian thực. Chuỗi Gmail lại có mục tiêu và điều kiện khác. Khả năng khai thác thực tế còn phụ thuộc trình duyệt, phiên bản ứng dụng, cấu hình sanitizer, những bản vá mới và hành vi người dùng.

Tình trạng khắc phục được công bố ra sao?

Tại thời điểm bài nghiên cứu được công bố, PortSwigger cho biết một số vấn đề trên Fastmail đã được báo cáo và sửa. Một kỹ thuật vượt proxy trên Proton Mail cũng không còn hoạt động khi nhà nghiên cứu kiểm tra lại sau đó.

Đối với Outlook, bài nghiên cứu cho biết kỹ thuật lạm dụng HTML label để điều khiển một số thành phần giao diện vẫn hoạt động khi công bố. Với Gmail, PortSwigger cho biết bypass dựa trên image-set() vẫn còn hiệu lực theo kết quả thử nghiệm của nhà nghiên cứu ở thời điểm xuất bản.

Đây là trạng thái do nhóm nghiên cứu báo cáo và có thể thay đổi sau khi Google, Microsoft hoặc trình duyệt cập nhật hệ thống. Vì vậy, người dùng và quản trị viên nên ưu tiên bản vá, cập nhật trình duyệt và thông báo chính thức mới nhất từ nhà cung cấp thay vì coi trạng thái ngày 6/8/2026 là cố định.

Người dùng Outlook và Gmail nên làm gì?

Người dùng cuối không thể tự sửa CSS sanitizer của nhà cung cấp, nhưng có thể giảm đáng kể khả năng một proof-of-concept như vậy trở thành sự cố tài khoản.

• Cảnh giác với yêu cầu đăng nhập xuất hiện ngay trong hộp thư: nếu Gmail hoặc Outlook bất ngờ hiển thị yêu cầu nhập lại mật khẩu khi đang đọc một email, không nên nhập thông tin ngay tại đó. Hãy mở dịch vụ từ tab mới hoặc ứng dụng chính thức.
• Dùng passkey khi có thể: passkey giảm phụ thuộc vào mật khẩu có thể bị nhập vào giao diện giả và chống phishing tốt hơn mật khẩu truyền thống.
• Bật MFA chống phishing: khóa bảo mật phần cứng hoặc phương thức xác thực dựa trên passkey mạnh hơn mã OTP có thể bị lừa nhập vào trang giả.
• Cập nhật trình duyệt và webmail: chuỗi khai thác phụ thuộc nhiều vào hành vi parser và trình duyệt, vì vậy bản vá có thể làm gãy một hoặc nhiều mắt xích.
• Không coi giao diện bên trong một tab quen thuộc là bằng chứng tuyệt đối: nghiên cứu cho thấy nội dung không đáng tin cậy có thể trong một số trường hợp che phủ hoặc mô phỏng phần UI đáng tin cậy.

Nhà phát triển webmail có thể phòng thủ thế nào?

PortSwigger cho rằng cách phòng thủ mạnh nhất là cô lập nghiêm ngặt nội dung email, chẳng hạn render email trong sandboxed iframe để CSS và HTML của thông điệp không thể vượt sang giao diện tin cậy của ứng dụng.

Ngoài ra, nhà cung cấp nên thắt chặt danh sách HTML/CSS được phép, xem xét chặn những thành phần lựa chọn có thể bị lạm dụng để mô phỏng input, hạn chế các selector có khả năng phản ứng với trạng thái giao diện, kiểm tra CSS/HTML gadget được tạo bởi JavaScript của chính ứng dụng và dùng image proxy theo cách không thể bị né bằng cú pháp CSS mới.

Thông điệp lớn hơn là sanitizer cần được thiết kế theo cách trình duyệt thực sự diễn giải nội dung, không chỉ theo cách parser của bộ lọc nghĩ rằng trình duyệt sẽ diễn giải. CSS liên tục được bổ sung tính năng mới, nên một allow list an toàn hôm nay chưa chắc vẫn an toàn khi browser engine thay đổi.

CSS đang trở thành bề mặt tấn công nghiêm túc hơn

Nghiên cứu của PortSwigger không biến CSS thành một ngôn ngữ thực thi tương đương JavaScript, nhưng nó cho thấy ranh giới này đang trở nên phức tạp hơn. CSS hiện có selector theo trạng thái, biến, animation, hàm xử lý tài nguyên và nhiều cơ chế đủ mạnh để tạo ra side channel hoặc điều khiển cách người dùng tương tác với giao diện.

Khi những khả năng đó được đặt trong một webmail nơi email không đáng tin cậy nằm sát UI đáng tin cậy, sai sót sanitizer có thể mở ra tác động lớn hơn nhiều so với “email hiển thị sai màu”. Chuỗi Outlook chứng minh khả năng dựng giao diện đăng nhập giả và lấy mật khẩu trong điều kiện cụ thể. Chuỗi Gmail cho thấy một request CSS tưởng vô hại có thể trở thành mắt xích làm rò dữ liệu khi được kết hợp với AI agent và prompt injection.

Vì thế, bài học từ “CSS: the bomb inside your inbox” không phải là người dùng nên tắt toàn bộ HTML email. Điểm quan trọng hơn là các nền tảng webmail cần coi CSS từ email là nội dung chủ động có khả năng ảnh hưởng đến bảo mật, chứ không đơn thuần là một lớp trang trí.

Nguồn tham khảo: PortSwigger Research, “CSS: the bomb inside your inbox”, Gareth Heyes, công bố ngày 6/8/2026; Black Hat USA 2026 Briefings Schedule; The Hacker News, “New CSS Attacks Can Break Webmail Defenses to Steal Passwords and Tokens”, ngày 8/8/2026.