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

Bản 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 không gian địa chỉ IP.
Ngày 27 tháng 4 năm 2022: Thông báo mới về 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 thấy các 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 trên mạng riêng tư từ các trang web công khai trong quy cách Quyền truy cập mạng riêng (PNA).

Chrome sẽ bắt đầu gửi một yêu cầu kiểm tra 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 sự cho phép rõ ràng từ máy chủ đích. Yêu cầu kiểm tra này sẽ mang một tiêu đề mới là Access-Control-Request-Private-Network: true và phản hồi cho yêu cầu này phải có một tiêu đề tương ứng là 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 mục tiêu vào 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, tạo điều kiện cho kẻ tấn công chuyển hướng họ đến các máy chủ độc hại.

Gói phát hành

Chrome sẽ triển khai thay đổi này theo 2 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 kiểm tra trước các yêu cầu về tài nguyên phụ của mạng riêng.
- Lỗi trước khi kiểm tra 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à liên hệ với các trang web bị ảnh hưởng lớn nhất.
- Chúng tôi hy vọng phiên bản này tương thích rộng với các trang web hiện có.
Cảnh báo: Để hạn chế ảnh hưởng đến các trang web chưa hỗ trợ kiểm tra, thời gian chờ được giới hạn ở mức 200 mili giây trong Chrome 104. Quy định hạn chế này chỉ được á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ỳ chọn "Tôn trọng kết quả của các lượt kiểm tra quyền truy cập vào mạng riêng" thành "Đã bật" trong chrome://flags và giới hạn mặc định là 5 giây.
Sớm nhất có trong Chrome 113:
- Quá trình này sẽ chỉ bắt đầu nếu và khi dữ liệu về khả năng tương thích cho thấy sự thay đổi là đủ an toàn và chúng tôi đã liên hệ trực tiếp khi cần thiết.
- Chrome thực thi rằng các yêu cầu kiểm tra phải thành công, nếu không các yêu cầu đó sẽ không thành công.
- Thử nghiệm ngừng sử dụng bắt đầu cùng lúc để 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. Thời gian dùng thử sẽ kéo dài ít nhất 6 tháng.

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

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

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

Bản đặc tả kỹ thuật 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 rõ ràng từ máy chủ trên mạng riêng trước khi được phép gửi các yêu cầu tuỳ ý.

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

PNA phân loại địa chỉ IP và xác định mạng riêng bằng cách nào

Các địa chỉ IP được phân loại thành ba 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ỉ lặp lại IPv4 (127.0.0.0/8) được xác định trong mục 3.2.1.3 của RFC1122 hoặc địa chỉ lặp lại IPv6 (::1/128) được xác định trong mục 2.5.3 của RFC4291.

Không gian địa chỉ IP riêng tư chứa các địa chỉ IP có ý nghĩa chỉ 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 được ánh xạ cục bộ và địa chỉ IPv4 được ánh xạ cục bộ trong {RFC12} và địa chỉ IPv4 được ánh xạ cục bộ được xác định trong .fe80::/10RFC4291

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

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

Yêu cầu sẽ ở chế độ riêng tư khi một mạng khác hiện có sẵn gửi yêu cầu đến một mạng ít có sẵn hơn. — Mối quan hệ giữa các mạng công cộng, riêng tư 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 phần Ý kiến phản hồi: CORS cho mạng riêng (RFC1918).

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

Thông tin khái quát

Yêu cầu kiểm tra trước là cơ chế theo tiêu chuẩn Chia sẻ tài nguyên trên nhiều nguồn gốc (CORS) được 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 này được gửi dưới dạng một yêu cầu HTTP OPTIONS với các tiêu đề của yêu cầu CORS cụ thể mô tả yêu cầu HTTP sắp tới. Phản hồi phải chứa 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 CORS. Yêu cầu HTTP OPTIONS sẽ được gửi đến mục tiêu và trả về 200 OK. Sau đó, tiêu đề của yêu cầu CORS sẽ được gửi và trả về một tiêu đề phản hồi CORS

Tính năng mới về Quyền truy cập mạng riêng

Một cặp tiêu đề yêu cầu và phản hồi mới được đưa vào các yêu cầu kiểm tra:

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

