Trang này được dịch bởi Cloud Translation API.

Quyền truy cập mạng riêng tư: giới thiệu các kiểm tra

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

Thông tin cập nhật

Ngày 7 tháng 7 năm 2022: Cập nhật trạng thái hiện tại và bổ sung định nghĩa về không gian địa chỉ IP.
Ngày 27 tháng 4 năm 2022: Thông báo cập nhật tiến trình.
Ngày 7 tháng 3 năm 2022: Thông báo về việc khôi phục sau khi phát hiện vấn đề trong Chrome 98.

Giới thiệu

Chrome sẽ ngừng sử dụng quyền truy cập trực tiếp vào các điểm cuối mạng riêng tư từ các trang web công khai trong thông số kỹ thuật về Quyền truy cập mạng riêng (PNA).

Chrome sẽ bắt đầu gửi yêu cầu kiểm tra trước CORS trước mọi yêu cầu mạng riêng cho một tài nguyên phụ, yêu cầu máy chủ mục tiêu cấp quyền rõ ràng. Yêu cầu trước khi bay này sẽ mang theo một tiêu đề mới, Access-Control-Request-Private-Network: true, và phản hồi cho yêu cầu đó phải mang theo một tiêu đề tương ứng, Access-Control-Allow-Private-Network: true.

Mục đích là để bảo vệ người dùng khỏi các cuộc tấn công giả mạo yêu cầu trên nhiều trang web (CSRF) nhắm đến bộ định tuyến và các thiết bị khác trên mạng riêng. Những cuộc tấn công này đã ảnh hưởng đến hàng trăm nghìn người dùng, cho phép kẻ tấn công chuyển hướng họ đến các máy chủ độc hại.

Kế hoạch triển khai

Chrome sẽ triển khai thay đổi này theo hai giai đoạn để các trang web có thời gian nhận thấy sự thay đổi và điều chỉnh cho phù hợp.

Trong Chrome 104:
- Chrome thử nghiệm bằng cách gửi các yêu cầu trước khi khởi động trước các yêu cầu tài nguyên phụ của mạng riêng.
- Lỗi kiểm tra trước chỉ hiển thị cảnh báo trong Công cụ cho nhà phát triển mà không ảnh hưởng đến các yêu cầu mạng riêng.
- Chrome thu thập dữ liệu về khả năng tương thích và tiếp cận những trang web bị ảnh hưởng lớn nhất.
- Chúng tôi dự kiến phiên bản này sẽ tương thích rộng rãi với các trang web hiện có.
Cảnh báo: Để hạn chế tác động đến các trang web chưa hỗ trợ tính năng kiểm tra, thời gian chờ sẽ bị giới hạn ở mức 200 mili giây trong Chrome 104. Quy định hạn chế này chỉ áp dụng ở chế độ cảnh báo. Giới hạn thời gian chờ đặc biệt sẽ bị xoá sau khi bật chế độ thực thi bằng cách chuyển "Tuân thủ kết quả của quy trình kiểm tra trước quyền truy cập vào mạng riêng tư" thành "Đã bật" trong chrome://flags và giới hạn mặc định là 5 giây.
Trong Chrome 113 sớm nhất:
- Việc này sẽ chỉ bắt đầu nếu và khi dữ liệu về khả năng tương thích cho biết rằng thay đổi đó đủ an toàn và chúng tôi đã liên hệ trực tiếp khi cần.
- Chrome thực thi yêu cầu là các yêu cầu trước khi bay phải thành công, nếu không sẽ từ chối các yêu cầu đó.
- Chương trình thử nghiệm ngừng sử dụng bắt đầu đồng thời để cho phép các trang web chịu ảnh hưởng của giai đoạn này có thể yêu cầu gia hạn. Bản dùng thử sẽ kéo dài ít nhất 6 tháng.

Quyền truy cập mạng riêng tư (PNA) là gì?

Quyền truy cập mạng riêng (trước đây gọi là CORS-RFC1918) hạn chế khả năng các trang web gửi yêu cầu đến máy chủ trên mạng riêng.

Chrome đã triển khai một phần thông số kỹ thuật: kể từ Chrome 96, chỉ những ngữ cảnh an toàn mới được phép gửi yêu cầu mạng riêng. Hãy tham khảo bài đăng trước trên blog của chúng tôi để biết thông tin chi tiết.

