Muốn có ý kiến phản hồi: CORS cho mạng riêng (RFC1918)

Giảm thiểu rủi ro liên quan đến việc vô tình tiết lộ thiết bị và máy chủ trên mạng nội bộ của khách hàng cho web nói chung.

Eiji Kitamura

Lưu ý: Để rõ ràng hơn, chúng tôi đã đổi tên CORS-RFC1918 thành Quyền truy cập mạng riêng. Thông tin cập nhật về bài đăng này được đăng trên blog developer.chrome.com.

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ạng riêng tư từ lâu đã là 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à đề 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 tham gia các 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 các nhà phát triển xây dựng máy chủ cho mạng riêng tư.

Tình trạng hiện tại 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 vạn vật (IoT) chỉ là một phần trong số đó. Các máy chủ này có vẻ như ở trong một môi trường an toàn hơn so với các máy chủ được công khai, nhưng kẻ tấn công có thể lợi dụng các máy chủ đó 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ỉ xem (trên trình duyệt 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 thông rộng tại nhà của nạn nhân. Loại hình tấn công này được gọi là "Tấn công giả mạo khi truy cập" 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 CORS sẽ kiểm tra với các tài nguyên mục tiêu xem có thể tải từ một nguồn gốc khác hay không. Việc này được thực hiện bằng các tiêu đề bổ sung cùng dòng 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 trước khi bay, 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, ngoại trừ những tài nguyên mà máy chủ cho phép rõ ràng bằng CORS và thông qua HTTPS. Trang web thực hiện yêu cầu đến các 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 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 các 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ạng riêng được phân phát qua HTTPS.
• Thiết lập tính năng 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?

Sau đây là những yêu cầu bị ảnh hưởng:

• Yêu cầu từ mạng công khai đến mạng riêng
• Yêu cầu từ mạng riêng đến mạng cục bộ
• Yêu cầu từ mạng công khai đến mạng cục bộ

Mạng riêng tư Đích đến phân giải đến 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 liên kết IPv4 trong đó địa chỉ IPv4 được liên kết chính 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ộ Đích đến phân giải đến không gian "loopback" (127.0.0.0/8) được xác định trong phần 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ố "Địa chỉ cục bộ duy nhất" (fc00::/7) được xác định trong Phần 3 của RFC4193 của IPv6 hoặc tiền tố "link-local" (fe80::/10) được xác định trong phần 2.5.6 của RFC4291 của IPv6.

Mạng công cộng Mọi mạng khác.

Mối quan hệ giữa mạng công cộng, mạng riêng, mạng cục bộ trong CORS-RFC1918.

Kế hoạch của Chrome để bật CORS-RFC1918

Chrome sẽ triển khai CORS-RFC1918 theo hai bước:

Bước 1: Chỉ cho phép các yêu cầu đến tài nguyên mạng riêng từ các trang web HTTPS

Chrome 87 thêm một cờ yêu cầu các trang web công khai đưa ra yêu cầu truy cập vào tài nguyên mạng riêng phải sử dụng giao thức HTTPS. Bạn có thể chuyển đến about://flags#block-insecure-private-network-requests để bật tính năng này. Khi bạn bật cờ này, mọi yêu cầu đến tài nguyên mạng riêng từ một trang web HTTP sẽ bị chặn.

Kể từ Chrome 88, 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.

Lỗi CORS-RFC1918 sẽ được báo cáo là 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 Công cụ dành cho nhà phát triển Chrome, bạn có thể bật hộp đánh dấu Yêu cầu bị chặn để tập trung vào các yêu cầu bị chặn:

Lỗi CORS-RFC1918 cũng sẽ được báo cáo dưới dạng lỗi CORS trong bảng điều khiển Mạng.

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ự thử nghiệm bằng cách sử dụng trang web thử nghiệm này.

Bước 2: Gửi yêu cầu trước khi bay bằng tiêu đề đặc biệt

Trong tương lai, mỗi khi một trang web công khai cố gắng tìm nạp tài nguyên từ mạng riêng tư hoặc mạng cục bộ, Chrome sẽ gửi một yêu cầu trước khi bay trước yêu cầu thực tế.

Yêu cầu này sẽ bao gồm một tiêu đề Access-Control-Request-Private-Network: true ngoài các tiêu đề yêu cầu CORS khác. Ngoài ra, các tiêu đề này xác định nguồn gốc tạo ra yêu cầu, cho phép kiểm soát quyền truy cập 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.

Lưu ý: Các tiêu đề này vẫn đang trong quá trình phát triển và có thể thay đổi trong tương lai. Bạn hiện không cần làm gì cả.

Muốn nhận ý kiến phản hồi

Nếu bạn đang lưu trữ một trang web trong một mạng riêng tư và mong đợi các yêu cầu từ mạng công cộng, nhóm Chrome rất mong nhận được ý kiến phản hồi và trường hợp sử dụng của bạn. Bạn có thể làm hai việc sau để 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 phân phát 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à điều kiện bắt buộc đối với các trang web nhúng trang web quản trị, thì đó sẽ là nội dung hỗn hợp. Chúng tôi có nên bật HTTPS trên trang web quản trị trong một mạng khép kín không?

Đây chính xác là loại 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 ý kiến phản hồi của bạn.

Hình ảnh chính của Stephen Philips trên Unsplash.