Các yêu cầu chuẩn bị trước cho PNA được gửi cho mọi yêu cầu mạng riêng, bất kể chế độ và phương thức yêu cầu là gì. Chúng đượ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. Nguyên nhân là do mọi yêu cầu mạng riêng tư đề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à liệu 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 được thực hiện ở chế độ cors, thì ngoài phản hồi kiểm tra, các tiêu đề CORS phải được đặt trên phản hồi cuối cùng.

Các yêu cầu kiểm tra trước cho PNA cũng được gửi cho các yêu cầu có cùng nguồn gốc, nếu địa chỉ IP mục tiêu mang tính riêng tư hơn so với trình tạo. Cơ chế này không giống như cơ chế xử lý coroutine thông thường, trong đó các yêu cầu kiểm tra chỉ dành cho các yêu cầu trên nhiều nguồn gốc. Các yêu cầu kiểm tra trước cho các yêu cầu cùng nguồn gốc giúp bảo vệ khỏi 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 phụ thuộc vào chế độ của yêu cầu.

Chế độ không có 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:

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ù cách này nguy hiểm và không được khuyến khích. Tài nguyên mạng riêng hiếm khi truy cập được vào tất cả các nguồn gốc. Vì vậy, hãy suy nghĩ kỹ về những 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',
})

Một lần nữa, giả sử 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:

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

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

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

Cách để biết 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ì yêu cầu kiểm tra 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 vẫn sẽ được gửi nhưng cảnh báo sẽ xuất hiện trong bảng điều khiển vấn đề cho Công cụ cho nhà phát triển.

Cảnh báo về yêu cầu kiểm tra không thành công trong bảng Các vấn đề của Devtools. Trạng thái này: đảm bảo chỉ gửi yêu cầu mạng riêng đến các 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à danh sách các 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 kiểm tra bị ảnh hưởng trong bảng điều khiển mạng:

Yêu cầu kiểm tra không thành công trong bảng điều khiển Mạng cho nhà phát triển của 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 lượt 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ì 2 lượt kiểm tra trước có thể xuất hiện trong bảng điều khiển mạng, trong đó lượt đầu tiên có vẻ như không thực hiện được. Đây là 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 giả mạo không thành công trước khi kiểm tra thành công trong
bảng điều khiển Mạng Công cụ cho nhà phát triển.

Để xem điều gì sẽ xảy ra nếu thực thi thành công yêu cầu kiểm tra trước, bạn có thể chuyển đối số dòng lệnh sau đây, kể từ Chrome 98:

--enable-features=PrivateNetworkAccessRespectPreflightResults

Mọi yêu cầu kiểm tra không thành công đều sẽ dẫn đến việc tìm nạp không thành công. Nhờ đó, bạn có thể kiểm tra xem trang web của mình có hoạt động sau khi giai đoạn thứ hai của kế hoạch ra mắt chúng tôi ra mắt hay không. Cách chẩn đoán lỗi giống như các cảnh báo bằng cách sử dụng các bảng điều khiển Công cụ cho nhà phát triển nêu 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 thay đổi này sẽ không làm hỏng bất kỳ trang web nào. 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 mình vẫn chạy như dự kiến.

Có 2 giải pháp dành cho bạn:

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

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

Cập nhật máy chủ mục tiêu của mọi lần tìm nạp bị ảnh hưởng để xử lý các yêu cầu kiểm tra 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 tiêu 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 một yêu cầu kiểm tra (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 xuất hiện trong yêu cầu, máy chủ sẽ 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 thuộc quyền kiểm soát của mình.

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) với 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.

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

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

Nếu có quyền kiểm soát quản trị đối với người dùng của mình, bạn có thể tắt các chế độ kiểm tra Quyền truy cập mạng riêng tư 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 của 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 và dự kiến nhận được yêu cầu từ các mạng công khai, thì nhóm Chrome sẽ quan tâm đến ý kiến phản hồi và các trường hợp sử dụng của bạn. Hãy cho chúng tôi biết bằng cách báo cáo vấn đề với Chromium tại crbug.com và đặt thành phần thành Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Các bước tiếp theo

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

Sau đó, Chrome sẽ mở rộng các bước kiểm tra Quyền truy cập mạng riêng để xem 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ẽ nhắm đến Chrome 108 để bắt đầu hiển thị cảnh báo.

Trong cả hai trường hợp, chúng tôi sẽ triển khai một cách thận trọng việc phát hành 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.

Xác nhận

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