Cùng trang web có lược đồ

Định nghĩa về "cùng trang web" đang phát triển để bao gồm cả lược đồ URL, vì vậy, các đường liên kết giữa phiên bản HTTP và HTTPS của một trang web hiện được tính là yêu cầu trên nhiều trang web. Nâng cấp lên HTTPS theo mặc định để tránh các vấn đề (nếu có thể) hoặc đọc tiếp để biết thông tin chi tiết về những giá trị thuộc tính SameSite cần thiết.

Steven Bingler

Rowan Merewood

Schemeful Same-Site sửa đổi định nghĩa về một trang web (trên web) từ chỉ miền có thể đăng ký thành lược đồ + miền có thể đăng ký. Bạn có thể xem thêm thông tin chi tiết và ví dụ trong bài viết Tìm hiểu về "same-site" và "same-origin".

Tin vui là: nếu trang web của bạn đã được nâng cấp hoàn toàn lên HTTPS thì bạn không cần lo lắng về bất cứ điều gì. Bạn sẽ không thấy có gì thay đổi.

Nếu bạn chưa nâng cấp hoàn toàn trang web của mình, thì đây là việc bạn nên ưu tiên. Tuy nhiên, nếu khách truy cập trang web của bạn chuyển đổi giữa HTTP và HTTPS, thì một số trường hợp phổ biến và hành vi liên quan của cookie SameSite sẽ được trình bày ở phần sau của bài viết này.

Bạn có thể bật những thay đổi này để kiểm thử trong cả Chrome và Firefox.

• Từ Chrome 86, hãy bật about://flags/#schemeful-same-site. Theo dõi tiến trình trên trang Chrome Status.
• Từ Firefox 79, hãy đặt network.cookie.sameSite.schemeful thành true thông qua about:config. Theo dõi tiến trình bằng cách sử dụng vấn đề Bugzilla.

Một trong những lý do chính khiến SameSite=Lax trở thành giá trị mặc định cho cookie là để bảo vệ khỏi Giả mạo yêu cầu trên nhiều trang web (CSRF). Tuy nhiên, lưu lượng truy cập HTTP không an toàn vẫn tạo cơ hội cho kẻ tấn công mạng can thiệp vào cookie, sau đó cookie sẽ được dùng trên phiên bản HTTPS an toàn của trang web. Việc tạo ranh giới bổ sung giữa các lược đồ trên nhiều trang web giúp tăng cường khả năng phòng vệ trước các cuộc tấn công này.

Các trường hợp phổ biến về việc sử dụng nhiều lược đồ

Di chuyển

