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

Định nghĩa về "same-site" đang phát triển để bổ sung lược đồ URL. Do đó, các đường liên kết giữa phiên bản HTTP và HTTPS của một trang web giờ đây được tính là yêu cầu trên nhiều trang web. Hãy nâng cấp lên giao thức HTTPS theo mặc định để tránh gặp phải các vấn đề (nếu có thể) hoặc đọc tiếp để biết thông tin chi tiết về việc cần có các giá trị thuộc tính SameSite.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Lập lịch trình Cùng trang web sửa đổi định nghĩa của một trang web (web) từ 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 Hiểu về "same-site" (cùng một trang web) 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 phải lo lắng về bất cứ điều gì. Sẽ không có gì thay đổi đối với bạn.

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

Bạn có thể bật những 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 Chrome .
  • Từ Firefox 79, đặt network.cookie.sameSite.schemeful thành true qua about:config. Theo dõi tiến trình qua Bugzilla .

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

Trường hợp trên nhiều lược đồ phổ biến

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

Một hoạt động điều hướng trên nhiều lượ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 một trang web đến phiên bản HTTPS bảo mật. SameSite=Cookie bị chặn, SameSite=Lax và SameSite=None; Cho phép các cookie an toàn.
Đ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 coi là biện pháp khắc phục tạm thời 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à yêu cầu mạng được thực hiện bằng XHR hoặc Fetch.

Tải một tài nguyên phụ trên nhiều lược đồ trên một trang mà trước đây cho phép SameSite=Strict hoặc SameSite=Lax cookie sẽ được gửi hoặc đặt. Bây giờ là được xử lý theo cách 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 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 không cho phép tài nguyên từ các giao thức không an toàn để được tải 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 trên nhiều trang web cần phải có Secure.

Tài nguyên phụ trên nhiều lược đồ tạo ra từ một tài nguyên từ phiên bản HTTPS bảo mật của trang web được đưa vào phiên bản HTTP không an toàn. Cookie SameSite=Strict và SameSite=Lax bị chặn và SameSite=None; Cho phép các cookie an toàn.
Một trang HTTP bao gồm 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 lược đồ chéo của một trang web sẽ cho phép cookie được đặt bằng SameSite=Lax hoặc SameSite=Strict sẽ được gửi. Bây giờ là được coi là POST trên nhiều trang web, tức là chỉ có thể gửi SameSite=None cookie. Bạn có thể gặp phải trường hợp này trên các trang web có 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 thông tin đăng nhập hoặc biểu mẫu thanh toán.

Giống như với tài nguyên phụ, nếu yêu cầu đến từ một nguồn bảo mật, ví dụ: HTTPS thành một không an toàn, ví dụ: HTTP, ngữ cảnh thì tất cả cookie sẽ bị chặn đối với 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 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 được gửi đến phiên bản HTTPS bảo mật. Cookie SameSite=Strict và SameSite=Lax bị chặn và SameSite=None; Cho phép các cookie an toàn.
Gửi biểu mẫu trên nhiều lượ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 để thử nghiệm trang web của tôi?

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

Trên Chrome 86, thẻ Vấn đề trong Công cụ cho nhà phát triển sẽ bao gồm các sự cố Cùng trang web có lược đồ. Bạn có thể thấy các vấn đề sau được đánh dấu cho trang web của bạn.

Vấn đề về việc đi theo chỉ dẫn:

  • "Di chuyển hoàn toàn sang HTTPS để tiếp tục nhận được cookie được gửi trên cùng một trang web yêu cầu"—Cảnh báo rằng cookie sẽ bị chặn trong một phiên bản tương lai của Chrome.
  • "Di chuyển hoàn toàn sang HTTPS để gửi cookie trên các yêu cầu trên cùng một trang web"—A cho biết 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 nhận được cookie được gửi đến cùng một trang web tài nguyên phụ" hoặc "Di chuyển hoàn toàn sang HTTPS để tiếp tục cho phép cookie được đặt bởi các tài nguyên phụ cùng trang web"—Cảnh báo rằng cookie sẽ được bị chặn trong 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ùng một trang web đặt cookie tài nguyên phụ"—Cảnh báo rằng cookie đã bị chặn. Chính sách sau cũng có thể xuất hiện khi POST một biểu mẫu.

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

Từ Firefox 79, với network.cookie.sameSite.schemeful được đặt thành true qua about:config bảng điều khiển sẽ hiển thị thông báo cho các vấn đề cùng trang web có lập trình. 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 xem là cookie trên nhiều trang web http://site.example/ vì lược đồ không khớp."
  • "Cookie cookie_name đã được coi là trên nhiều trang web 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 truy cập được trên HTTPS, tại sao tôi lại gặp vấn đề 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 đường liên kết không an toàn URL.

Một cách để khắc phục vấn đề này là sử dụng HTTP Nghiêm ngặt-Bảo mật truyền tải (HSTS) và lệnh includeSubDomain. Với HSTS + includeSubDomain đều nếu một trong các trang của bạn vô tình bao gồm một 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.

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 của bạn, nếu bạn không thể tự làm như vậy, chúng tôi khuyên bạn nên liên hệ với nhà cung cấp dịch vụ lưu trữ của bạn để xem họ có thể cung cấp lựa chọn đó không. Nếu bạn tự tổ chức, 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ể điều tra việc di chuyển trang web sau một mạng phân phối nội dung (CDN) hoặc proxy khác có thể cung cấp kết nối HTTPS.

Nếu cách đó vẫn không được, hãy thử giảm mức bảo vệ của SameSite trên cookie bị ảnh hưởng.

  • Trong trường hợp chỉ có SameSite=Strict cookie bị chặn, bạn có thể giảm biện pháp bảo vệ thành Lax.
  • Trong trường hợp cả cookie Strict và Lax đều bị chặn và cookie được gửi đến (hoặc được đặt từ) một URL bảo mật, bạn có thể giảm biện pháp bảo vệ vào None.
    • Giải pháp này sẽ không thành công nếu URL mà bạn đang gửi cookie đến (hoặc đặt từ khoá) là không an toàn. Điều này là do SameSite=None yêu cầu Secure trên cookie, điều này có nghĩa là những cookie đó có thể không được gửi hoặc thiết lập trên 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 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ị 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 được xử lý như thể chúng được chỉ định SameSite=Lax và cùng một hành vi trên nhiều lược đồ cũng áp dụng cho các cookie này tốt. 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 giải pháp giảm thiểu Lax + POST trong Chromium SameSite Câu hỏi thường gặp để 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 sẽ được coi là cùng một trang web nếu chúng giống nhau trang.

Cùng một 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 của Julissa Ma tuý đá về Không hiển thị nội dung