Situs yang Sama Skema

Definisi "situs yang sama" terus berkembang hingga menyertakan skema URL, sehingga link antara versi HTTP dan HTTPS situs kini dihitung sebagai permintaan lintas situs. Upgrade ke HTTPS secara default untuk menghindari masalah jika memungkinkan atau baca terus untuk mengetahui detail nilai atribut SameSite yang diperlukan.

Steven Bingler

Rowan Merewood

SameSite dengan Skema mengubah definisi situs (web) dari hanya domain yang dapat didaftarkan menjadi skema + domain yang dapat didaftarkan. Anda dapat menemukan detail dan contoh selengkapnya di Memahami "situs yang sama" dan "origin yang sama".

Kabar baiknya adalah: jika situs Anda sudah sepenuhnya diupgrade ke HTTPS, Anda tidak perlu khawatir tentang apa pun. Tidak ada yang akan berubah bagi Anda.

Jika Anda belum sepenuhnya mengupgrade situs, hal ini harus menjadi prioritas. Namun, jika ada kasus ketika pengunjung situs Anda akan beralih antara HTTP dan HTTPS, beberapa skenario umum dan perilaku cookie SameSite terkait akan diuraikan nanti dalam artikel ini.

Anda dapat mengaktifkan perubahan ini untuk pengujian di Chrome dan Firefox.

• Mulai Chrome 86, aktifkan about://flags/#schemeful-same-site. Pantau progres di halaman Status Chrome.
• Mulai Firefox 79, tetapkan network.cookie.sameSite.schemeful ke true melalui about:config. Pantau progres menggunakan masalah Bugzilla.

Salah satu alasan utama perubahan ke SameSite=Lax sebagai default untuk cookie adalah untuk melindungi dari Pemalsuan Permintaan Lintas Situs (CSRF). Namun, traffic HTTP yang tidak aman masih memberikan peluang bagi penyerang jaringan untuk merusak cookie yang kemudian akan digunakan pada versi HTTPS situs yang aman. Membuat batas lintas situs tambahan antara skema memberikan pertahanan lebih lanjut terhadap serangan ini.

Skenario lintas skema umum

Navigasi

