Mengurangi risiko yang terkait dengan eksposur perangkat dan server yang tidak disengaja di jaringan internal klien ke web dalam skala besar.
Situs berbahaya yang membuat permintaan ke perangkat dan server yang dihosting di jaringan pribadi sudah lama menjadi ancaman. Penyerang dapat, misalnya, mengubah konfigurasi router nirkabel untuk mengaktifkan serangan Man-in-the-Middle. CORS-RFC1918 adalah proposal untuk memblokir permintaan semacam itu secara default di browser dan mewajibkan perangkat internal untuk memilih ikut serta dalam permintaan dari internet publik.
Untuk memahami dampak perubahan ini pada ekosistem web, tim Chrome mencari masukan dari developer yang membangun server untuk jaringan pribadi.
Apa yang salah dengan status quo?
Banyak server web berjalan di dalam jaringan pribadi—router nirkabel, {i>printer<i}, situs web intranet, layanan perusahaan, dan perangkat Internet of Things (IoT) hanyalah sebagian dari itu. Server tersebut mungkin terlihat berada di lingkungan yang lebih aman daripada yang terekspos ke publik, tetapi server tersebut dapat disalahgunakan oleh penyerang menggunakan halaman web sebagai proxy. Misalnya, situs berbahaya dapat menyematkan URL yang, jika hanya dilihat oleh korban (di browser dengan JavaScript), berupaya 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 mereka dan memungkinkan penyerang mengalihkan pengguna ke server berbahaya.
CORS-RFC1918
Untuk memitigasi ancaman serangan serupa, komunitas web menghadirkan CORS-RFC1918—Cross Origin Resource Sharing (CORS) khusus untuk jaringan pribadi yang ditentukan dalam RFC1918.
Browser yang mengimplementasikan CORS akan memeriksa dengan resource target apakah resource tersebut baik-baik saja dimuat dari asal yang berbeda. Hal ini dilakukan dengan header tambahan secara inline yang menjelaskan akses atau dengan menggunakan mekanisme yang disebut permintaan preflight, bergantung pada kompleksitasnya. Baca Cross Origin Resource Sharing untuk mempelajari lebih lanjut.
Dengan CORS-RFC1918, browser akan memblokir pemuatan resource melalui jaringan pribadi secara default, kecuali yang secara eksplisit diizinkan oleh server menggunakan CORS dan HTTPS. Permintaan yang dibuat oleh situs ke resource tersebut harus mengirimkan header CORS dan server harus menyatakan secara eksplisit bahwa server tersebut menerima permintaan lintas origin dengan merespons menggunakan header CORS yang sesuai. (Header CORS persis 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 mencakup:
- 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 terhubung ke ruang alamat pribadi yang ditentukan dalam Bagian 3
RFC1918 di IPv4, alamat IPv6 yang dipetakan
IPv4 di mana 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 dalam
bagian 3.2.1.3 di RFC1122 di IPv4,
ruang "link-local" (169.254.0.0/16
) yang ditentukan di
RFC3927 di IPv4, awalan "Unique Local
Address" (fc00::/7
) yang ditentukan di
bagian 3 di
RFC4193 di bagian
RFC4193fe80::/10
RFC4291
Jaringan publik Lainnya.
![Hubungan antara jaringan publik, pribadi, dan lokal di CORS-RFC1918](https://developer.chrome.google.cn/static/blog/cors-rfc1918-feedback/image/relationship-between-publ-b36a72c2b6ded.png?authuser=0&hl=id)
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 flag yang mewajibkan situs publik yang membuat permintaan ke resource jaringan
pribadi agar berada di HTTPS. Anda dapat membuka
about://flags#block-insecure-private-network-requests
untuk mengaktifkannya. Dengan mengaktifkan flag ini, semua permintaan ke resource jaringan pribadi dari situs HTTP akan diblokir.
Mulai Chrome 88, error CORS-RFC1918 akan dilaporkan sebagai error kebijakan CORS di konsol.
![Error CORS-RFC1918 akan dilaporkan sebagai error kebijakan CORS di konsol.](https://developer.chrome.google.cn/static/blog/cors-rfc1918-feedback/image/cors-rfc1918-errors-be-r-b862b694a7ca2.png?authuser=0&hl=id)
Di panel Jaringan di Chrome DevTools, Anda dapat mengaktifkan kotak centang Permintaan yang Diblokir untuk berfokus pada permintaan yang diblokir:
![Error CORS-RFC1918 juga akan dilaporkan sebagai error error CORS di panel Jaringan.](https://developer.chrome.google.cn/static/blog/cors-rfc1918-feedback/image/cors-rfc1918-errors-also-67275e6c8a037.png?authuser=0&hl=id)
Di Chrome 87, error CORS-RFC1918 hanya dilaporkan di Konsol DevTools sebagai
ERR_INSECURE_PRIVATE_NETWORK_REQUEST
.
Anda dapat mencobanya sendiri menggunakan situs uji coba ini.
Langkah 2: Mengirim permintaan preflight dengan header khusus
Pada masa mendatang, setiap kali situs publik mencoba mengambil resource dari jaringan pribadi atau lokal, Chrome akan mengirimkan permintaan preflight sebelum permintaan yang sebenarnya.
Permintaan ini akan menyertakan header Access-Control-Request-Private-Network: true
selain header permintaan CORS lainnya. Header ini antara lain mengidentifikasi origin yang membuat permintaan, sehingga memungkinkan kontrol akses yang terperinci. Server dapat merespons dengan header Access-Control-Allow-Private-Network:
true
untuk menunjukkan secara eksplisit bahwa server memberikan akses ke resource.
Masukan diinginkan
Jika Anda menghosting situs dalam jaringan pribadi yang mengharapkan permintaan dari jaringan publik, tim Chrome ingin mendengar masukan dan kasus penggunaan Anda. Ada dua hal yang dapat Anda lakukan untuk membantu:
- Buka
about://flags#block-insecure-private-network-requests
, aktifkan tanda dan lihat apakah situs Anda mengirim permintaan ke resource jaringan pribadi seperti yang diharapkan. - Jika Anda mengalami masalah atau memiliki masukan, laporkan masalah di
crbug.com
dan setel komponen ke
Blink>SecurityFeature>CORS>RFC1918
.
Contoh masukan
{i>Router<i} nirkabel melayani situs web admin untuk jaringan pribadi yang sama tetapi melalui HTTP. Jika HTTPS diperlukan untuk situs yang menyematkan situs admin, konten akan berupa konten campuran. Haruskah kita mengaktifkan HTTPS di situs admin dalam jaringan tertutup?
Ini adalah jenis masukan yang dicari Chrome. Laporkan masalah dengan kasus penggunaan konkret Anda di crbug.com. Chrome ingin mendengar pendapat Anda.
Banner besar oleh Stephen Philips di Unsplash.