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

Định nghĩa "cùng trang web" đang được phát triển để bao gồm lược đồ URL, vì vậy, những đườ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 sự cố 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.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Cùng trang web điều chỉnh định nghĩa của một trang web (web) chỉ từ miền có thể đăng ký thành giao thức + miền có thể đăng ký. Bạn có thể xem thêm thông tin chi tiết và ví dụ trong phần 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 phải lo lắng về bất kỳ điều gì. Sẽ không có gì thay đổi đối với bạn.

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

Bạn có thể bật các thay đổi này để thử nghiệm trong cả Chrome và Firefox.

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

Một trong những lý do chính khiến SameSite=Lax được đặt làm mặc định cho cookie là để ngăn chặn 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 là cơ hội để kẻ tấn công mạng can thiệp vào các cookie. Các cookie này sau đó sẽ được dùng trên phiên bản HTTPS bảo mật của trang web. Việc tạo ranh giới bổ sung trên nhiều trang web này giữa các giao thức giúp tăng cường khả năng bảo vệ chống lại các cuộc tấn công này.

Các trường hợp phổ biến trên nhiều giao thức

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

Thao tác điều hướng trên nhiều giao thức được kích hoạt bằng cách đi theo một đường liên kết trên phiên bản HTTP không an toàn của trang web đến phiên bản HTTPS bảo mật. Đã chặn cookie SameSite=Strict, SameSite=Lax và SameSite=None; Cho phép cookie bảo mật.
Điều hướng trên nhiều lược đồ từ HTTP sang HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bị chặn ⛔ Bị chặn
SameSite=Lax ✓ Được phép ✓ Được phép
SameSite=None;Secure ✓ Được phép ⛔ Bị chặn

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

Mọi thay đổi bạn thực hiện ở đây chỉ nên được xem là bản sửa lỗi tạm thời trong khi bạn 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 Tìm nạp.

Trước đây, việc tải 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. Hiện tại, việc này được xử lý giống như mọi tài nguyên phụ khác trên nhiều trang web hoặc của bên thứ ba. Điều này có nghĩa là mọi cookie SameSite=Strict hoặc SameSite=Lax đều 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 thủ đoạn không an toàn trên một trang an toàn, thì tất cả cookie cũng 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 cần có Secure.

Tài nguyên phụ trên nhiều lược đồ bắt nguồn từ một tài nguyên từ phiên bản HTTPS bảo mật của trang web và được đưa vào phiên bản HTTP không an toàn. Đã chặn cookie SameSite=Strict và SameSite=Lax và SameSite=None; Cho phép cookie bảo mật.
Một trang HTTP có một tài nguyên phụ trên nhiều lược đồ thông qua HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bị chặn ⛔ Bị chặn
SameSite=Lax ⛔ Bị chặn ⛔ Bị chặn
SameSite=None;Secure ✓ Được phép ⛔ Bị chặn

ĐĂNG biểu mẫu

Trước đây, việc đăng giữa các phiên bản trên nhiều lược đồ của một trang web sẽ cho phép gửi các cookie được đặt bằng SameSite=Lax hoặc SameSite=Strict. Hiện tại, hoạt động này được coi là 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 trường hợp này trên các trang web hiển thị phiên bản không an toàn theo mặc định, nhưng hãy nâng cấp người dùng lên phiên bản bảo mật khi gửi biểu mẫu đăng nhập hoặc thanh toán.

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

Lượt gửi biểu mẫu trên nhiều lược đồ từ một biểu mẫu trên phiên bản HTTP không an toàn của trang web đang được gửi đến phiên bản HTTPS bảo mật. Đã chặn cookie SameSite=Strict và SameSite=Lax và SameSite=None; Cho phép cookie bảo mật.
Gửi biểu mẫu trên nhiều giao thức từ HTTP sang HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bị chặn ⛔ Bị chặn
SameSite=Lax ⛔ Bị chặn ⛔ Bị chặn
SameSite=None;Secure ✓ Được phép ⛔ Bị chặn

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

Công cụ và tính năng nhắn tin dành cho nhà phát triển có trên Chrome và Firefox.

Từ Chrome 86, thẻ Vấn đề trong DevTools sẽ bao gồm các vấn đề Giao diện cùng trang web theo lược đồ. Bạn có thể thấy các vấn đề sau đây được đánh dấu cho trang web của mình.

Vấn đề về lộ trình di chuyển:

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

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

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

Bạn có thể xem thêm thông tin chi tiết trong bài viết Các mẹo kiểm thử và gỡ lỗi cho cùng trang web có lược đồ.

Từ Firefox 79, với 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 đề có giao diện cùng trang web theo lược đồ. 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ì giao thức này không khớp."
  • "Cookie cookie_name đã được coi là trên nhiều trang web dựa trên http://site.example/ do giao thức này không khớp."

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

Trang web của tôi đã có đầy đủ tính năng trên HTTPS, tại sao tôi lại gặp sự cố trong Công cụ cho nhà phát triển 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à lệnh includeSubDomain. Với HSTS + includeSubDomain ngay cả khi một trong các trang của bạn vô tình chứa một đường liên kết không an toàn, trình duyệt cũng sẽ tự động sử dụng phiên bản bảo mật.

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

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 liên hệ 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 sẽ 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 việc di chuyển trang web của mình sau 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 biện pháp 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 các biện pháp bảo vệ xuống None.
    • Giải pháp này sẽ không thành công nếu URL mà bạn gửi cookie đến (hoặc đặt qua URL đó) không an toàn. Nguyên nhân 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 cookie đó cho đến khi trang web của bạn được nâng cấp lên HTTPS.
    • Hãy nhớ rằng đây chỉ là 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 như thế nào đến cookie của tôi nếu tôi chưa chỉ định thuộc tính SameSite?

Những 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 giao thức cũng sẽ áp dụng cho các cookie này. Xin lưu ý rằng ngoại lệ tạm thời đối với các phương thức không an toàn vẫn áp dụng. Hãy xem phần Giảm thiểu thao tác mở rộng và POST trong phần Câu hỏi thường gặp về SameSite của Chromium để biết thêm thông tin.

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

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

Cùng trang web:

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

Trên nhiều trang web:

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

Ảnh chụp của Julissa Capdevilla trên Unsplash