Situs yang Sama Skema

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

Skema Situs yang Sama 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 "same-site" dan "origin yang sama".

Kabar baiknya adalah: jika situs web Anda telah sepenuhnya ditingkatkan ke HTTPS maka Anda tidak perlu mengkhawatirkan apa pun. Tidak ada yang berubah untuk Anda.

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

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

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

Salah satu alasan utama untuk perubahan ke SameSite=Lax sebagai default untuk adalah untuk melindungi dari Pemalsuan Permintaan Lintas Situs (CSRF). Namun, lalu lintas HTTP yang tidak aman masih memiliki peluang bagi penyerang untuk mengutak-atik {i>cookie<i} yang kemudian akan digunakan pada versi HTTPS yang aman situs Anda. Membuat batas lintas situs tambahan di antara skema akan memberikan pertahanan yang lebih baik dari serangan tersebut.

Skenario silang umum

Navigasi

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

Memuat subresource

Setiap perubahan yang Anda buat di sini sebaiknya hanya dianggap sebagai perbaikan sementara selama Anda bekerja untuk meningkatkan ke HTTPS penuh.

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

Memuat subresource lintas skema pada halaman sebelumnya akan mengizinkan SameSite=Strict atau SameSite=Lax cookie yang akan dikirim atau ditetapkan. Ini adalah diperlakukan dengan cara yang sama seperti subresource pihak ketiga atau lintas situs lainnya yang berarti bahwa cookie SameSite=Strict atau SameSite=Lax akan diblokir.

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

MEMPOSTING formulir

Pengeposan antar-skema situs web sebelumnya akan memungkinkan cookie yang ditetapkan dengan SameSite=Lax atau SameSite=Strict untuk dikirim. Ini adalah diperlakukan sebagai POST lintas situs—hanya SameSite=None cookie yang dapat dikirim. Anda mungkin mengalami skenario ini pada situs yang memberikan versi yang tidak aman secara {i>default<i}, tetapi meningkatkan pengguna ke versi aman saat melakukan upaya masuk atau formulir {i>check out<i}.

Seperti pada subresource, jika permintaan berasal dari jaringan aman, mis. HTTPS, dengan tidak aman, misalnya HTTP, konteks lalu 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 mencakup masalah Schemeful Same-Site. Anda mungkin melihat masalah berikut ditandai untuk situs Anda.

Masalah navigasi:

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

Masalah pemuatan subresource:

• "Bermigrasi sepenuhnya ke HTTPS agar cookie terus dikirim ke situs yang sama subresource" atau "Migrasikan sepenuhnya ke HTTPS untuk terus mengizinkan cookie untuk 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 "Bermigrasi sepenuhnya ke HTTPS untuk mengizinkan cookie disetel oleh situs yang sama subresources"—Peringatan bahwa cookie telah diblokir. Terakhir peringatan ini juga dapat muncul saat MEMPOSTING formulir.

Detail selengkapnya tersedia di Tips Pengujian dan Proses Debug untuk Schemeful Situs yang Sama.

Dari Firefox 79, dengan network.cookie.sameSite.schemeful 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?

Mungkin beberapa link dan subresource Anda masih mengarah ke status tidak aman URL.

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

Bagaimana jika saya tidak dapat mengupgrade ke HTTPS?

Meskipun kami sangat menyarankan agar Anda mengupgrade situs sepenuhnya ke HTTPS untuk melindungi pengguna Anda, jika Anda tidak dapat melakukannya sendiri, sebaiknya bicarakan dengan penyedia hosting Anda untuk melihat apakah mereka dapat menawarkan opsi tersebut. Jika Anda menghosting sendiri, lalu 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 masih tidak memungkinkan, coba longgarkan perlindungan SameSite di cookie yang terpengaruh.

• Jika hanya SameSite=Strict cookie yang diblokir, Anda dapat menurunkan perlindungan ke Lax.
• Jika cookie Strict dan Lax diblokir dan cookie dikirim ke (atau disetel dari) URL aman, Anda dapat menurunkan perlindungan data menjadi None.
  • Solusi ini akan gagal jika URL tujuan pengiriman cookie (atau menyetelnya) tidak aman. Hal ini karena SameSite=None memerlukan Secure pada cookie, yang berarti cookie tersebut tidak dapat dikirim atau menggunakan koneksi yang tidak aman. Dalam kasus ini, Anda tidak akan dapat mengakses cookie tersebut hingga situs Anda diupgrade ke HTTPS.
  • Ingat, ini hanya bersifat sementara karena pada akhirnya cookie pihak ketiga akan dihentikan sepenuhnya.

Bagaimana pengaruhnya terhadap cookie saya jika saya belum menentukan atribut SameSite?

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

Bagaimana WebSockets terpengaruh?

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

Situs yang sama:

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

Lintas situs:

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

Foto oleh Julissa {i>Capdevilla<i} aktif Buka Pembukaan