Mitigasi risiko yang terkait dengan eksposur perangkat dan server yang tidak disengaja di jaringan internal klien ke web secara keseluruhan.
Situs berbahaya yang membuat permintaan ke perangkat dan server yang dihosting di jaringan pribadi telah lama menjadi ancaman. Penyerang dapat, misalnya, mengubah konfigurasi router nirkabel untuk mengaktifkan serangan Man-in-the-Middle. CORS-RFC1918 adalah proposal untuk memblokir permintaan tersebut secara default di browser dan mewajibkan perangkat internal untuk ikut serta dalam permintaan dari internet publik.
Untuk memahami dampak perubahan ini terhadap ekosistem web, tim Chrome mencari masukan dari developer yang membuat server untuk jaringan pribadi.
Apa yang salah dengan status quo?
Banyak server web berjalan dalam jaringan pribadi—router nirkabel, printer, situs intranet, layanan perusahaan, dan perangkat Internet of Things (IoT) hanyalah sebagian darinya. Server tersebut mungkin tampak berada di lingkungan yang lebih aman daripada server yang terekspos ke publik, tetapi server tersebut dapat disalahgunakan oleh penyerang yang menggunakan halaman web sebagai proxy. Misalnya, situs berbahaya dapat menyematkan URL yang, saat hanya dilihat oleh korban (di browser yang mengaktifkan JavaScript), mencoba mengubah setelan server DNS di router broadband rumah korban. Jenis serangan ini disebut "Drive-By Pharming" dan terjadi pada tahun 2014. Lebih dari 300.000 router nirkabel yang rentan dieksploitasi dengan mengubah setelan DNS-nya dan mengizinkan penyerang mengalihkan pengguna ke server berbahaya.
CORS-RFC1918
Untuk mengurangi ancaman serangan serupa, komunitas web menghadirkan CORS-RFC1918—Cross Origin Resource Sharing (CORS) yang dikhususkan untuk jaringan pribadi yang ditentukan dalam RFC1918.
Browser yang menerapkan CORS akan memeriksa dengan resource target apakah resource tersebut dapat dimuat dari origin yang berbeda. Hal ini dilakukan dengan header tambahan inline yang menjelaskan akses atau dengan menggunakan mekanisme yang disebut permintaan pra-penerbangan, bergantung pada kompleksitasnya. Baca Cross Origin Resource Sharing untuk mempelajari lebih lanjut.
Dengan CORS-RFC1918, browser akan memblokir memuat resource melalui jaringan pribadi secara default, kecuali yang diizinkan secara eksplisit oleh server menggunakan CORS dan melalui HTTPS. Situs yang membuat permintaan ke resource tersebut harus mengirim header CORS dan server harus menyatakan secara eksplisit bahwa situs tersebut menerima permintaan lintas-asal dengan merespons dengan header CORS yang sesuai. (Header CORS yang tepat masih dalam pengembangan.)
Developer perangkat atau server tersebut akan diminta untuk melakukan dua hal:
- Pastikan situs yang membuat permintaan ke jaringan pribadi ditayangkan melalui HTTPS.
- Siapkan dukungan server untuk CORS-RFC1918 dan respons dengan header HTTP yang diharapkan.
Jenis permintaan apa yang terpengaruh?
Permintaan yang terpengaruh meliputi:
- Permintaan dari jaringan publik ke jaringan pribadi
- Permintaan dari jaringan pribadi ke jaringan lokal
- Permintaan dari jaringan publik ke jaringan lokal
Jaringan pribadi
Tujuan yang me-resolve ke ruang alamat pribadi yang ditentukan di Bagian 3
RFC1918 di IPv4, alamat IPv6 yang dipetakan IPv4
dengan alamat IPv4 yang dipetakan itu sendiri bersifat pribadi, atau alamat IPv6
di luar subnet ::1/128, 2000::/3, dan ff00::/8.
Jaringan lokal
Tujuan yang me-resolve ke ruang "loopback" (127.0.0.0/8) yang ditentukan di
bagian 3.2.1.3 dari RFC1122 IPv4, ruang
"link-local" (169.254.0.0/16) yang ditentukan di
RFC3927 IPv4, awalan "Alamat Lokal
Unik" (fc00::/7) yang ditentukan di Bagian 3 dari
RFC4193 IPv6, atau awalan "link-local"
(fe80::/10) yang ditentukan di bagian 2.5.6 dari
RFC4291 IPv6.
Jaringan publik Semua jaringan lainnya.
Rencana Chrome untuk mengaktifkan CORS-RFC1918
Chrome menghadirkan CORS-RFC1918 dalam dua langkah:
Langkah 1: Permintaan ke resource jaringan pribadi hanya akan diizinkan dari halaman web HTTPS
Chrome 87 menambahkan tanda yang mewajibkan situs publik yang membuat permintaan ke resource jaringan
pribadi untuk menggunakan HTTPS. Anda dapat membuka
about://flags#block-insecure-private-network-requests untuk mengaktifkannya. Dengan flag ini diaktifkan, setiap permintaan ke resource jaringan pribadi dari situs HTTP akan diblokir.
Mulai Chrome 88, error CORS-RFC1918 akan dilaporkan sebagai error kebijakan CORS di konsol.
Di panel Jaringan di Chrome DevTools, Anda dapat mengaktifkan kotak centang Permintaan yang Diblokir untuk berfokus pada permintaan yang diblokir:
Di Chrome 87, error CORS-RFC1918 hanya dilaporkan di Konsol DevTools sebagai
ERR_INSECURE_PRIVATE_NETWORK_REQUEST.
Anda dapat mencobanya sendiri menggunakan situs pengujian ini.
Langkah 2: Mengirim permintaan pra-penerbangan dengan header khusus
Di masa mendatang, setiap kali situs publik mencoba mengambil resource dari jaringan pribadi atau lokal, Chrome akan mengirimkan permintaan pra-penerbangan sebelum permintaan yang sebenarnya.
Permintaan akan menyertakan header Access-Control-Request-Private-Network: true
selain header permintaan CORS lainnya. Di antara hal lainnya, header
ini mengidentifikasi asal yang membuat permintaan, sehingga memungkinkan kontrol akses
yang terperinci. Server dapat merespons dengan header Access-Control-Allow-Private-Network:
true untuk secara eksplisit menunjukkan bahwa server tersebut memberikan akses ke resource.
Masukan yang diinginkan
Jika Anda menghosting situs dalam jaringan pribadi yang mengharapkan permintaan dari jaringan publik, tim Chrome tertarik dengan masukan dan kasus penggunaan Anda. Ada dua hal yang dapat Anda lakukan untuk membantu:
- Buka
about://flags#block-insecure-private-network-requests, aktifkan tanda, lalu lihat apakah situs Anda mengirimkan permintaan ke resource jaringan pribadi seperti yang diharapkan. - Jika Anda mengalami masalah atau memiliki masukan, laporkan masalah di
crbug.com
dan tetapkan komponen ke
Blink>SecurityFeature>CORS>RFC1918.
Contoh masukan
Router nirkabel kami menayangkan situs admin untuk jaringan pribadi yang sama, tetapi melalui HTTP. Jika HTTPS diperlukan untuk situs yang menyematkan situs admin, situs tersebut akan menjadi konten campuran. Haruskah kami mengaktifkan HTTPS di situs admin dalam jaringan tertutup?
Ini adalah jenis umpan balik yang dicari Chrome. Harap laporkan masalah dengan kasus penggunaan konkret Anda di crbug.com. Chrome ingin mendengar pendapat Anda.
Banner besar oleh Stephen Philips di Unsplash.