Sebelumnya, navigasi antara versi lintas skema situs (misalnya, menghubungkan dari http://site.example ke https://site.example) akan memungkinkan SameSite=Strict cookie dikirim. Sekarang, hal ini diperlakukan sebagai navigasi lintas situs yang berarti cookie SameSite=Strict akan diblokir.

Memuat subresource

Setiap perubahan yang Anda buat di sini hanya boleh dianggap sebagai perbaikan sementara saat Anda berupaya mengupgrade ke HTTPS penuh.

Contoh subresource mencakup gambar, iframe, dan permintaan jaringan yang dibuat dengan XHR atau Pengambilan.

Sebelumnya, memuat subresource lintas skema di halaman akan memungkinkan cookie SameSite=Strict atau SameSite=Lax dikirim atau ditetapkan. Sekarang, hal ini diperlakukan dengan cara yang sama seperti subresource pihak ketiga atau lintas situs lainnya yang berarti cookie SameSite=Strict atau SameSite=Lax akan diblokir.

Selain itu, meskipun browser mengizinkan resource dari skema yang tidak aman dimuat di halaman yang aman, semua cookie akan diblokir pada permintaan ini karena cookie pihak ketiga atau lintas situs memerlukan Secure.

Memposting formulir

Sebelumnya, memposting antara versi lintas skema situs akan memungkinkan cookie yang ditetapkan dengan SameSite=Lax atau SameSite=Strict dikirim. Sekarang, hal ini diperlakukan sebagai POST lintas situs—hanya cookie SameSite=None yang dapat dikirim. Anda mungkin menemukan skenario ini di situs yang menampilkan versi tidak aman secara default, tetapi mengupgrade pengguna ke versi yang aman saat formulir login atau checkout dikirimkan.

Seperti subresource, jika permintaan berasal dari konteks yang aman (misalnya HTTPS) ke konteks yang tidak aman (misalnya HTTP), semua cookie akan diblokir pada permintaan ini karena cookie pihak ketiga atau lintas situs memerlukan Secure.

Bagaimana cara menguji situs saya?

Alat dan pesan developer tersedia di Chrome dan Firefox.

Mulai Chrome 86, tab Masalah di DevTools akan menyertakan masalah SameSite dengan Skema. Anda mungkin melihat masalah berikut yang ditandai untuk situs Anda.

Masalah navigasi:

• "Migrasikan sepenuhnya ke HTTPS agar cookie tetap dikirim pada permintaan situs yang sama"—Peringatan bahwa cookie akan diblokir di Chrome versi mendatang.
• "Migrasikan sepenuhnya ke HTTPS agar cookie dikirim pada permintaan situs yang sama"—Peringatan bahwa cookie telah diblokir.

Masalah pemuatan subresource:

• "Migrasikan sepenuhnya ke HTTPS agar cookie tetap dikirim ke subresource situs yang sama" atau "Migrasikan sepenuhnya ke HTTPS agar cookie tetap dapat ditetapkan oleh subresource situs yang sama"—Peringatan bahwa cookie akan diblokir di Chrome versi mendatang.
• "Migrasikan sepenuhnya ke HTTPS agar cookie dikirim ke subresource situs yang sama" atau "Migrasikan sepenuhnya ke HTTPS agar cookie dapat ditetapkan oleh subresource situs yang sama"—Peringatan bahwa cookie telah diblokir. Peringatan terakhir juga dapat muncul saat memposting formulir.

Detail selengkapnya tersedia di Tips Pengujian dan Debugging untuk SameSite dengan Skema.

Mulai Firefox 79, dengan network.cookie.sameSite.schemeful ditetapkan ke true melalui about:config, konsol akan menampilkan pesan untuk masalah SameSite dengan Skema. Anda mungkin melihat hal berikut di situs Anda:

• "Cookie cookie_name akan segera diperlakukan sebagai cookie lintas situs terhadap http://site.example/ karena skemanya tidak cocok."
• "Cookie cookie_name telah diperlakukan sebagai lintas situs terhadap http://site.example/ karena skemanya tidak cocok."

FAQ

Situs saya sudah sepenuhnya tersedia di HTTPS, mengapa saya melihat masalah di DevTools browser?

Kemungkinan beberapa link dan subresource Anda masih mengarah ke URL yang tidak aman.

Salah satu cara untuk memperbaiki masalah ini adalah dengan menggunakan HTTP Strict-Transport-Security (HSTS) dan direktif includeSubDomain. Dengan HSTS + includeSubDomain, meskipun salah satu halaman Anda secara tidak sengaja menyertakan link yang tidak aman, browser akan otomatis menggunakan versi yang aman.

Bagaimana jika saya tidak dapat mengupgrade ke HTTPS?

Meskipun kami sangat menyarankan Anda mengupgrade situs sepenuhnya ke HTTPS untuk melindungi pengguna, jika Anda tidak dapat melakukannya sendiri, sebaiknya hubungi penyedia hosting Anda untuk melihat apakah mereka dapat menawarkan opsi tersebut. Jika Anda melakukan hosting sendiri, maka Let's Encrypt menyediakan sejumlah alat untuk menginstal dan mengonfigurasi sertifikat. Anda juga dapat menyelidiki pemindahan situs di belakang CDN atau proxy lain yang dapat menyediakan koneksi HTTPS.

Jika hal tersebut masih tidak memungkinkan, coba kurangi perlindungan SameSite pada cookie yang terpengaruh.

• Jika hanya cookie SameSite=Strict yang diblokir, Anda dapat menurunkan perlindungan ke Lax.
• Jika cookie Strict dan Lax diblokir dan cookie Anda dikirim ke (atau ditetapkan dari) URL yang aman, Anda dapat menurunkan perlindungan ke None.
  • Solusi sementara ini akan gagal jika URL yang Anda gunakan untuk mengirim cookie (atau menetapkannya dari) tidak aman. Hal ini karena SameSite=None memerlukan atribut Secure pada cookie yang berarti cookie tersebut mungkin tidak dikirim atau ditetapkan melalui koneksi yang tidak aman. Dalam hal ini, Anda tidak akan dapat mengakses cookie tersebut hingga situs Anda diupgrade ke HTTPS.
  • Perlu diingat bahwa hal ini hanya bersifat sementara karena pada akhirnya cookie pihak ketiga akan dihentikan sepenuhnya.

Bagaimana hal ini memengaruhi cookie saya jika saya belum menentukan atribut SameSite?

Cookie tanpa atribut SameSite diperlakukan seolah-olah menentukan SameSite=Lax dan perilaku lintas skema yang sama juga berlaku untuk cookie ini juga. Perhatikan bahwa pengecualian sementara untuk metode yang tidak aman masih berlaku. Lihat mitigasi Lax + POST di FAQSameSiteChromium untuk mengetahui informasi selengkapnya.

Bagaimana pengaruhnya terhadap WebSocket?

Koneksi WebSocket akan tetap dianggap sebagai situs yang sama jika memiliki tingkat keamanan yang sama dengan halaman.

Situs yang sama:

• Koneksi wss:// dari https://
• Koneksi ws:// dari http://

Lintas situs:

• Koneksi wss:// dari http://
• Koneksi ws:// dari https://