Thông tin cập nhật
Ngày 23 tháng 3 năm 2023: Tiến trình này đã được cập nhật và việc ngừng sử dụng sẽ không diễn ra cho đến Chrome 117.
Ngày 19 tháng 1 năm 2023: Tiến trình đã được cập nhật và việc ngừng sử dụng sẽ không diễn ra cho đến Chrome 114.
Ngày 12 tháng 8 năm 2022: Tiến trình đã được cập nhật và việc ngừng sử dụng sẽ không diễn ra cho đến Chrome 109.
Ngày 10 tháng 2 năm 2022: Một bài viết mới được đăng tại trang Private Network Access: giới thiệu các quy trình kiểm tra
Ngày 25 tháng 8 năm 2021: Thông báo cập nhật về tiến trình và giới thiệu bản dùng thử ngừng sử dụng.
Chrome sẽ ngừng hỗ trợ quyền truy cập vào các điểm cuối mạng riêng tư từ các trang web không an toàn theo thông số kỹ thuật về Quyền truy cập mạng riêng. Mục đích của tính năng này 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 các bộ định tuyến và thiết bị khác trên mạng riêng tư. 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.
Chrome sẽ ra mắt các thay đổi sau:
- Chặn các yêu cầu đến mạng riêng từ các trang web công cộng không an toàn kể từ Chrome 94.
- Giới thiệu bản dùng thử không dùng nữa mà sẽ kết thúc bằng Chrome
- Điều này sẽ cho phép nhà phát triển yêu cầu gia hạn thời gian cho các nguồn gốc đã chọn. Các nguồn gốc này sẽ không bị ảnh hưởng trong thời gian thử nghiệm ngừng sử dụng.
- Giới thiệu một chính sách của Chrome cho phép các bản triển khai Chrome được quản lý bỏ qua việc ngừng sử dụng vĩnh viễn. Có trong Chrome 92.
Nếu bạn cần thêm thời gian để giảm thiểu tác động của sổ đăng ký ngừng sử dụng trong quá trình dùng thử ngừng hoạt động.
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ể bật lại tính năng này bằng các chính sách của Chrome.
Để giảm thiểu tác động của các quy định hạn chế mới, hãy sử dụng một trong các chiến lược sau:
- Nâng cấp trang web của bạn lên HTTPS và máy chủ mục tiêu nếu cần.
- Nâng cấp trang web lên HTTPS và sử dụng WebTransport.
- Đảo ngược mối quan hệ nhúng.
Dòng thời gian
- Tháng 11 năm 2020: Cuộc gọi phản hồi về những thay đổi sắp tới.
- Tháng 3 năm 2021: Sau khi xem xét ý kiến phản hồi và liên hệ, chúng tôi sẽ thông báo về những thay đổi sắp tới. Thông số kỹ thuật được đổi tên từ CORS-RFC1918 thành Quyền truy cập mạng riêng.
- Tháng 4 năm 2021: Chrome 90 ra mắt phiên bản ổn định, hiển thị cảnh báo về việc ngừng sử dụng.
- Tháng 6 năm 2021: Chrome 92 ra mắt phiên bản Beta, cấm các yêu cầu mạng riêng tư từ các ngữ cảnh không an toàn. Sau khi nhà phát triển phản hồi rằng họ cần thêm thời gian để điều chỉnh, việc ngừng sử dụng sẽ được hoãn sang Chrome 93, cùng với một Bản dùng thử ngừng sử dụng.
- Tháng 7 năm 2021: Sau khi nhận được thêm ý kiến phản hồi của nhà phát triển, việc ngừng sử dụng và bản dùng thử đi kèm sẽ được hoãn sang Chrome 94. Ngoài ra, việc ngừng sử dụng này không còn ảnh hưởng đến các trang web riêng tư.
- Tháng 8 năm 2021: Chrome 94 ra mắt phiên bản Beta. Nhà phát triển web có thể bắt đầu đăng ký phiên bản dùng thử khi ngừng sử dụng.
- Tháng 9 năm 2021: Chrome 94 ra mắt phiên bản ổn định. Nhà phát triển web phải đăng ký dùng thử tính năng ngừng sử dụng và triển khai mã thông báo dùng thử cho phiên bản chính thức.
- Tháng 12 năm 2022: Gửi bản khảo sát về chương trình dùng thử Origin và nhận được ý kiến phản hồi. Bản dùng thử ngừng hoạt động được mở rộng cho Chrome 113.
- Tháng 3 năm 2023: Bản dùng thử ngừng sử dụng được mở rộng đến Chrome 116 và dự kiến sẽ kết thúc trong Chrome 117. Chúng tôi đang phát triển một cơ chế thay thế dựa trên quyền, dự kiến sẽ phát hành lần đầu trong Chrome 114.
- Tháng 5 năm 2023 (dự kiến): Cơ chế dựa trên quyền này ra mắt trong Chrome 114. Các trang web có thể sử dụng URL này để thoát khỏi quá trình thử nghiệm ngừng sử dụng.
- Tháng 9 năm 2023: Chrome 117 ra mắt phiên bản ổn định, kết thúc giai đoạn thử nghiệm ngừng sử dụng. Chrome chặn tất cả các yêu cầu mạng riêng tư từ các ngữ cảnh công khai, không an toàn.
Quyền truy cập mạng riêng tư 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. API này chỉ cho phép các yêu cầu như vậy từ ngữ cảnh bảo mậ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) để các trang web hiện phải yêu cầu cấp phép rõ ràng từ các máy chủ trên mạng riêng tư trước khi được phép gửi yêu cầu tuỳ ý.
Yêu cầu mạng riêng là các yêu cầu có địa chỉ IP của máy chủ mục tiêu riêng tư hơn so với địa chỉ IP của 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ộ.
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).
Thử nghiệm ngừng sử dụng là gì
Bản dùng thử ngừng sử dụng (trước đây gọi là bản dùng thử theo nguyên gốc đảo ngược) là một dạng bản dùng thử theo nguyên gốc dùng để giảm thiểu việc ngừng sử dụng các tính năng web. Các thử nghiệm ngừng sử dụng cho phép Chrome ngừng sử dụng một số tính năng web nhất định và ngăn các trang web tạo các phần phụ thuộc mới trên các tính năng đó, đồng thời cho phép các trang web phụ thuộc hiện tại thêm thời gian để di chuyển khỏi các tính năng đó.
Trong thời gian dùng thử tính năng ngừng hoạt động, theo mặc định, tất cả các trang web sẽ không sử dụng được các tính năng ngừng hoạt động. Những nhà phát triển vẫn cần sử dụng các tính năng bị ảnh hưởng phải đăng ký dùng thử tính năng ngừng sử dụng và lấy mã thông báo cho các nguồn gốc web được chỉ định, sau đó sửa đổi trang web của họ để phân phát các mã thông báo đó trong tiêu đề HTTP hoặc thẻ meta (ngoại trừ trường hợp này). Nếu một trang web phân phát mã thông báo hợp lệ khớp với nguồn gốc, thì Chrome sẽ cho phép sử dụng tính năng không dùng nữa trong một khoảng thời gian giới hạn.
Để biết thêm thông tin, hãy xem bài viết Bắt đầu sử dụng bản dùng thử theo nguyên gốc của Chrome và hướng dẫn dành cho nhà phát triển web về bản dùng thử theo nguyên gốc để biết hướng dẫn.
Những thay đổi trong Chrome
Chrome 94
Kể từ Chrome 94, các bối cảnh không an toàn công khai (nói chung là các trang web không được phân phối qua HTTPS hoặc từ địa chỉ IP riêng) sẽ bị cấm gửi yêu cầu đến mạng riêng. Trước đây, việc này được lên kế hoạch cho Chrome 92, do đó, thông báo ngừng sử dụng có thể vẫn đề cập đến mốc trước đó.
Việc ngừng sử dụng này đi kèm với một bản dùng thử không dùng nữa, cho phép các nhà phát triển web có trang web sử dụng tính năng không dùng nữa tiếp tục sử dụng tính năng đó cho đến Chrome 116 bằng cách đăng ký mã thông báo. Hãy xem bên dưới để biết hướng dẫn cách đăng ký và bật bản dùng thử trên trang web của bạn.
Bạn có thể tận dụng một cặp chính sách của Chrome để vô thời hạn tắt việc ngừng sử dụng hoàn toàn hoặc trên một số nguồn gốc cụ thể. Điều này cho phép các lượt cài đặt Chrome được quản lý, chẳng hạn như các lượt cài đặt trong chế độ cài đặt của công ty, tránh bị hỏng.
Chrome 117
Thời gian dùng thử tính năng ngừng sử dụng kết thúc. Tất cả trang web phải được di chuyển khỏi tính năng không dùng nữa hoặc chính sách của người dùng được định cấu hình để tiếp tục bật tính năng này.
Hành động được đề xuất cho nhà phát triển
Bước đầu tiên cho các trang web bị ảnh hưởng có nhiều khả năng là kéo dài thời gian cho đến khi có thể triển khai biện pháp khắc phục thích hợp: bằng cách đăng ký dùng thử tính năng ngừng sử dụng hoặc bằng cách sử dụng các chính sách. Sau đó, biện pháp hành động được đề xuất sẽ khác nhau tuỳ thuộc vào tình huống của từng trang web bị ảnh hưởng.
Đăng ký dùng thử tính năng ngừng sử dụng
- Nhấp vào Đăng ký cho Quyền truy cập mạng riêng tư từ bản dùng thử theo nguyên gốc ngữ cảnh không an toàn để lấy mã thông báo dùng thử cho nguồn gốc tham gia.
- Thêm
Origin-Trial: $tokendành riêng cho nguồn gốc vào tiêu đề phản hồi. Bạn chỉ cần đặt tiêu đề phản hồi này trên các phản hồi điều hướng và tài nguyên chính khi tài liệu thu được sử dụng tính năng không dùng nữa. Việc đính kèm tiêu đề này vào các phản hồi của tài nguyên phụ sẽ là vô ích (mặc dù vô hại).
Vì bạn phải bật hoặc tắt bản dùng thử này trước khi một tài liệu được phép thực hiện yêu cầu nào, nên bạn không thể bật bản dùng thử này thông qua thẻ <meta>. Các thẻ như vậy chỉ được phân tích cú pháp từ nội dung phản hồi sau khi có thể đã phát hành các yêu cầu về tài nguyên phụ. Điều này đặt ra một thách thức đối với các trang web không kiểm soát các tiêu đề phản hồi, chẳng hạn như các trang web tĩnh github.io do bên thứ ba phân phát.
Để biết thêm thông tin chi tiết, hãy xem Hướng dẫn dành cho nhà phát triển web về thử nghiệm gốc.
Bật chính sách
Nếu có quyền kiểm soát quản trị đối với người dùng, bạn có thể bật lại tính năng đã ngừng hoạt động bằng một trong các chính sách sau:
Để biết thêm thông tin chi tiết về cách quản lý chính sách cho người dùng, hãy xem bài viết này trong trung tâm trợ giúp.
Truy cập vào localhost
Nếu trang web của bạn cần đưa ra yêu cầu cho máy chủ cục bộ, thì bạn chỉ cần nâng cấp trang web lên HTTPS.
Nội dung hỗn hợp không chặn các yêu cầu nhắm đến http://localhost (hoặc http://127.*.*.*, http://[::1]), ngay cả khi các yêu cầu đó được đưa ra từ ngữ cảnh bảo mật.
Xin lưu ý rằng công cụ WebKit và các trình duyệt dựa trên công cụ này (đáng chú ý nhất là Safari) khác với thông số kỹ thuật Nội dung hỗn hợp của W3C tại đây và cấm các yêu cầu này dưới dạng Nội dung hỗn hợp. Các trình duyệt này cũng không triển khai tính năng Quyền truy cập mạng riêng tư, vì vậy, các trang web có thể muốn chuyển hướng ứng dụng sử dụng các trình duyệt đó đến phiên bản HTTP văn bản thuần tuý của trang web. Các trình duyệt này vẫn cho phép gửi yêu cầu đến máy chủ cục bộ.
Truy cập vào địa chỉ IP riêng tư
Nếu trang web của bạn cần gửi yêu cầu đến máy chủ mục tiêu trên địa chỉ IP riêng tư, thì bạn chỉ cần nâng cấp trang web của trình khởi tạo lên HTTPS là không hoạt động. Nội dung hỗn hợp ngăn các ngữ cảnh an toàn gửi yêu cầu qua HTTP văn bản thuần tuý, vì vậy, trang web mới được bảo mật vẫn không thể gửi yêu cầu. Có một số cách để giải quyết vấn đề này:
- Nâng cấp cả hai đầu lên HTTPS.
- Sử dụng WebTransport để kết nối an toàn với máy chủ mục tiêu.
- Đảo ngược mối quan hệ nhúng.
Nâng cấp cả hai đầu lên HTTPS
Giải pháp này yêu cầu quyền kiểm soát việc phân giải DNS của người dùng, chẳng hạn như trong ngữ cảnh mạng nội bộ hoặc nếu người dùng lấy địa chỉ của máy chủ tên từ một máy chủ DHCP mà bạn kiểm soát. Bạn cũng phải sở hữu tên miền công khai.
Vấn đề chính khi phân phối các trang web riêng tư qua HTTPS là các tổ chức phát hành chứng chỉ cơ sở hạ tầng khoá công khai (PKI CA) chỉ cung cấp chứng chỉ TLS cho các trang web có tên miền công khai. Cách khắc phục vấn đề này:
- Đăng ký tên miền công khai (ví dụ:
intranet.example) và phát hành các bản ghi DNS trỏ tên miền đó đến một máy chủ công khai mà bạn chọn. - Nhận chứng chỉ TLS cho
intranet.example. - Bên trong mạng riêng tư, hãy định cấu hình DNS để phân giải
intranet.examplethành địa chỉ IP riêng tư của máy chủ mục tiêu. - Định cấu hình máy chủ riêng tư để sử dụng chứng chỉ TLS cho
intranet.example. Điều này cho phép người dùng truy cập vào máy chủ riêng tư tạihttps://intranet.example.
Sau đó, bạn có thể nâng cấp trang web khởi tạo các yêu cầu lên HTTPS và tiếp tục đưa ra các yêu cầu như trước.
Giải pháp này phù hợp cho tương lai và giúp bạn tin tưởng vào mạng của mình hơn, đồng thời mở rộng việc sử dụng phương thức mã hoá hai đầu trong mạng riêng tư.
WebTransport
Giải pháp này không yêu cầu kiểm soát quá trình phân giải DNS của người dùng. Phương thức này yêu cầu máy chủ mục tiêu chạy một máy chủ WebTransport tối thiểu (máy chủ HTTP/3 với một số sửa đổi).
Bạn có thể bỏ qua việc thiếu chứng chỉ TLS hợp lệ do một CA đáng tin cậy ký bằng cách sử dụng WebTransport và cơ chế ghim chứng chỉ. Điều này cho phép thiết lập các kết nối an toàn với các thiết bị riêng tư có thể có một chứng chỉ tự ký. Kết nối WebTransport cho phép chuyển dữ liệu hai chiều, nhưng không cho phép tìm nạp yêu cầu. Bạn có thể kết hợp phương pháp này với một worker dịch vụ để chuyển tiếp minh bạch các yêu cầu HTTP qua kết nối, từ quan điểm của ứng dụng web. Ở phía máy chủ, một lớp dịch tương ứng có thể chuyển đổi các thông báo WebTransport thành các yêu cầu HTTP.
Chúng tôi thừa nhận rằng đây là một khối lượng công việc khá lớn, nhưng sẽ dễ dàng hơn đáng kể so với việc xây dựng dựa trên WebRTC; chúng tôi cũng hy vọng rằng một số khoản đầu tư cần thiết sẽ được triển khai dưới dạng thư viện có thể sử dụng lại. Chúng tôi cũng cho rằng điều này đặc biệt đáng cân nhắc khi xem xét thực tế là các ngữ cảnh không an toàn có thể mất quyền truy cập vào ngày càng nhiều tính năng của nền tảng web khi nền tảng này chuyển hướng khuyến khích việc sử dụng HTTPS theo cách mạnh mẽ hơn theo thời gian. Dù có Quyền truy cập mạng riêng hay không, đây vẫn có thể là một khoản đầu tư khôn ngoan.
Chúng tôi dự kiến sẽ ra mắt WebTransport qua HTTP/3 trong Chrome 96 (đã bắt đầu dùng thử theo nguyên gốc) với các biện pháp giảm thiểu để bảo vệ khỏi việc chia sẻ khoá và các phương pháp bảo mật kém khác, bao gồm:
- Thời gian hết hạn tối đa ngắn cho các chứng chỉ được ghim.
- Cơ chế dành riêng cho trình duyệt để thu hồi một số khoá nhất định đã bị xâm phạm.
Chúng tôi sẽ không gửi quy tắc hạn chế theo bối cảnh bảo mật cho đến ít nhất 2 mốc quan trọng sau khi WebTransport được triển khai hoàn toàn. Thời gian thử nghiệm ngừng sử dụng sẽ được kéo dài nếu cần.
Nhúng ngược
Giải pháp này không yêu cầu quyền kiểm soát quản trị nào đối với mạng và có thể được sử dụng khi máy chủ mục tiêu không đủ mạnh để chạy HTTPS.
Thay vì tìm nạp tài nguyên phụ riêng tư từ một ứng dụng web công khai, khung của ứng dụng có thể được phân phát từ máy chủ riêng tư, sau đó tìm nạp tất cả tài nguyên phụ (chẳng hạn như tập lệnh hoặc hình ảnh) từ một máy chủ công khai, chẳng hạn như CDN. Sau đó, ứng dụng web thu được có thể gửi yêu cầu đến máy chủ riêng, vì các yêu cầu này được coi là cùng nguồn gốc. API này thậm chí có thể gửi yêu cầu đến các máy chủ khác có IP riêng tư (nhưng không phải máy chủ cục bộ), mặc dù điều này có thể thay đổi trong dài hạn.
Bằng cách chỉ lưu trữ một bộ khung trên máy chủ riêng tư, bạn có thể cập nhật ứng dụng web bằng cách đẩy tài nguyên mới lên máy chủ công khai, giống như cách bạn cập nhật một ứng dụng web công khai. Mặt khác, ứng dụng web thu được không phải là ngữ cảnh bảo mật nên không có quyền truy cập vào một số tính năng mạnh mẽ hơn của web.
Kế hoạch cho tương lai
Việc hạn chế các yêu cầu mạng riêng ở những ngữ cảnh an toàn chỉ là bước đầu tiên trong quá trình triển khai Quyền truy cập mạng riêng. Chrome đang nỗ lực triển khai phần còn lại của quy cách trong những tháng tới. Hãy chú ý theo dõi thông tin cập nhật nhé!
Hạn chế quyền truy cập máy chủ cục bộ từ các trang web riêng tư
Các thay đổi trong Chrome 94 chỉ ảnh hưởng đến các trang web công khai truy cập vào địa chỉ IP riêng tư hoặc máy chủ cục bộ. Thông số kỹ thuật về Quyền truy cập mạng riêng tư cũng phân loại các yêu cầu từ trang web riêng tư đến máy chủ cục bộ là có vấn đề. Chrome cũng sẽ ngừng sử dụng những tính năng này. Điều này đặt ra một nhóm thách thức hơi khác, tuy nhiên, vì nhiều trang web riêng tư không có tên miền, làm phức tạp việc sử dụng mã thông báo thử nghiệm ngừng sử dụng.
Yêu cầu kiểm tra trước CORS
Phần thứ hai của tính năng Quyền truy cập mạng riêng là kiểm soát các yêu cầu mạng riêng được bắt đầu từ các ngữ cảnh an toàn bằng yêu cầu kiểm tra trước CORS. Ý tưởng là ngay cả khi yêu cầu được bắt đầu từ một bối cảnh an toàn, máy chủ mục tiêu vẫn được yêu cầu cấp quyền rõ ràng cho bên khởi tạo. Yêu cầu chỉ được gửi nếu quá trình cấp quyền thành công.
Tóm lại, yêu cầu kiểm tra trước CORS là một yêu cầu OPTIONS HTTP chứa một số tiêu đề Access-Control-Request-* cho biết bản chất của yêu cầu tiếp theo. Sau đó, máy chủ có thể quyết định có cấp quyền truy cập chi tiết hay không bằng cách phản hồi 200 OK bằng các tiêu đề Access-Control-Allow-*.
Hãy xem thêm thông tin chi tiết về vấn đề này trong quy cách.
Hạn chế tìm nạp điều hướng
Chrome sẽ ngừng sử dụng và cuối cùng sẽ chặn các yêu cầu tài nguyên phụ đến mạng riêng tư. Việc này sẽ không ảnh hưởng đến việc điều hướng đến mạng riêng tư. Mạng riêng này cũng có thể được sử dụng trong các cuộc tấn công CSRF.
Quy cách về Quyền truy cập vào mạng riêng không phân biệt giữa hai loại tìm nạp, cuối cùng sẽ phải tuân theo các quy định hạn chế giống nhau.
Ảnh bìa của Markus Spiske trên Unsplash