Situs yang Sama Skema

Definisi "situs yang sama" terus berkembang untuk 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

Catatan: Artikel ini adalah bagian dari rangkaian tentang perubahan atribut cookie SameSite yang mencakup:

• Memahami cookie
• Cookie SameSite dijelaskan
• Resep cookie SameSite

Schemeful Same-Site mengubah definisi situs (web) dari hanya domain yang dapat didaftarkan ke skema + domain yang dapat didaftarkan. Anda dapat menemukan detail dan contoh selengkapnya dalam Memahami "situs yang sama" dan "origin yang sama".

Istilah penting: Ini berarti bahwa versi HTTP situs yang tidak aman, misalnya, http://website.example, dan versi HTTPS yang aman dari situs tersebut, https://website.example, kini dianggap lintas situs satu sama lain.

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

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

Peringatan: Rencana jangka panjangnya adalah menghentikan dukungan untuk cookie pihak ketiga sepenuhnya, dan menggantinya dengan alternatif yang menjaga privasi. Menyetel SameSite=None; Secure pada cookie untuk mengizinkannya dikirim di seluruh skema hanya boleh dianggap sebagai solusi sementara dalam migrasi ke HTTPS lengkap.

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

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

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

Skenario lintas skema umum

Istilah penting: Pada contoh di bawah, semua URL memiliki domain yang dapat didaftarkan yang sama, misalnya site.example, tetapi skema yang berbeda, misalnya, http://site.example vs. https://site.example, keduanya disebut sebagai lintas skema satu sama lain.

Navigasi

Menavigasi antara versi situs web lintas skema (misalnya, menautkan dari http://site.example ke https://site.example) sebelumnya akan memungkinkan cookie SameSite=Strict dikirim. Hal ini kini diperlakukan sebagai navigasi lintas situs, yang berarti cookie SameSite=Strict akan diblokir.

Navigasi lintas skema dari HTTP ke HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Diblokir	⛔ Diblokir
SameSite=Lax	✓ Diizinkan	✓ Diizinkan
SameSite=None;Secure	✓ Diizinkan	⛔ Diblokir

Memuat subresource

Peringatan: Semua browser utama memblokir konten campuran aktif seperti skrip atau iframe. Selain itu, browser termasuk Chrome dan Firefox berupaya mengupgrade atau memblokir konten campuran pasif.

Setiap perubahan yang Anda lakukan di sini hanya boleh dianggap sebagai perbaikan sementara saat Anda melakukan upgrade ke HTTPS lengkap.

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

Memuat subresource lintas skema pada halaman sebelumnya akan memungkinkan cookie SameSite=Strict atau SameSite=Lax dikirim atau disetel. Sekarang, hal ini diperlakukan dengan cara yang sama seperti subresource pihak ketiga atau lintas situs lainnya, yang berarti bahwa setiap cookie SameSite=Strict atau SameSite=Lax akan diblokir.

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

Halaman HTTP yang berisi subresource lintas skema melalui HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Diblokir	⛔ Diblokir
SameSite=Lax	⛔ Diblokir	⛔ Diblokir
SameSite=None;Secure	✓ Diizinkan	⛔ Diblokir

POSTING formulir

Memposting antara versi situs lintas skema sebelumnya 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 mengalami skenario ini di situs yang secara default menyajikan versi yang tidak aman, tetapi mengupgrade pengguna ke versi yang aman saat formulir login atau check out.

Seperti halnya subresource, jika permintaan beralih 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.

Peringatan: Solusi terbaik dalam hal ini adalah memastikan halaman formulir dan tujuan berada di koneksi yang aman seperti HTTPS. Tindakan ini sangat penting jika pengguna memasukkan informasi sensitif apa pun ke dalam formulir.

Pengiriman formulir lintas skema dari HTTP ke HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Diblokir	⛔ Diblokir
SameSite=Lax	⛔ Diblokir	⛔ Diblokir
SameSite=None;Secure	✓ Diizinkan	⛔ Diblokir

Bagaimana cara menguji situs saya?

Fitur dan pesan developer tersedia di Chrome dan Firefox.

Mulai Chrome 86, tab Masalah di DevTools akan menyertakan masalah Schemeful Same-Site. Anda mungkin melihat masalah berikut ditandai untuk situs Anda.

Masalah navigasi:

• "Migrasikan seluruhnya ke HTTPS untuk terus memiliki cookie yang dikirim di permintaan situs yang sama"—Peringatan bahwa cookie akan diblokir di versi Chrome 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 untuk terus mengirimkan cookie ke subresource situs yang sama" atau "Migrasikan sepenuhnya ke HTTPS untuk terus mengizinkan cookie agar 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 seluruhnya ke HTTPS untuk mengizinkan cookie disetel 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 Proses Debug untuk Schemeful Same-Site.

Dari Firefox 79, dengan network.cookie.sameSite.schemeful yang ditetapkan ke true melalui about:config, konsol akan menampilkan pesan untuk masalah Schemeful Same-Site. Anda mungkin melihat hal berikut di situs Anda:

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

FAQ

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

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

Salah satu cara untuk memperbaiki masalah ini adalah menggunakan HTTP Strict-Transport-Security (HSTS) dan perintah includeSubDomain. Dengan HSTS + includeSubDomain, meskipun salah satu halaman Anda 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 agar Anda mengupgrade situs sepenuhnya ke HTTPS untuk melindungi pengguna, jika Anda tidak dapat melakukannya sendiri, sebaiknya hubungi penyedia hosting Anda untuk mengetahui apakah mereka dapat menawarkan opsi tersebut. Jika Anda menghosting sendiri, Let's Encrypt akan menyediakan sejumlah alat untuk menginstal dan mengonfigurasi sertifikat. Anda juga dapat menyelidiki pemindahan situs Anda ke belakang CDN atau proxy lain yang dapat menyediakan koneksi HTTPS.

Jika tidak memungkinkan, coba longgarkan 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 disetel dari) URL aman, Anda dapat menurunkan perlindungan ke None.
  • Solusi ini akan gagal jika URL yang Anda gunakan untuk mengirimkan cookie (atau menetapkannya) tidak aman. Ini karena SameSite=None memerlukan atribut Secure pada cookie, yang berarti cookie tersebut tidak dapat dikirim atau disetel melalui koneksi yang tidak aman. Dalam kasus ini, Anda tidak akan dapat mengakses cookie tersebut hingga situs Anda diupgrade ke HTTPS.
  • Ingat, hal ini hanya bersifat sementara karena cookie pihak ketiga pada akhirnya akan dihentikan sepenuhnya.

Bagaimana pengaruhnya terhadap cookie 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. Perlu diperhatikan bahwa pengecualian sementara untuk metode yang tidak aman masih berlaku, lihat mitigasi Lax + POST di SameSite FAQ Chromium untuk mengetahui informasi selengkapnya.

Bagaimana pengaruh terhadap WebSockets?

Koneksi WebSocket akan tetap dianggap situs yang sama jika tingkat keamanannya sama dengan halaman.

Situs yang sama:

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

{i>Cross-site <i}(Lintas situs):

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

Foto oleh Julissa Capdevilla di Unsplash