Akses Jaringan Pribadi: memperkenalkan preflight

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

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.

1. 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.

2. 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 PNA
• Access-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:

1. Menangani permintaan preflight di sisi server
2. 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:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

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.