Vào tháng 7 năm 2025, một cá nhân đã đăng ký một tên miền từng thuộc về một mạng phân phối nội dung (CDN). CDN này đã ngừng hoạt động từ nhiều năm trước và tên miền dùng để cung cấp tài nguyên của nó đã bị để cho hết hạn. Tuy nhiên, nó vẫn chưa mất đi những "người gọi". Hàng nghìn trang web, kho lưu trữ mã nguồn và các trang tài liệu vẫn mang các tham chiếu được mã hóa cứng (hard-coded) đến các hostname bên dưới tên miền đó.
Chủ sở hữu mới nắm giữ wildcard DNS trên toàn bộ tên miền, và bất kỳ hostname nào bên dưới nó hiện đều trỏ về hạ tầng mà người này kiểm soát. Hiện tại, trang chủ của tên miền này chỉ là một trang tải xuống phương tiện truyền thông dày đặc quảng cáo, điều này vốn không có gì lạ. Điểm đáng chú ý là quyết định về việc hàng nghìn trang web kia sẽ tải nội dung gì tiếp theo giờ đây thuộc về một người lạ, và không ai liên quan được thông báo, bởi vì nhìn từ bên ngoài, không có gì bị hỏng cả.
Mô hình này không phải là giả thuyết và cũng không phải là chưa từng nghe thấy. Vào tháng 6 năm 2024, tên miền polyfill.io (một JavaScript shim được nhúng trong hơn 110.000 trang web) đã đổi chủ và bắt đầu thực hiện các lệnh chuyển hướng có điều kiện đối với khách truy cập bằng thiết bị di động. Các trang web chạy nó không hề bị hack, họ chỉ đơn giản là đã sử dụng một thẻ <script> từ bên ngoài nhiều năm trước và chưa bao giờ xem xét lại quyết định đó.
Cả hai trường hợp này đều chia sẻ một vấn đề mà hầu hết các đội ngũ bảo mật không có quyền kiểm soát: mã độc chưa bao giờ nằm trên máy chủ của họ, và nó xuất hiện rất lâu sau khi lần triển khai (deployment) cuối cùng diễn ra.
Các công cụ phía máy chủ đang tìm kiếm sai chỗ
Static analysis, dependency scanning và software composition analysis đều kiểm tra những gì một tổ chức xây dựng và xuất bản, nhưng một script từ bên thứ ba không nằm trong số đó. Nó được trình duyệt của khách truy cập tải về từ một máy chủ mà tổ chức không vận hành và không có quyền kiểm soát, diễn ra trực tiếp trên mỗi lượt xem trang.
Điều đó làm cho nó trở nên đặc biệt khó đối phó với các phương pháp kiểm tra truyền thống vì phản hồi có thể thay đổi tùy theo vị trí địa lý, user agent, referrer, thời gian trong ngày và phiên làm việc. Một trình thu thập dữ liệu (crawler) tải tệp một lần từ dải IP của trung tâm dữ liệu có thể nhận được phiên bản sạch; nhưng một người mua hàng trên mạng di động ở một quốc gia khác lại nhận được thứ gì đó độc hại hơn.
Trong khi đó, chính script của bên thứ ba lại nắm giữ các đặc quyền tương tự như mã nguồn tự phát triển của bạn. Nó có thể đọc DOM, đọc các trường biểu mẫu theo từng ký tự khi chúng được nhập vào, đọc cookies và local storage, và thực hiện các yêu cầu ra bên ngoài tới bất kỳ đâu nó muốn. Các cuộc tấn công phía máy khách (Client-side attacks) kiểu Magecart không yêu cầu xâm nhập máy chủ, chúng chỉ cần một thẻ script đã được phê duyệt bắt đầu hành xử khác đi.
Trình duyệt nhìn thấy tất cả mọi thứ
Có một "quan sát viên" luôn hiện diện đáng tin cậy trong mỗi lượt xem trang: đó là trình duyệt thực thi mã. Content Security Policy (CSP) thường được thảo luận như một biện pháp bảo vệ chống lại cross-site scripting, và đó là một giải pháp tốt, nhưng chức năng thứ hai của nó còn hữu ích hơn đối với một đội ngũ bảo mật chưa biết trang web mình đang chạy mã gì. Một CSP có thể kiểm soát mã nào được phép chạy trên trang web của bạn, chặn mã không được phép và cho bạn biết khi nào điều đó xảy ra.
Những cảnh báo đó đến từ các phiên làm việc thực, ở các vị trí địa lý thực, từ những người dùng thực trên các thiết bị thực của họ. Một mã độc chỉ kích hoạt cho những người dùng đã đăng nhập ở một quốc gia vẫn sẽ bị báo cáo, bởi vì trình duyệt thực thi mã đó chính là thứ gửi cảnh báo.
Đây không phải là một lợi ích lý thuyết. Vào tháng 9 năm 2026, những cảnh báo này được Report URI thu thập đã làm lộ ra một nhóm các trang thương mại điện tử bị xâm nhập đang chạy chiến dịch kỹ thuật xã hội (social-engineering) thuộc dòng "ClickFix". Các trình tải (loader) mã hóa Base64 đã được cấy vào bên trong nội dung CMS sau khi tài khoản quản trị bị chiếm quyền, dẫn dụ qua một trình chuyển hướng đến một lớp phủ giả mạo "xác minh bạn là con người". Lớp phủ này sẽ đặt một lệnh PowerShell vào clipboard của nạn nhân và duy trì nó dưới dạng một tác vụ được lập lịch (scheduled task). Các hostname do kẻ tấn công kiểm soát đã xuất hiện trong cảnh báo từ trình duyệt của nạn nhân trong khi nhiều tên miền đó vẫn được các dịch vụ danh tiếng xếp loại là sạch. Không có trình quét nào gắn cờ các trang này, vì trên máy chủ, chúng vẫn ổn.
Bạn có thể bắt đầu với CSP mà không cần chặn bất cứ thứ gì
Sự phản đối phổ biến là Content Security Policy sẽ làm hỏng trang web, nhưng ở chế độ chỉ báo cáo (report-only), nó không thể làm vậy. Content-Security-Policy-Report-Only không thực thi gì cả, không chặn gì và không thay đổi bất kỳ hành vi nào; nó chỉ báo cáo những gì mà một chính sách lẽ ra sẽ chặn.
Điều đó biến lần triển khai đầu tiên thành một bài tập đo lường an toàn và cho phép bạn thu thập tất cả dữ liệu cần thiết về những mã nào đang chạy trên trang web của mình. Đối với hầu hết các tổ chức, danh sách đó dài hơn nhiều so với họ mong đợi.
Tuân thủ quy định đã biến điều này thành nghĩa vụ
Đối với bất kỳ ai xử lý thanh toán bằng thẻ trên trang web của mình, lập luận này đã được định đoạt. Các yêu cầu 6.4.3 và 11.6.1 của PCI DSS v4.0.1 đã ngừng là khuyến nghị và trở thành bắt buộc kể từ ngày 31 tháng 3 năm 2025. Cùng với nhau, chúng yêu cầu mọi script trên trang thanh toán phải được ủy quyền, tính toàn vẹn của nó phải được đảm bảo, phải có danh mục bằng văn bản với lý giải kinh doanh và phải có cơ chế phát hiện cũng như cảnh báo về việc sửa đổi trái phép nội dung trang thanh toán và HTTP headers.
Một QSA có thể và sẽ yêu cầu xem danh mục, cơ chế cảnh báo và dấu vết bằng chứng mà nó tạo ra. Report URI có thể cung cấp cho bạn cả ba điều đó.
Quy trình triển khai hoạt động như thế nào
- Triển khai và thu thập dữ liệu ban đầu trong một tuần.
- Xây dựng danh mục (inventory) từ những gì đã được báo cáo.
- Theo dõi các thay đổi theo thời gian và phê duyệt hoặc từ chối những thay đổi đó.
Một cuộc khảo sát hàng ngày kéo dài mười năm trên một triệu trang web hàng đầu cho thấy việc áp dụng CSP đã tăng hơn 12.000% trong thập kỷ qua khi các tổ chức nhận ra những lợi ích mà nó mang lại. Sự tăng trưởng đó phản ánh một sự thay đổi rộng lớn hơn trong việc các tổ chức cần khả năng hiển thị: không chỉ vào những gì họ triển khai, mà còn vào mã nguồn mà trình duyệt của người dùng thực sự thực thi.
Vai trò của Report URI
Report URI là một nền tảng bảo mật phía máy khách giúp trả lời những câu hỏi mà đội ngũ bảo mật không thể trả lời về trang web của chính họ: bên thứ ba nào đang thực thi mã trên các trang của bạn? Cái nào đã thay đổi kể từ ngày hôm qua? Cái nào đang lấy dữ liệu hoặc giao tiếp với hạ tầng được xác định là độc hại? Các script cung cấp cho người dùng thực được băm (hashed) và lưu trữ, vì vậy các thay đổi có thể được xác định và điều tra sau đó. Các hostname được kiểm tra đối chiếu với threat intelligence, và các chính sách được giám sát để tránh sai lệch, lấp đầy khoảng cách giữa những gì bạn đã phê duyệt và những gì thực sự đang chạy trên trang web của mình.
Triển khai không thêm JavaScript vào trang của bạn và không có agent, module hay SDK nào vào hệ thống.
Bước đầu tiên rất dễ dàng, hãy thêm một HTTP response header và đọc dữ liệu trả về trong 48 giờ tiếp theo. Danh sách những thứ thực thi mã trong trình duyệt của khách hàng hiếm khi là danh sách mà bất kỳ ai mong đợi!