Quy cách này cũng mở rộng giao thức Chia sẻ tài nguyên trên nhiều nguồn gốc (CORS) để giờ đây, các trang web phải yêu cầu cấp quyền một cách rõ ràng từ các máy chủ trên mạng riêng trước khi được phép gửi các yêu cầu tuỳ ý.

Thuật ngữ chính: Yêu cầu mạng riêng tư là những yêu cầu có địa chỉ IP của máy chủ mục tiêu riêng tư hơn địa chỉ IP mà trình khởi tạo yêu cầu được tìm nạp. Ví dụ: yêu cầu từ một trang web công khai (https://example.com) đến một trang web riêng tư (http://router.local) hoặc yêu cầu từ một trang web riêng tư đến máy chủ cục bộ.

Cách PNA phân loại địa chỉ IP và xác định mạng riêng tư

Địa chỉ IP được phân loại thành 3 không gian địa chỉ IP: - public - private - local

Không gian địa chỉ IP cục bộ chứa các địa chỉ IP là địa chỉ quay lại IPv4 (127.0.0.0/8) được xác định trong phần 3.2.1.3 của RFC1122 hoặc địa chỉ quay lại IPv6 (::1/128) được xác định trong phần 2.5.3 của RFC4291.

Không gian địa chỉ IP riêng chứa các địa chỉ IP chỉ có ý nghĩa trong mạng hiện tại, bao gồm 10.0.0.0/8, 172.16.0.0/12 và 192.168.0.0/16 được xác định trong RFC1918, địa chỉ liên kết cục bộ 169.254.0.0/16 được xác định trong RFC3927, địa chỉ unicast IPv6 cục bộ duy nhất fc00::/7 được xác định trong RFC4193, địa chỉ unicast IPv6 liên kết cục bộ fe80::/10 được xác định trong mục 2.5.6 của RFC4291 và địa chỉ IPv6 được ánh xạ IPv4, trong đó địa chỉ IPv4 được ánh xạ là địa chỉ riêng.

Không gian địa chỉ IP công khai chứa tất cả địa chỉ khác không được đề cập trước đó.

Địa chỉ IP cục bộ được coi là riêng tư hơn so với địa chỉ IP riêng tư và được coi là riêng tư hơn so với địa chỉ IP công khai.

Yêu cầu là riêng tư khi một mạng có nhiều khả năng hoạt động gửi yêu cầu đến một mạng có ít khả năng hoạt động hơn. — Mối quan hệ giữa mạng công cộng, mạng riêng và mạng cục bộ trong Quyền truy cập mạng riêng (CORS-RFC1918)

Tìm hiểu thêm tại bài viết Muốn nhận ý kiến phản hồi: CORS cho mạng riêng (RFC1918).

Yêu cầu kiểm tra trước

Thông tin khái quát

Yêu cầu trước khi bay là một cơ chế do tiêu chuẩn Chia sẻ tài nguyên trên nhiều nguồn gốc (CORS) đưa ra, dùng để yêu cầu quyền từ một trang web mục tiêu trước khi gửi yêu cầu HTTP có thể có tác dụng phụ. Điều này đảm bảo rằng máy chủ mục tiêu hiểu được giao thức CORS và giảm đáng kể nguy cơ bị tấn công CSRF.

Yêu cầu cấp quyền được gửi dưới dạng yêu cầu HTTP OPTIONS có các tiêu đề yêu cầu CORS cụ thể mô tả yêu cầu HTTP sắp tới. Phản hồi phải có các tiêu đề phản hồi CORS cụ thể đồng ý một cách rõ ràng với yêu cầu sắp tới.

Sơ đồ trình tự thể hiện quy trình kiểm tra trước CORS. Yêu cầu OPTIONS HTTP sẽ được gửi đến mục tiêu và trả về trạng thái 200 OK. Sau đó, tiêu đề yêu cầu CORS sẽ được gửi, trả về tiêu đề phản hồi CORS

Tính năng mới trong quyền Truy cập vào mạng riêng

Một cặp tiêu đề yêu cầu và phản hồi mới được giới thiệu cho các yêu cầu trước khi bay:

Access-Control-Request-Private-Network: true được đặt trên tất cả các yêu cầu kiểm tra trước của PNA
Phải đặt Access-Control-Allow-Private-Network: true trên tất cả các phản hồi trước chuyến bay PNA

Yêu cầu trước khi bay cho PNA được gửi cho tất cả các yêu cầu mạng riêng, bất kể phương thức yêu cầu và chế độ. Các yêu cầu này được gửi trước các yêu cầu ở chế độ cors cũng như no-cors và tất cả các chế độ khác. Lý do là mọi yêu cầu mạng riêng đều có thể được dùng cho các cuộc tấn công CSRF, bất kể chế độ yêu cầu và nội dung phản hồi có được cung cấp cho trình khởi tạo hay không.

Lưu ý: Nếu yêu cầu mạng riêng tư được thực hiện ở chế độ cors, thì bạn phải đặt tiêu đề CORS trên phản hồi cuối cùng, ngoài phản hồi trước khi bay.

Yêu cầu trước khi truyền đối với PNA cũng được gửi đối với các yêu cầu cùng nguồn gốc nếu địa chỉ IP mục tiêu có tính riêng tư cao hơn so với trình khởi tạo. Điều này không giống như CORS thông thường, trong đó các yêu cầu trước khi bay chỉ dành cho các yêu cầu trên nhiều nguồn gốc. Các yêu cầu trước khi bay cho các yêu cầu cùng nguồn gốc giúp ngăn chặn các cuộc tấn công liên kết lại DNS.

Ví dụ

Hành vi có thể quan sát được phụ thuộc vào chế độ của yêu cầu.

Chế độ không-CORS

Giả sử https://foo.example/index.html nhúng <img src="https://bar.example/cat.gif" alt="dancing cat"/> và bar.example phân giải thành 192.168.1.1, một địa chỉ IP riêng tư theo RFC 1918.

Trước tiên, Chrome sẽ gửi một yêu cầu kiểm tra trước:

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

Để yêu cầu này thành công, máy chủ phải phản hồi bằng:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

Cảnh báo: Máy chủ có thể đặt Access-Control-Allow-Origin: *, mặc dù việc này rất nguy hiểm và không nên thực hiện. Hiếm khi tất cả nguồn gốc có thể truy cập vào tài nguyên mạng riêng, vì vậy, hãy cân nhắc kỹ các rủi ro liên quan đến việc đặt tiêu đề như vậy.

Sau đó, Chrome sẽ gửi yêu cầu thực tế:

HTTP/1.1 GET /cat.gif
...

Mà máy chủ có thể phản hồi bình thường.

Chế độ CORS

Giả sử https://foo.example/index.html chạy mã sau:

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

Xin nhắc lại, hãy nói bar.example phân giải thành 192.168.1.1.

Trước tiên, Chrome sẽ gửi một yêu cầu kiểm tra trước:

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

Để yêu cầu này thành công, máy chủ phải phản hồi bằng:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

Sau đó, Chrome sẽ gửi yêu cầu thực tế:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

Mà máy chủ có thể phản hồi theo các quy tắc CORS thông thường:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

Cách biết liệu trang web của bạn có bị ảnh hưởng hay không

Kể từ Chrome 104, nếu phát hiện thấy một yêu cầu mạng riêng tư, thì một yêu cầu trước khi bay sẽ được gửi trước yêu cầu đó. Nếu yêu cầu kiểm tra này không thành công, thì yêu cầu cuối cùng sẽ vẫn được gửi nhưng một cảnh báo sẽ xuất hiện trong bảng điều khiển các vấn đề về Công cụ cho nhà phát triển.

Cảnh báo yêu cầu trước chuyến bay không thành công trong bảng điều khiển Vấn đề của công cụ cho nhà phát triển. Trạng thái này nêu rõ:
hãy đảm bảo chỉ gửi yêu cầu mạng riêng cho những tài nguyên cho phép,
cùng với thông tin chi tiết về yêu cầu cụ thể và liệt kê những tài nguyên bị ảnh hưởng.

Bạn cũng có thể xem và chẩn đoán các yêu cầu trước khi bay bị ảnh hưởng trong bảng điều khiển mạng:

Yêu cầu trước khi bay không thành công trong bảng điều khiển Mạng của DevTools cho máy chủ cục bộ sẽ đưa ra trạng thái 501.

Nếu yêu cầu của bạn đã kích hoạt một quy trình kiểm tra CORS thông thường mà không có quy tắc Quyền truy cập mạng riêng tư, thì hai lượt kiểm tra có thể xuất hiện trong bảng điều khiển mạng, trong đó lượt kiểm tra đầu tiên có vẻ như luôn không thành công. Đây là một lỗi đã biết và bạn có thể yên tâm bỏ qua lỗi này.

Một yêu cầu kiểm tra trước không thành công giả mạo trước một yêu cầu kiểm tra trước thành công trong bảng điều khiển Mạng của DevTools.

Để xem xét những gì sẽ xảy ra nếu quá trình kiểm tra trước khi khởi chạy thành công, bạn có thể chuyển đối số dòng lệnh sau, bắt đầu từ Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Mọi yêu cầu trước khi bay không thành công sẽ dẫn đến việc tìm nạp không thành công. Điều này cho phép bạn kiểm thử xem trang web của mình có hoạt động sau giai đoạn thứ hai của kế hoạch triển khai hay không. Bạn có thể chẩn đoán lỗi theo cách tương tự như cảnh báo bằng các bảng điều khiển DevTools được đề cập ở trên.

Việc cần làm nếu trang web của bạn bị ảnh hưởng

Khi thay đổi này được triển khai trong Chrome 104, dự kiến sẽ không có trang web nào bị lỗi. Tuy nhiên, bạn nên cập nhật các đường dẫn yêu cầu bị ảnh hưởng để đảm bảo trang web của bạn vẫn chạy như dự kiến.

Bạn có hai giải pháp:

Xử lý các yêu cầu kiểm tra trước ở phía máy chủ
Tắt tính năng kiểm tra PNA bằng chính sách doanh nghiệp

Xử lý yêu cầu kiểm tra trước ở phía máy chủ

Cập nhật máy chủ mục tiêu của mọi lượt tìm nạp bị ảnh hưởng để xử lý các yêu cầu trước chuyến bay của PNA. Trước tiên, hãy triển khai tính năng hỗ trợ cho các yêu cầu kiểm tra CORS chuẩn trên các tuyến bị ảnh hưởng. Sau đó, hãy thêm tính năng hỗ trợ cho hai tiêu đề phản hồi mới.

Khi nhận được yêu cầu kiểm tra trước (yêu cầu OPTIONS có tiêu đề CORS), máy chủ sẽ kiểm tra xem có tiêu đề Access-Control-Request-Private-Network: true hay không. Nếu tiêu đề này có trong yêu cầu, máy chủ phải kiểm tra tiêu đề Origin và đường dẫn yêu cầu cùng với mọi thông tin khác có liên quan (chẳng hạn như Access-Control-Request-Headers) để đảm bảo yêu cầu đó an toàn khi cho phép. Thông thường, bạn nên cho phép truy cập vào một nguồn gốc duy nhất mà bạn kiểm soát.

Sau khi quyết định cho phép yêu cầu, máy chủ sẽ phản hồi 204 No Content (hoặc 200 OK) bằng các tiêu đề CORS cần thiết và tiêu đề PNA mới. Các tiêu đề này bao gồm Access-Control-Allow-Origin và Access-Control-Allow-Private-Network: true, cũng như các tiêu đề khác nếu cần.

Hãy tham khảo ví dụ để biết các trường hợp cụ thể.

Tắt tính năng kiểm tra Quyền truy cập mạng riêng bằng chính sách doanh nghiệp

Nếu có quyền quản trị đối với người dùng, bạn có thể tắt tính năng kiểm tra Quyền truy cập vào mạng riêng bằng một trong các chính sách sau:

Để biết thêm thông tin, hãy tham khảo bài viết Tìm hiểu về việc quản lý chính sách đối với Chrome.

Gửi phản hồi cho chúng tôi

Nếu bạn đang lưu trữ một trang web trong một 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, 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. Hãy cho chúng tôi biết bằng cách gửi vấn đề về Chromium tại crbug.com và đặt thành phần thành Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Bước tiếp theo

Tiếp theo, Chrome sẽ mở rộng quy trình kiểm tra Quyền truy cập mạng riêng để bao gồm cả worker web: worker chuyên dụng, worker dùng chung và worker dịch vụ. Chúng tôi dự kiến sẽ bắt đầu hiển thị cảnh báo trong Chrome 107.

Sau đó, Chrome sẽ mở rộng quy trình kiểm tra Quyền truy cập mạng riêng tư để bao gồm cả các thao tác điều hướng, bao gồm cả iframe và cửa sổ bật lên. Chúng tôi dự kiến sẽ cho Chrome 108 bắt đầu hiển thị cảnh báo.

Trong cả hai trường hợp, chúng tôi sẽ tiến hành thận trọng với lộ trình triển khai theo giai đoạn tương tự, để các nhà phát triển web có thời gian điều chỉnh và ước tính rủi ro về khả năng tương thích.

Lời cảm ơn

Ảnh bìa của Mark Olsen trên Unsplash.