Giảm thiểu rủi ro liên quan đến việc vô tình để lộ các thiết bị và máy chủ trên mạng nội bộ của khách hàng cho toàn bộ web.
Các trang web độc hại gửi yêu cầu đến các thiết bị và máy chủ được lưu trữ trên một mạng riêng từ lâu đã là một mối đe doạ. Ví dụ: kẻ tấn công có thể thay đổi cấu hình của bộ định tuyến không dây để thực hiện các cuộc tấn công Man-in-the-Middle. CORS-RFC1918 là một đề xuất chặn các yêu cầu như vậy theo mặc định trên trình duyệt và yêu cầu các thiết bị nội bộ chọn nhận yêu cầu từ Internet công cộng.
Để hiểu rõ tác động của thay đổi này đối với hệ sinh thái web, nhóm Chrome đang tìm kiếm ý kiến phản hồi của những nhà phát triển xây dựng máy chủ cho mạng riêng tư.
Hiện trạng có vấn đề gì?
Nhiều máy chủ web chạy trong một mạng riêng tư – bộ định tuyến không dây, máy in, trang web nội bộ, dịch vụ doanh nghiệp và thiết bị Internet of Things (IoT) chỉ là một phần trong số đó. Chúng có vẻ như nằm trong một môi trường an toàn hơn so với những môi trường công khai, nhưng những máy chủ đó có thể bị kẻ tấn công lợi dụng bằng cách sử dụng một trang web làm proxy. Ví dụ: các trang web độc hại có thể nhúng một URL mà khi nạn nhân chỉ cần xem (trên trình duyệt có hỗ trợ JavaScript), URL đó sẽ tìm cách thay đổi chế độ cài đặt máy chủ DNS trên bộ định tuyến băng tần rộng tại nhà của nạn nhân. Loại tấn công này được gọi là "Tấn công chuyển hướng bằng cách truy cập vào trang web" và xảy ra vào năm 2014. Hơn 300.000 bộ định tuyến không dây dễ bị tấn công đã bị khai thác bằng cách thay đổi chế độ cài đặt DNS và cho phép kẻ tấn công chuyển hướng người dùng đến các máy chủ độc hại.
CORS-RFC1918
Để giảm thiểu mối đe doạ của các cuộc tấn công tương tự, cộng đồng web đang triển khai CORS-RFC1918 – Chia sẻ tài nguyên trên nhiều nguồn gốc (CORS) chuyên biệt cho các mạng riêng tư được xác định trong RFC1918.
Các trình duyệt triển khai chế độ kiểm tra CORS với các tài nguyên mục tiêu để xem liệu chúng có được phép tải từ một nguồn gốc khác hay không. Điều này được thực hiện bằng cách sử dụng các tiêu đề bổ sung nội tuyến mô tả quyền truy cập hoặc bằng cách sử dụng một cơ chế gọi là yêu cầu kiểm tra trước, tuỳ thuộc vào độ phức tạp. Hãy đọc bài viết Chia sẻ tài nguyên trên nhiều nguồn gốc để tìm hiểu thêm.
Với CORS-RFC1918, theo mặc định, trình duyệt sẽ chặn việc tải tài nguyên qua mạng riêng, trừ những tài nguyên được máy chủ cho phép rõ ràng bằng CORS và thông qua HTTPS. Trang web đưa ra yêu cầu đối với những tài nguyên đó sẽ cần gửi tiêu đề CORS và máy chủ sẽ cần nêu rõ rằng máy chủ chấp nhận yêu cầu trên nhiều nguồn gốc bằng cách phản hồi bằng các tiêu đề CORS tương ứng. (Tiêu đề CORS chính xác vẫn đang trong quá trình phát triển.)
Nhà phát triển của những thiết bị hoặc máy chủ như vậy sẽ được yêu cầu làm hai việc:
- Đảm bảo trang web gửi yêu cầu đến một mạng riêng được phân phát qua HTTPS.
- Thiết lập chế độ hỗ trợ máy chủ cho CORS-RFC1918 và phản hồi bằng các tiêu đề HTTP dự kiến.
Những loại yêu cầu nào bị ảnh hưởng?
Các yêu cầu bị ảnh hưởng bao gồm:
- Yêu cầu từ mạng công cộng đến mạng riêng tư
- Yêu cầu từ một mạng riêng tư đến mạng cục bộ
- Yêu cầu từ mạng công cộng đến mạng cục bộ
Mạng riêng tư
Một đích đến phân giải thành không gian địa chỉ riêng tư được xác định trong Mục 3 của RFC1918 trong IPv4, một địa chỉ IPv6 được ánh xạ IPv4 trong đó địa chỉ IPv4 được ánh xạ là địa chỉ riêng tư hoặc một địa chỉ IPv6 bên ngoài các mạng con ::1/128, 2000::/3 và ff00::/8.
Mạng cục bộ
Một đích đến phân giải thành không gian "loopback" (127.0.0.0/8) được xác định trong mục 3.2.1.3 của RFC1122 của IPv4, không gian "link-local" (169.254.0.0/16) được xác định trong RFC3927 của IPv4, tiền tố "Unique Local Address" (fc00::/7) được xác định trong Mục 3 của RFC4193 của IPv6 hoặc tiền tố "link-local" (fe80::/10) được xác định trong mục 2.5.6 của RFC4291 của IPv6.
Mạng công cộng Tất cả các mạng khác.
Kế hoạch của Chrome về việc bật CORS-RFC1918
Chrome sẽ triển khai CORS-RFC1918 theo 2 bước:
Bước 1: Chỉ các trang web HTTPS mới được phép gửi yêu cầu đến các tài nguyên mạng riêng tư
Chrome 87 bổ sung một cờ bắt buộc các trang web công khai đưa ra yêu cầu đối với tài nguyên mạng riêng phải sử dụng HTTPS. Bạn có thể chuyển đến phần about://flags#block-insecure-private-network-requests để bật tính năng này. Khi cờ này bật, mọi yêu cầu đến một tài nguyên mạng riêng từ một trang web HTTP sẽ bị chặn.
Kể từ Chrome 88, các lỗi CORS-RFC1918 sẽ được báo cáo dưới dạng lỗi chính sách CORS trong bảng điều khiển.
Trong bảng điều khiển Mạng của Chrome DevTools, bạn có thể đánh dấu vào hộp Yêu cầu bị chặn để tập trung vào các yêu cầu bị chặn:
Trong Chrome 87, lỗi CORS-RFC1918 chỉ được báo cáo trong Bảng điều khiển DevTools dưới dạng ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
Bạn có thể tự mình dùng thử bằng trang web kiểm thử này.
Bước 2: Gửi yêu cầu kiểm tra trước chuyến bay bằng tiêu đề đặc biệt
Trong tương lai, bất cứ khi nào một trang web công khai cố gắng tìm nạp tài nguyên từ một mạng riêng hoặc mạng cục bộ, Chrome sẽ gửi một yêu cầu kiểm tra trước khi gửi yêu cầu thực tế.
Yêu cầu sẽ bao gồm một tiêu đề Access-Control-Request-Private-Network: true ngoài các tiêu đề khác của yêu cầu CORS. Ngoài các tiêu chí khác, những tiêu đề này còn xác định nguồn gốc của yêu cầu, cho phép kiểm soát quyền truy cập một cách chi tiết. Máy chủ có thể phản hồi bằng tiêu đề Access-Control-Allow-Private-Network:
true để cho biết rõ rằng máy chủ cấp quyền truy cập vào tài nguyên.
Chúng tôi mong nhận được ý kiến phản hồi của bạn
Nếu bạn đang lưu trữ một trang web trong mạng riêng tư và dự kiến sẽ nhận được các yêu cầu từ mạng công cộng, thì nhóm Chrome rất mong nhận được ý kiến phản hồi và các trường hợp sử dụng của bạn. Có hai việc bạn có thể làm để giúp đỡ:
- Chuyển đến
about://flags#block-insecure-private-network-requests, bật cờ và xem liệu trang web của bạn có gửi yêu cầu đến tài nguyên mạng riêng như dự kiến hay không. - Nếu bạn gặp vấn đề hoặc có ý kiến phản hồi, hãy báo cáo vấn đề tại crbug.com và đặt thành phần thành
Blink>SecurityFeature>CORS>RFC1918.
Ví dụ về ý kiến phản hồi
Bộ định tuyến không dây của chúng tôi cung cấp một trang web quản trị cho cùng một mạng riêng nhưng thông qua HTTP. Nếu HTTPS là bắt buộc đối với những trang web nhúng trang web quản trị, thì đó sẽ là nội dung hỗn hợp. Chúng ta có nên bật HTTPS trên trang web quản trị trong một mạng đóng không?
Đây chính xác là loại ý kiến phản hồi mà Chrome đang tìm kiếm. Vui lòng báo cáo vấn đề kèm theo trường hợp sử dụng cụ thể của bạn tại crbug.com. Chrome rất mong nhận được thông tin từ bạn.