Trước đây, việc điều hướng giữa các phiên bản khác giản đồ của một trang web (ví dụ: liên kết từ http://site.example đến https://site.example) sẽ cho phép gửi cookie SameSite=Strict. Giờ đây, thao tác này được coi là một thao tác điều hướng trên nhiều trang web, tức là cookie SameSite=Strict sẽ bị chặn.

Đang tải tài nguyên phụ

Mọi thay đổi bạn thực hiện tại đây chỉ nên được coi là một giải pháp tạm thời trong khi bạn tìm cách nâng cấp lên HTTPS đầy đủ.

Ví dụ về tài nguyên phụ bao gồm hình ảnh, iframe và các yêu cầu mạng được thực hiện bằng XHR hoặc Fetch.

Trước đây, việc tải một tài nguyên phụ trên nhiều lược đồ trên một trang sẽ cho phép gửi hoặc đặt cookie SameSite=Strict hoặc SameSite=Lax. Giờ đây, cookie này được xử lý giống như mọi tài nguyên phụ của bên thứ ba hoặc trên nhiều trang web khác. Điều này có nghĩa là mọi cookie SameSite=Strict hoặc SameSite=Lax sẽ bị chặn.

Ngoài ra, ngay cả khi trình duyệt cho phép tải tài nguyên từ các lược đồ không an toàn trên một trang an toàn, thì tất cả cookie sẽ bị chặn trong các yêu cầu này vì cookie của bên thứ ba hoặc cookie cross-site yêu cầu Secure.

Đăng biểu mẫu

Trước đây, việc đăng giữa các phiên bản chéo lược đồ của một trang web sẽ cho phép gửi cookie được đặt bằng SameSite=Lax hoặc SameSite=Strict. Giờ đây, yêu cầu này được coi là một yêu cầu POST trên nhiều trang web – chỉ có thể gửi cookie SameSite=None. Bạn có thể gặp phải trường hợp này trên những trang web mặc định hiển thị phiên bản không an toàn, nhưng nâng cấp người dùng lên phiên bản an toàn khi họ gửi biểu mẫu đăng nhập hoặc thanh toán.

Tương tự như tài nguyên phụ, nếu yêu cầu đến từ một bối cảnh bảo mật (ví dụ: HTTPS) đến một bối cảnh không bảo mật (ví dụ: HTTP), thì tất cả cookie sẽ bị chặn trong các yêu cầu này vì cookie của bên thứ ba hoặc cookie trên nhiều trang web yêu cầu Secure.

Làm cách nào để kiểm thử trang web của tôi?

Công cụ và thông báo dành cho nhà phát triển có trong Chrome và Firefox.

Kể từ Chrome 86, thẻ Vấn đề trong Công cụ cho nhà phát triển sẽ bao gồm các vấn đề về Schemeful Same-Site. Bạn có thể thấy những vấn đề sau đây được làm nổi bật cho trang web của mình.

Vấn đề về chỉ đường:

• "Di chuyển hoàn toàn sang HTTPS để tiếp tục gửi cookie trong các yêu cầu cùng trang web" – Cảnh báo rằng cookie sẽ bị chặn trong một phiên bản Chrome sau này.
• "Di chuyển hoàn toàn sang HTTPS để gửi cookie theo yêu cầu trên cùng một trang web" – Cảnh báo rằng cookie đã bị chặn.

Vấn đề khi tải tài nguyên phụ:

• "Di chuyển hoàn toàn sang HTTPS để tiếp tục gửi cookie đến các tài nguyên phụ cùng trang web" hoặc "Di chuyển hoàn toàn sang HTTPS để tiếp tục cho phép các tài nguyên phụ cùng trang web đặt cookie" – Cảnh báo rằng cookie sẽ bị chặn trong một phiên bản Chrome sau này.
• "Di chuyển hoàn toàn sang HTTPS để gửi cookie đến các tài nguyên phụ cùng trang web" hoặc "Di chuyển hoàn toàn sang HTTPS để cho phép các tài nguyên phụ cùng trang web đặt cookie" – Cảnh báo rằng cookie đã bị chặn. Cảnh báo thứ hai cũng có thể xuất hiện khi bạn đăng biểu mẫu.

Bạn có thể xem thêm thông tin chi tiết trong bài viết Mẹo kiểm thử và gỡ lỗi cho Schemeful Same-Site.

Kể từ Firefox 79, khi network.cookie.sameSite.schemeful được đặt thành true thông qua about:config, bảng điều khiển sẽ hiển thị thông báo về các vấn đề Schemeful Same-Site. Bạn có thể thấy những thông tin sau trên trang web của mình:

• "Cookie cookie_name sẽ sớm được coi là cookie trên nhiều trang web đối với http://site.example/ vì lược đồ không khớp."
• "Cookie cookie_name đã được coi là trên nhiều trang web đối với http://site.example/ vì lược đồ không khớp."

Câu hỏi thường gặp

Trang web của tôi đã hoàn toàn có sẵn trên HTTPS, tại sao tôi vẫn thấy vấn đề trong DevTools của trình duyệt?

Có thể một số đường liên kết và tài nguyên phụ của bạn vẫn trỏ đến các URL không an toàn.

Một cách để khắc phục vấn đề này là sử dụng HTTP Strict-Transport-Security (HSTS) và chỉ thị includeSubDomain. Với HSTS + includeSubDomain, ngay cả khi một trong các trang của bạn vô tình có một đường liên kết không an toàn, trình duyệt sẽ tự động sử dụng phiên bản an toàn thay thế.

Nếu tôi không thể nâng cấp lên HTTPS thì sao?

Mặc dù bạn nên nâng cấp toàn bộ trang web của mình lên HTTPS để bảo vệ người dùng, nhưng nếu không thể tự làm việc này, bạn nên trao đổi với nhà cung cấp dịch vụ lưu trữ để xem họ có thể cung cấp lựa chọn đó hay không. Nếu bạn tự lưu trữ, thì Let's Encrypt cung cấp một số công cụ để cài đặt và định cấu hình chứng chỉ. Bạn cũng có thể tìm hiểu về việc di chuyển trang web của mình ra sau một CDN hoặc proxy khác có thể cung cấp kết nối HTTPS.

Nếu vẫn không được, hãy thử nới lỏng chế độ bảo vệ SameSite đối với các cookie bị ảnh hưởng.

• Trong trường hợp chỉ có cookie SameSite=Strict bị chặn, bạn có thể giảm mức bảo vệ xuống Lax.
• Trong trường hợp cả cookie Strict và Lax đều bị chặn và cookie của bạn đang được gửi đến (hoặc được đặt từ) một URL bảo mật, bạn có thể giảm mức bảo vệ xuống None.
  • Biện pháp khắc phục này sẽ thất bại nếu URL mà bạn đang gửi cookie đến (hoặc đặt cookie từ đó) không an toàn. Điều này là do SameSite=None yêu cầu thuộc tính Secure trên cookie, tức là những cookie đó có thể không được gửi hoặc đặt qua một kết nối không an toàn. Trong trường hợp này, bạn sẽ không thể truy cập vào cookie đó cho đến khi trang web của bạn được nâng cấp lên HTTPS.
  • Xin lưu ý rằng đây chỉ là giải pháp tạm thời vì cuối cùng cookie của bên thứ ba sẽ bị loại bỏ hoàn toàn.

Điều này ảnh hưởng đến cookie của tôi như thế nào nếu tôi chưa chỉ định thuộc tính SameSite?

Cookie không có thuộc tính SameSite sẽ được xử lý như thể chúng chỉ định SameSite=Lax và hành vi trên nhiều lược đồ tương tự cũng áp dụng cho các cookie này. Xin lưu ý rằng trường hợp ngoại lệ tạm thời đối với các phương thức không an toàn vẫn được áp dụng, hãy xem Lax + biện pháp giảm thiểu POST trong SameSiteCâu hỏi thường gặp về Chromium để biết thêm thông tin.

WebSockets bị ảnh hưởng như thế nào?

Các kết nối WebSocket vẫn được coi là cùng trang web nếu chúng có cùng mức độ bảo mật như trang.

Same-site:

• wss:// kết nối từ https://
• ws:// kết nối từ http://

Nhiều trang web:

• wss:// kết nối từ http://
• ws:// kết nối từ https://