Update
23 Maret 2023: Linimasa telah diperbarui, dan penghentian penggunaan tidak akan terjadi hingga Chrome 117.
19 Januari 2023: Linimasa telah diperbarui, dan penghentian penggunaan tidak akan terjadi hingga Chrome 114.
12 Agustus 2022: Linimasa telah diperbarui, dan penghentian penggunaan tidak akan terjadi hingga Chrome 109.
10 Februari 2022: Artikel yang telah diperbarui dipublikasikan di Akses Jaringan Pribadi: memperkenalkan preflight
25 Agustus 2021: Pembaruan pengumuman linimasa dan pengenalan uji coba penghentian penggunaan.
Chrome menghentikan akses ke endpoint jaringan pribadi dari situs yang tidak aman sebagai bagian dari spesifikasi Akses Jaringan Pribadi. Tujuannya adalah untuk melindungi pengguna dari serangan pemalsuan permintaan lintas situs (CSRF) yang menargetkan router dan perangkat lain di jaringan pribadi. Serangan ini telah memengaruhi ratusan ribu pengguna, sehingga penyerang dapat mengalihkannya ke server berbahaya.
Chrome akan memperkenalkan perubahan berikut:
- Memblokir permintaan ke jaringan pribadi dari situs publik yang tidak aman mulai Chrome 94.
- Memperkenalkan uji coba penghentian penggunaan yang akan berakhir di Chrome
- Dengan demikian, developer dapat meminta perpanjangan waktu untuk origin yang dipilih, yang tidak akan terpengaruh selama uji coba penghentian penggunaan.
- Memperkenalkan kebijakan Chrome yang akan memungkinkan deployment Chrome terkelola mengabaikan penghentian secara permanen. Tersedia di Chrome 92.
Jika Anda memerlukan lebih banyak waktu untuk mengurangi dampak daftar penghentian penggunaan untuk uji coba penghentian.
Jika memiliki kontrol administratif atas pengguna, Anda dapat mengaktifkan kembali fitur tersebut menggunakan kebijakan Chrome.
Untuk mengurangi dampak pembatasan baru, gunakan salah satu strategi berikut:
- Upgrade situs Anda ke HTTPS, dan jika perlu server target.
- Upgrade situs Anda ke HTTPS dan gunakan WebTransport.
- Balikkan hubungan penyematan.
Rentang waktu
- November 2020: Minta masukan tentang perubahan mendatang.
- Maret 2021: Setelah meninjau masukan dan melakukan penjangkauan, perubahan mendatang akan diumumkan. Spesifikasi diganti namanya dari CORS-RFC1918 menjadi Akses Jaringan Pribadi.
- April 2021: Chrome 90 diluncurkan ke versi Stabil, yang menampilkan peringatan penghentian penggunaan.
- Juni 2021: Chrome 92 diluncurkan ke Beta, yang melarang permintaan jaringan pribadi dari konteks yang tidak aman. Setelah mendapatkan masukan dari developer yang meminta tambahan waktu untuk menyesuaikan, penghentian penggunaan ditangguhkan ke Chrome 93, untuk disertai Uji Coba Penghentian Penggunaan.
- Juli 2021: Setelah mendapatkan masukan lebih lanjut dari developer, penghentian penggunaan dan uji coba yang menyertainya akan dialihkan ke Chrome 94. Selain itu, situs pribadi tidak lagi terpengaruh oleh penghentian penggunaan tersebut.
- Agustus 2021: Chrome 94 diluncurkan ke versi Beta. Developer web dapat mulai mendaftar ke uji coba penghentian penggunaan.
- September 2021: Chrome 94 diluncurkan ke Stabil. Developer web seharusnya sudah mendaftar ke uji coba penghentian penggunaan dan men-deploy token uji coba ke produksi.
- Desember 2022: Survei uji coba origin dikirim dan masukan diterima. Uji coba penghentian penggunaan diperpanjang ke Chrome 113.
- Maret 2023: Uji coba penghentian penggunaan diperpanjang ke Chrome 116, dan akan berakhir di Chrome 117. Mekanisme alternatif berbasis izin sedang dalam pengembangan, yang menargetkan rilis awal di Chrome 114.
- Mei 2023 (sementara): Mekanisme berbasis izin diluncurkan di Chrome 114. Situs dapat menggunakannya untuk keluar dari uji coba penghentian penggunaan.
- September 2023: Chrome 117 diluncurkan ke Stabil, yang mengakhiri uji coba penghentian penggunaan. Chrome memblokir semua permintaan jaringan pribadi dari konteks publik yang tidak aman.
Apa itu Akses Jaringan Pribadi
Akses Jaringan Pribadi (sebelumnya dikenal sebagai CORS-RFC1918) membatasi kemampuan situs untuk mengirim permintaan ke server di jaringan pribadi. Metode ini memungkinkan permintaan tersebut hanya dari konteks yang aman. Spesifikasi ini juga memperluas protokol Cross-Origin Resource Sharing (CORS) sehingga situs kini harus secara eksplisit meminta pemberian dari server di jaringan pribadi sebelum diizinkan untuk mengirim permintaan arbitrer.
Permintaan jaringan pribadi adalah permintaan yang alamat IP server targetnya lebih
pribadi daripada permintaan tempat inisiator permintaan diambil. Misalnya, permintaan dari situs publik (https://example.com) ke situs pribadi (http://router.local), atau permintaan dari situs pribadi ke localhost.
Pelajari lebih lanjut di bagian Masukan yang diinginkan: CORS untuk jaringan pribadi (RFC1918).
Pengertian uji coba penghentian penggunaan
Uji coba penghentian penggunaan (sebelumnya dikenal sebagai uji coba origin terbalik) adalah bentuk uji coba origin yang digunakan untuk memudahkan penghentian penggunaan fitur web. Uji coba penghentian penggunaan memungkinkan Chrome menghentikan fitur web tertentu dan mencegah situs membentuk dependensi baru, sekaligus memberikan waktu tambahan bagi situs yang dependen saat ini untuk melakukan migrasi dari fitur tersebut.
Selama uji coba penghentian penggunaan, fitur yang tidak digunakan lagi tidak akan tersedia untuk semua situs secara default. Developer yang masih perlu menggunakan fitur yang terpengaruh harus mendaftar ke uji coba penghentian penggunaan dan mendapatkan token untuk origin web tertentu, lalu mengubah situsnya untuk menayangkan token tersebut di header HTTP atau tag meta (kecuali dalam kasus ini). Jika situs menayangkan token valid yang cocok dengan originnya, Chrome akan mengizinkan penggunaan fitur yang tidak digunakan lagi dalam waktu terbatas.
Untuk informasi selengkapnya, lihat Mulai menggunakan uji coba origin Chrome dan panduan developer web untuk uji coba origin guna mendapatkan petunjuk.
Yang berubah di Chrome
Chrome 94
Mulai Chrome 94, konteks publik yang tidak aman (secara luas, situs yang tidak dikirim melalui HTTPS atau dari alamat IP pribadi) dilarang membuat permintaan ke jaringan pribadi. Hal ini sebelumnya direncanakan untuk Chrome 92, sehingga pesan penghentian penggunaan mungkin masih menyebutkan pencapaian sebelumnya.
Penghentian penggunaan ini disertai dengan uji coba penghentian penggunaan, yang memungkinkan developer web yang situsnya memanfaatkan fitur yang tidak digunakan lagi untuk terus menggunakannya hingga Chrome 116 dengan mendaftar ke token. Lihat di bawah untuk mengetahui petunjuk tentang cara mendaftar dan mengaktifkan uji coba di situs Anda.
Sepasang kebijakan Chrome dapat dimanfaatkan untuk menonaktifkan penghentian sepenuhnya atau di origin tertentu, tanpa batas. Hal ini memungkinkan penginstalan Chrome terkelola, misalnya, yang ada di setelan perusahaan, untuk menghindari kerusakan.
Chrome 117
Uji coba penghentian penggunaan berakhir. Semua situs harus dimigrasikan dari fitur yang tidak digunakan lagi, atau kebijakan penggunanya dikonfigurasi untuk terus mengaktifkan fitur tersebut.
Tindakan developer yang direkomendasikan
Langkah pertama untuk situs yang terpengaruh kemungkinan besar memerlukan waktu hingga perbaikan yang tepat dapat di-deploy: baik dengan mendaftar ke uji coba penghentian penggunaan, atau dengan menggunakan kebijakan. Kemudian, tindakan yang disarankan bervariasi bergantung pada situasi setiap situs yang terpengaruh.
Mendaftar ke uji coba penghentian penggunaan
- Klik Register untuk Akses Jaringan Pribadi dari uji coba origin konteks yang tidak aman guna mendapatkan token uji coba untuk origin yang berpartisipasi.
- Tambahkan
Origin-Trial: $tokenkhusus origin ke header respons Anda. Header respons ini hanya perlu ditetapkan pada resource utama dan respons navigasi jika dokumen yang dihasilkan menggunakan fitur yang tidak digunakan lagi. Tidak ada gunanya (meski tidak berbahaya) untuk melampirkan header ini ke respons subresource.
Karena uji coba ini harus diaktifkan atau dinonaktifkan sebelum dokumen diizinkan untuk membuat permintaan apa pun, dokumen tidak dapat diaktifkan melalui tag <meta>. Tag tersebut hanya diuraikan dari isi respons setelah permintaan subresource dikeluarkan. Hal ini menghadirkan tantangan bagi situs yang tidak mengontrol header respons, seperti situs statis github.io yang dilayani oleh pihak ketiga.
Untuk mengetahui detail selengkapnya, lihat Panduan developer web untuk uji coba origin.
Aktifkan kebijakan
Jika memiliki kontrol administratif atas pengguna, Anda dapat mengaktifkan kembali fitur yang tidak digunakan lagi menggunakan salah satu kebijakan berikut:
Untuk mengetahui detail selengkapnya tentang mengelola kebijakan bagi pengguna Anda, lihat artikel pusat bantuan ini.
Mengakses localhost
Jika situs Anda perlu mengeluarkan permintaan ke localhost, Anda hanya perlu mengupgrade situs ke HTTPS.
Permintaan yang menargetkan http://localhost (atau http://127.*.*.*, http://[::1]) tidak diblokir oleh Konten Campuran, meskipun dikeluarkan dari konteks yang aman.
Perhatikan bahwa mesin dan browser WebKit yang didasarkan padanya (terutama Safari) menyimpang dari spesifikasi Konten Campuran W3C di sini dan melarang permintaan ini sebagai Konten Campuran. Mereka juga tidak menerapkan Akses Jaringan Pribadi, sehingga situs mungkin ingin mengalihkan klien yang menggunakan browser tersebut ke situs versi HTTP teks biasa, yang masih diizinkan oleh browser tersebut untuk membuat permintaan ke localhost.
Mengakses alamat IP pribadi
Jika situs Anda perlu mengeluarkan permintaan ke server target pada alamat IP pribadi, mengupgrade situs inisiator ke HTTPS tidak akan berhasil. Konten Campuran mencegah konteks aman membuat permintaan melalui HTTP teks biasa, sehingga situs yang baru diamankan tetap tidak dapat membuat permintaan. Ada beberapa cara untuk mengatasi masalah ini:
- Mengupgrade kedua ujung ke HTTPS.
- Gunakan WebTransport untuk terhubung ke server target dengan aman.
- Balik hubungan penyematan.
Mengupgrade kedua ujung ke HTTPS
Solusi ini memerlukan kontrol atas resolusi DNS pengguna, seperti yang mungkin terjadi dalam konteks intranet, atau jika pengguna mendapatkan alamat server namanya dari server DHCP yang Anda kontrol. Ini juga mengharuskan Anda memiliki nama domain publik.
Masalah utama saat menayangkan situs pribadi melalui HTTPS adalah otoritas sertifikat infrastruktur kunci publik (PKI CA) hanya memberikan sertifikat TLS ke situs dengan nama domain publik. Untuk mengatasi hal ini:
- Daftarkan nama domain publik (misalnya,
intranet.example) dan publikasikan data DNS yang menunjukkan nama domain tersebut ke server publik pilihan Anda. - Dapatkan sertifikat TLS untuk
intranet.example. - Di dalam jaringan pribadi Anda, konfigurasikan DNS untuk me-resolve
intranet.exampleke alamat IP pribadi server target. - Konfigurasikan server pribadi agar menggunakan sertifikat TLS untuk
intranet.example. Tindakan ini memungkinkan pengguna Anda mengakses server pribadi dihttps://intranet.example.
Kemudian, Anda dapat mengupgrade situs yang memulai permintaan ke HTTPS dan terus membuat permintaan seperti sebelumnya.
Solusi ini siap menghadapi masa depan dan mengurangi kepercayaan yang Anda berikan pada jaringan, sehingga memperluas penggunaan enkripsi end-to-end dalam jaringan pribadi Anda.
WebTransport
Solusi ini tidak memerlukan kontrol atas resolusi DNS pengguna Anda. Opsi ini mengharuskan server target menjalankan server WebTransport minimal (server HTTP/3 dengan beberapa modifikasi).
Anda dapat mengabaikan kurangnya sertifikat TLS valid yang ditandatangani oleh CA tepercaya dengan menggunakan WebTransport dan mekanisme penyematan sertifikatnya. Hal ini memungkinkan pembuatan koneksi aman ke perangkat pribadi yang mungkin memiliki sertifikat yang ditandatangani sendiri, misalnya. Koneksi WebTransport memungkinkan transfer data dua arah, tetapi tidak untuk permintaan pengambilan. Anda dapat menggabungkan pendekatan ini dengan pekerja layanan untuk mem-proxy permintaan HTTP secara transparan melalui koneksi, dari sudut pandang aplikasi web Anda. Di sisi server, lapisan terjemahan yang sesuai dapat mengonversi pesan WebTransport menjadi permintaan HTTP.
Kami tahu bahwa tindakan ini cukup merepotkan, tetapi prosesnya akan jauh lebih mudah daripada mem-build di atas WebRTC. Kami juga berharap sejumlah investasi yang diperlukan juga akan diimplementasikan sebagai library yang dapat digunakan kembali. Kami juga percaya bahwa hal ini sangat berguna mengingat fakta bahwa konteks yang tidak aman cenderung kehilangan akses ke lebih banyak fitur platform web karena platform bergerak untuk mendorong penggunaan HTTPS dengan cara yang lebih kuat dari waktu ke waktu. Terlepas dari Akses Jaringan Pribadi, bagaimanapun juga hal ini mungkin menjadi investasi yang bijaksana.
Kami memperkirakan WebTransport melalui HTTP/3 akan dikirimkan di Chrome 96 (perangkat ini telah memulai uji coba origin) dengan mitigasi untuk melindungi dari aktivitas berbagi kunci dan praktik keamanan substandar lainnya, termasuk:
- Waktu habis masa berlaku maksimum yang singkat untuk sertifikat yang disematkan.
- Mekanisme khusus browser untuk mencabut kunci tertentu yang telah disalahgunakan.
Kami tidak akan mengirimkan pembatasan konteks aman hingga setidaknya dua versi setelah WebTransport diluncurkan sepenuhnya. Uji coba penghentian penggunaan akan diperpanjang jika diperlukan.
Penyematan balik
Solusi ini tidak memerlukan kontrol administratif atas jaringan, dan dapat digunakan saat server target tidak cukup andal untuk menjalankan HTTPS.
Daripada mengambil subresource pribadi dari aplikasi web publik, kerangka aplikasi dapat disalurkan dari server pribadi, yang kemudian mengambil semua subresource-nya (seperti skrip atau gambar) dari server publik, seperti CDN. Aplikasi web yang dihasilkan kemudian dapat membuat permintaan ke server pribadi, karena ini dianggap sebagai origin yang sama. Bahkan, localhost dapat membuat permintaan ke server lain dengan IP pribadi (tetapi bukan localhost), meskipun hal ini dapat berubah dalam jangka panjang.
Dengan menghosting kerangka saja di server pribadi, Anda dapat memperbarui aplikasi web dengan mengirim resource baru ke server publik, seperti Anda memperbarui aplikasi web publik. Di sisi lain, aplikasi web yang dihasilkan bukan konteks yang aman, sehingga tidak memiliki akses ke beberapa fitur web yang lebih canggih.
Rencana untuk masa depan
Membatasi permintaan jaringan pribadi ke konteks yang aman hanyalah langkah pertama dalam meluncurkan Akses Jaringan Pribadi. Chrome sedang berupaya menerapkan spesifikasi lainnya dalam beberapa bulan ke depan. Nantikan informasi lebih lanjut mengenai hal ini.
Membatasi akses localhost dari situs pribadi
Perubahan pada Chrome 94 hanya memengaruhi situs publik yang mengakses alamat IP pribadi atau localhost. Spesifikasi Akses Jaringan Pribadi juga mengklasifikasikan permintaan dari situs pribadi ke localhost sebagai bermasalah. Chrome pada akhirnya juga akan menghentikan penggunaan fitur ini. Namun, hal ini menghadirkan serangkaian tantangan yang sedikit berbeda, karena banyak situs pribadi yang tidak memiliki nama domain, sehingga mempersulit penggunaan token uji coba penghentian penggunaan.
Permintaan preflight CORS
Bagian kedua dari Akses Jaringan Pribadi adalah membatasi permintaan jaringan pribadi yang dimulai dari konteks aman dengan permintaan preflight CORS. Idenya adalah meskipun permintaan dimulai dari konteks yang aman, server target akan diminta untuk memberikan pemberian eksplisit kepada inisiator. Permintaan hanya dikirim jika pemberian berhasil.
Singkatnya, permintaan preflight CORS adalah permintaan OPTIONS HTTP yang membawa beberapa header Access-Control-Request-* yang menunjukkan sifat permintaan berikutnya. Server kemudian dapat memutuskan apakah akan memberikan akses terperinci atau tidak dengan merespons 200 OK menggunakan header Access-Control-Allow-*.
Temukan detail selengkapnya tentang hal ini di spesifikasi.
Membatasi pengambilan navigasi
Chrome tidak digunakan lagi dan pada akhirnya memblokir permintaan subresource ke jaringan pribadi. Hal ini tidak akan memengaruhi navigasi ke jaringan pribadi, yang juga dapat digunakan dalam serangan CSRF.
Spesifikasi Akses Jaringan Pribadi tidak membedakan antara dua jenis pengambilan tersebut, yang pada akhirnya akan tunduk kepada batasan yang sama.
Foto sampul oleh Markus Spiske di Unsplash