Update
- 7 Juli 2022: Memperbarui status saat ini dan menambahkan definisi ruang alamat IP.
- 27 April 2022: Memperbarui pengumuman linimasa.
- 7 Maret 2022: Mengumumkan rollback setelah masalah ditemukan di Chrome 98.
Pengantar
Chrome menghentikan akses langsung ke endpoint jaringan pribadi dari publik sebagai bagian dari Akses Jaringan Pribadi (PNA) spesifikasi pendukung.
Chrome akan mulai mengirimkan permintaan preflight CORS sebelum permintaan jaringan pribadi untuk subresource, yang meminta
untuk mendapatkan izin eksplisit
dari server target. Permintaan {i>preflight<i} ini akan
membawa header baru, Access-Control-Request-Private-Network: true
, dan
respons terhadapnya harus membawa
{i>header <i}yang sesuai,
Access-Control-Allow-Private-Network: true
.
Tujuannya adalah untuk melindungi pengguna dari serangan pemalsuan permintaan lintas situs (CSRF) yang menargetkan {i>router<i} dan perangkat lain di jaringan pribadi. Serangan ini telah memengaruhi ratusan ribu pengguna, yang memungkinkan penyerang untuk mengalihkan mereka ke server berbahaya.
Rencana peluncuran
Chrome akan meluncurkan perubahan ini dalam dua fase agar situs memiliki waktu untuk memperhatikan perubahan tersebut dan menyesuaikannya dengan tepat.
Di Chrome 104:
- Eksperimen Chrome dengan mengirimkan permintaan preflight sebelum jaringan pribadi permintaan subresource.
- Kegagalan preflight hanya menampilkan peringatan di DevTools, tanpa sebaliknya mempengaruhi permintaan jaringan pribadi.
- Chrome mengumpulkan data kompatibilitas dan menjangkau audiens terbesar yang terpengaruh situs web.
- Kami berharap fitur ini akan kompatibel secara luas dengan situs yang sudah ada.
Paling awal di Chrome 113:
- Proses ini akan dimulai hanya jika dan saat data kompatibilitas menunjukkan bahwa perubahan tersebut cukup aman dan kami telah menghubungi secara langsung bila diperlukan.
- Chrome mewajibkan bahwa permintaan preflight harus berhasil, jika tidak, akan gagal terhadap permintaan.
- Uji coba penghentian penggunaan dimulai pada waktu yang sama guna memungkinkan situs web yang terpengaruh oleh fase ini untuk meminta perpanjangan waktu. Uji coba akan berlangsung setidaknya selama 6 bulan.
Apa itu Akses Jaringan Pribadi (PNA)
Akses Jaringan Pribadi (sebelumnya dikenal sebagai CORS-RFC1918) membatasi kemampuan situs untuk mengirim permintaan ke server secara pribadi jaringan.
Chrome telah mengimplementasikan sebagian spesifikasi: mulai Chrome 96, hanya konteks aman diizinkan membuat permintaan jaringan pribadi. Lihat postingan blog sebelumnya untuk detailnya.
Spesifikasi ini juga memperluas Cross-Origin Resource Sharing (CORS) sehingga situs web sekarang harus secara eksplisit meminta izin dari server pada jaringan pribadi sebelum diizinkan untuk mengirim permintaan arbitrer.
Bagaimana PNA mengklasifikasikan alamat IP dan mengidentifikasi jaringan pribadi
Alamat IP diklasifikasikan ke dalam tiga ruang alamat IP:
- public
- private
- local
Ruang alamat IP lokal berisi alamat IP yang merupakan IPv4
alamat loopback (127.0.0.0/8
) yang ditentukan di bagian 3.2.1.3 dari RFC1122
atau alamat loopback IPv6 (::1/128
) yang ditentukan di bagian 2.5.3 dari RFC4291.
Ruang alamat IP pribadi berisi alamat IP yang hanya memiliki arti
dalam jaringan saat ini, termasuk 10.0.0.0/8
, 172.16.0.0/12
, dan
192.168.0.0/16
ditentukan dalam RFC1918,
alamat link-local 169.254.0.0/16
yang ditentukan dalam RFC3927,
alamat unicast IPv6 lokal unik fc00::/7
yang ditentukan dalam RFC4193,
alamat unicast link-local IPv6 fe80::/10
yang ditentukan di bagian 2.5.6 dari RFC4291
dan alamat IPv6 yang dipetakan IPv4, di mana
alamat IPv4 yang dipetakan bersifat pribadi.
Ruang Alamat IP Publik berisi semua alamat lain yang tidak disebutkan sebelumnya.
Alamat IP lokal dianggap lebih pribadi daripada alamat IP pribadi yang dianggap lebih pribadi daripada alamat IP publik.
Pelajari lebih lanjut di Feedback want: CORS untuk jaringan pribadi (RFC1918).
Permintaan preflight
Latar belakang
Permintaan preflight adalah mekanisme yang diperkenalkan oleh standar Cross-Origin Resource Sharing (CORS) yang digunakan untuk meminta izin dari situs web target sebelum mengirimkan permintaan HTTP yang mungkin memiliki efek samping. Hal ini memastikan bahwa server target memahami protokol CORS dan mengurangi risiko serangan CSRF secara signifikan.
Permintaan izin dikirim sebagai permintaan HTTP OPTIONS
dengan header permintaan CORS tertentu
yang menjelaskan permintaan HTTP yang akan datang. Respons harus membawa header respons CORS tertentu
secara eksplisit menyetujui
permintaan yang akan datang.
Yang baru di Akses Jaringan Pribadi
Sepasang header permintaan dan respons baru diperkenalkan untuk permintaan preflight:
Access-Control-Request-Private-Network: true
disetel di semua permintaan preflight PNAAccess-Control-Allow-Private-Network: true
harus ditetapkan di semua respons preflight PNA
Permintaan preflight untuk PNA dikirim untuk semua permintaan jaringan pribadi,
terlepas dari metode permintaan dan
mode yang sesuai. Pesan dikirim
sebelum permintaan dalam mode cors
serta no-cors
dan semua mode lainnya. Ini
adalah karena semua permintaan jaringan pribadi
dapat digunakan untuk serangan CSRF,
terlepas dari mode permintaan dan apakah konten respons dibuat atau tidak
yang tersedia untuk inisiator.
Permintaan preflight untuk PNA juga dikirim untuk permintaan origin yang sama, jika alamat IP target lebih pribadi daripada inisiator. Ini tidak seperti biasanya CORS, dengan permintaan preflight hanya untuk permintaan lintas asal. Preflight permintaan untuk permintaan origin yang sama mencegah Serangan DNS rebinding.
Contoh
Perilaku yang dapat diamati bergantung pada mode request.
Mode tanpa CORS
Ucapkan https://foo.example/index.html
sematan
<img src="https://bar.example/cat.gif" alt="dancing cat"/>
dan
bar.example
me-resolve menjadi 192.168.1.1
, alamat IP pribadi menurut
RFC 1918.
Chrome terlebih dahulu mengirimkan permintaan preflight:
HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true
Agar permintaan ini berhasil, server harus merespons dengan:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true
Kemudian Chrome akan mengirimkan permintaan yang sebenarnya:
HTTP/1.1 GET /cat.gif
...
Ke mana server dapat merespons secara normal.
mode CORS
Misalnya https://foo.example/index.html
menjalankan kode berikut:
await fetch('https://bar.example/delete-everything', {
method: 'PUT',
credentials: 'include',
})
Sekali lagi, misalnya bar.example
di-resolve menjadi 192.168.1.1
.
Chrome terlebih dahulu mengirimkan permintaan preflight:
HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true
Agar permintaan ini berhasil, server harus merespons dengan:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
Kemudian Chrome akan mengirimkan permintaan yang sebenarnya:
HTTP/1.1 PUT /delete-everything
Origin: https://foo.example
Yang dapat direspons server sesuai aturan CORS biasa:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example
Cara mengetahui apakah situs Anda terpengaruh
Mulai Chrome 104, jika permintaan jaringan pribadi terdeteksi, preflight akan dikirim terlebih dahulu. Jika permintaan preflight ini gagal, permintaan tetap akan dikirimkan, namun peringatan akan muncul di DevTools panel masalah.
Permintaan preflight yang terpengaruh juga dapat dilihat dan didiagnosis di panel jaringan:
Jika permintaan Anda akan memicu preflight CORS reguler tanpa aturan Akses Jaringan Pribadi, maka dua preflight dapat muncul di jaringan, dengan yang pertama selalu tampak gagal. Ini adalah bug yang diketahui, dan Anda dapat mengabaikannya dengan aman.
Untuk meninjau apa yang terjadi jika keberhasilan preflight diterapkan, Anda dapat meneruskan argumen command line berikut, mulai Chrome 98:
--enable-features=PrivateNetworkAccessRespectPreflightResults
Setiap permintaan preflight yang gagal akan mengakibatkan pengambilan gagal. Hal ini dapat memungkinkan Anda untuk menguji apakah situs Anda akan berfungsi setelah fase kedua dari rencana peluncuran. Kesalahan dapat didiagnosis dengan dengan cara yang sama seperti peringatan menggunakan panel DevTools yang disebutkan di atas.
Tindakan yang harus dilakukan jika situs Anda terpengaruh
Saat perubahan ini diluncurkan di Chrome 104, perubahan ini diperkirakan tidak akan menyebabkan error situs Anda. Namun, sebaiknya perbarui jalur permintaan yang terpengaruh untuk memastikan {i>website<i} Anda tetap berjalan seperti yang diharapkan.
Ada dua solusi yang tersedia untuk Anda:
- Menangani permintaan preflight di sisi server
- Nonaktifkan pemeriksaan PNA dengan kebijakan perusahaan
Menangani permintaan preflight sisi server
Mengupdate server target dari pengambilan yang terpengaruh untuk menangani preflight PNA permintaan. Pertama, implementasikan dukungan untuk permintaan preflight CORS standar di rute yang terdampak. Kemudian, tambahkan dukungan untuk dua header respons baru.
Saat server Anda menerima permintaan preflight (permintaan OPTIONS
dengan CORS
{i>header<i}), server harus memeriksa keberadaan
Header Access-Control-Request-Private-Network: true
. Jika {i>header<i} ini
ada pada permintaan, server harus memeriksa header Origin
dan
jalur permintaan bersama dengan informasi relevan lainnya (seperti
Access-Control-Request-Headers
) untuk memastikan permintaan aman untuk diizinkan.
Biasanya, Anda harus mengizinkan akses ke satu origin di bawah kontrol Anda.
Setelah server memutuskan untuk mengizinkan permintaan, server akan merespons
204 No Content
(atau 200 OK
) dengan header CORS yang diperlukan dan PNA baru
{i>header<i}. Header ini mencakup Access-Control-Allow-Origin
dan
Access-Control-Allow-Private-Network: true
, serta lainnya sesuai kebutuhan.
Lihat contoh untuk skenario konkret.
Menonaktifkan pemeriksaan Akses Jaringan Pribadi menggunakan kebijakan perusahaan
Jika memiliki kontrol administratif atas pengguna, Anda dapat menonaktifkan Pribadi Pemeriksaan Akses Jaringan menggunakan salah satu kebijakan berikut:
Untuk mengetahui informasi selengkapnya, lihat Memahami pengelolaan kebijakan Chrome.
Berikan masukan Anda
Jika Anda menghosting situs dalam jaringan pribadi yang mengharapkan permintaan dari
jaringan publik, tim Chrome tertarik dengan masukan dan kasus penggunaan Anda.
Beri tahu kami dengan mengajukan masalah ke Chromium di crbug.com dan setel
komponen ke Blink>SecurityFeature>CORS>PrivateNetworkAccess
.
Langkah berikutnya
Selanjutnya, Chrome akan memperluas pemeriksaan Akses Jaringan Pribadi untuk mencakup pekerja web: pekerja khusus, pekerja bersama, dan pekerja layanan. Kami sementara bertujuan untuk Chrome 107 agar mulai menampilkan peringatan.
Kemudian, Chrome akan memperluas pemeriksaan Akses Jaringan Pribadi untuk mencakup navigasi, termasuk iframe dan pop-up. Untuk sementara, kami menargetkan Chrome 108 dapat dimulai menampilkan peringatan.
Dalam kedua kasus tersebut, kita akan melanjutkan secara hati-hati dengan peluncuran bertahap yang serupa, untuk memberikan waktu kepada developer web untuk menyesuaikan dan memperkirakan risiko kompatibilitas.
Ucapan terima kasih
Foto sampul oleh Mark Olsen di Buka pembuka.