Usulan untuk membatasi situs yang dapat mengakses jaringan lokal pengguna

• Tim keamanan Chrome mengusulkan skema baru "izin akses jaringan lokal" untuk mengatasi masalah akses situs web ke jaringan lokal
• Saat ini, situs web publik berpotensi mengakses atau menyerang perangkat di jaringan lokal pengguna seperti printer tanpa izin, tetapi usulan ini bertujuan memblokir permintaan ke jaringan lokal tanpa persetujuan pengguna
• Berbeda dengan Private Network Access (PNA) yang ada, skema ini bekerja berbasis persetujuan izin pengguna alih-alih preflight, sehingga memperkuat kendali pengguna, dan dapat diterapkan hanya dengan pembaruan situs tanpa perubahan pada perangkat
• Secara spesifik, ketika situs publik melakukan permintaan fetch ke IP lokal, domain .local, dan sebagainya, jika tidak ada izin maka browser akan menampilkan permintaan persetujuan eksplisit kepada pengguna
• Melalui kebijakan ini, keamanan dan privasi diperkuat, sementara kasus penggunaan yang sah seperti pengaturan perangkat IoT tetap dijamin berfungsi normal jika pengguna mengizinkan

---

Gambaran umum dan tujuan usulan

• Chrome Secure Web and Network Team merilis rancangan awal mekanisme pemberian izin 'akses jaringan lokal' untuk mengatasi akses tak sah situs web publik ke jaringan lokal
• Sebelumnya, situs yang dikunjungi dapat mencoba melakukan CSRF atau serangan lain ke perangkat di jaringan lokal pengguna seperti printer dan router
• Ke depan, diusulkan struktur di mana browser memblokir permintaan yang melintasi batas antar-ruang alamat seperti IP publik → IP lokal, dan hanya mengizinkannya setelah mendapat persetujuan eksplisit dari pengguna per situs

Latar belakang dan perbedaannya

• Private Network Access (PNA) yang ada berbasis preflight (permintaan/respons pendahuluan), dan sulit diadopsi karena memerlukan perubahan pada perangkat juga
• Usulan kali ini dapat ditangani hanya dengan persetujuan izin pengguna, dan karena situs hanya perlu sedikit modifikasi, penerapan dan penyebarannya lebih mudah secara nyata

Tujuan dan non-tujuan

• Tujuan
  • Memblokir penyalahgunaan perangkat dan server rentan berbasis web drive-by
  • Mengizinkan komunikasi antara situs web publik dan perangkat lokal hanya jika pengguna menginginkan dan mengizinkannya
• Non-tujuan
  • Tidak bertujuan memblokir seluruh alur penggunaan yang wajar seperti pengaturan atau kontrol perangkat lokal yang sudah ada
  • Masalah HTTPS di jaringan lokal, penerbitan sertifikat yang rumit, dan sejenisnya tidak termasuk dalam cakupan usulan ini

Kasus penggunaan

• Kasus 1: Jika pengguna biasa tidak menginginkannya, saat example.com mengirim permintaan ke 192.168.0.1 dan sebagainya, browser akan menanyakan izin, dan jika ditolak maka permintaan diblokir
• Kasus 2: Halaman konfigurasi web resmi milik produsen perangkat seperti IoT atau router akan diizinkan berkomunikasi setelah terlebih dahulu memperoleh izin dari pengguna

Desain rinci

• Pemisahan ruang alamat:
  • Mengklasifikasikan lapisan jaringan IP ke dalam tiga tingkat: loopback (khusus dirinya sendiri), local (di dalam jaringan lokal), dan public (dapat diakses semua)
  • Mencakup berbagai kriteria identifikasi jaringan lokal seperti domain .local, IP privat RFC1918/4193, dan nama link-local RFC6762
• Permintaan jaringan lokal: izin diperlukan saat mengakses dari public→local, public→loopback, local→loopback, dan sejenisnya, yaitu dari alamat yang lebih terbuka ke jaringan internal
  • Permintaan dari jaringan publik ke jaringan lokal/loopback, hingga dari lokal ke loopback, dianggap sebagai permintaan jaringan lokal
  • Pengecualian: local→local, loopback→alamat mana pun, dan sejenisnya tidak menjadi target pembatasan
• Prompt izin:
  • Saat situs mengirim permintaan ke jaringan lokal, jika belum memiliki izin maka browser menampilkan prompt yang menanyakan apakah pengguna ingin mengizinkannya
  • Jika ditolak, permintaan diblokir; jika diterima, permintaan dilanjutkan
• Integrasi fetch API: opsi seperti targetAddressSpace: "local" dinyatakan saat pemanggilan fetch agar dapat dibedakan dengan jelas
  • Spesifikasi Fetch hanya mendefinisikan koneksi sederhana tanpa resolusi DNS, sehingga penilaian apakah suatu permintaan adalah permintaan jaringan lokal dilakukan pada koneksi baru
  • Permintaan jaringan lokal hanya diizinkan dalam konteks aman; jika izin belum diperoleh maka tampil prompt, dan jika izin diberikan maka permintaan diizinkan
  • Dengan menambahkan parameter targetAddressSpace pada opsi fetch(), pengembang dapat secara eksplisit menentukan ruang alamat tujuan
    • contoh) fetch("http://router.com/ping";, { targetAddressSpace: "local" })
  • Jika alamat yang benar-benar terhubung berbeda dari ruang yang ditentukan di opsi, permintaan gagal untuk mencegah bypass mixed content
• Kebijakan yang sama juga diterapkan pada HTML, WebRTC, ServiceWorker, dan lainnya
  • Menambahkan nilai ruang alamat pada dokumen HTML/worker untuk melacak ruang berbasis origin
  • Saat menambahkan kandidat pada ICE Agent di WebRTC, alamat lokal/loopback menggunakan prompt izin
  • Izin dihubungkan dengan Permissions API, sehingga situs dapat melakukan kueri atas status izin saat ini
  • Pada dasarnya akses jaringan lokal hanya dimungkinkan dari dokumen tingkat atas; bila perlu, izin dapat didelegasikan ke subframe melalui kebijakan delegasi Permissions Policy
• Masalah mixed content (HTTP/HTTPS):
  • Mencakup skenario seperti upaya akses jaringan lokal dari konteks tidak aman, pemuatan subresource berbasis HTTP, dan penerapan pemblokiran mixed content
  • Untuk IP privat literal, domain .local, dan permintaan dengan targetAddressSpace yang ditentukan, tahap upgrade dan pemblokiran mixed content dilewati, lalu pada koneksi lanjutan akan diblokir jika origin belum memiliki izin
• Contoh cara kerja
  • Jika terjadi akses jaringan lokal yang tidak terduga, pengguna dapat menolak izin sehingga permintaan tak sah diblokir
  • Dalam kasus halaman kontrol perangkat yang dioperasikan produsen, jika dipanggil dengan properti yang sesuai (misalnya targetAddressSpace="local"), maka dapat tetap berfungsi seperti sebelumnya jika pengguna menyetujuinya

Alternatif dan diskusi

• Pendekatan PNA:
  • PNA yang ada mengharuskan CORS preflight, tetapi ada kesulitan besar dalam penerapan dan distribusi nyata
  • Di beberapa bagian, diusulkan pendekatan yang mengizinkan prompt izin dan pengecualian mixed content
  • Ada keterbatasan praktis akibat masalah DNS, tidak didukungnya spesifikasi pada perangkat tertentu, dan sebagainya
• Memblokir semua permintaan jaringan lokal: sederhana, tetapi tidak realistis karena dikhawatirkan merusak kasus penggunaan dan meningkatkan biaya penghindaran
• Mempertahankan keadaan saat ini: seiring OS mulai mengelola izin jaringan lokal per aplikasi, kebutuhan pengelolaan di tingkat browser semakin ditekankan
• Alternatif mixed content:
  • Dibahas evaluasi keamanan metode koneksi seperti "hanya mengizinkan subresource jaringan lokal yang aman" serta beban implementasinya
  • Alternatif lain yang dibahas meliputi deklarasi ruang alamat melalui response header/meta tag, serta penambahan atribut pada elemen HTML

Poin tambahan

• Juga dibahas kemungkinan penambahan atribut ruang alamat pada HTML subresource (iframe, img, dan sebagainya)
• Hasil penelitian seperti isu transitivity, yaitu pemberian hak yang terlalu luas saat izin diberikan, turut dipertimbangkan
• Membatasi akses jaringan lokal saat navigasi main frame atau menampilkan interstitial peringatan
• Juga dipertimbangkan pendekatan yang secara luas menganggap semua permintaan cross-origin ke alamat lokal/loopback sebagai permintaan jaringan lokal
• Diteliti pula metode pemberian izin yang lebih terperinci per jaringan, serta perlunya persetujuan ulang saat berpindah ke jaringan lain (terhubung dari lokasi berbeda)

Pertimbangan keamanan dan privasi

• Ada kekhawatiran bahwa situs yang diberi izin dapat memperoleh hak yang diperluas untuk menelusuri dan mengakses seluruh perangkat di jaringan pengguna
• Saat menerima prompt, pengguna harus memahami niatnya dengan jelas, dan dibandingkan pendekatan berbasis preflight, ini memberikan kontrol yang lebih langsung
• Tanpa izin sebelumnya, tidak ada permintaan jaringan lokal yang diizinkan, sehingga perlindungan privasi diperkuat

[GN⁺]

Komentar Hacker News

• Saat pertama kali melihatnya, saya langsung menyukai fitur ini; gagasan bahwa situs web bisa mengirim permintaan HTTP ke IP lokal secara sembarangan (atau IP mana pun) terasa sebagai risiko yang benar-benar tidak masuk akal. Bahkan jika ini membuat sebagian aplikasi enterprise atau integrasi rusak, saya tidak terlalu peduli; perusahaan bisa mengaktifkan kembali fitur ini lewat alat manajemen, dan pengguna biasa bisa mengaturnya sendiri. Menurut saya, cukup tampilkan popup seperti, "Situs web ini mencoba mengendalikan perangkat lokal - izinkan/tolak".

  • Ada sudut pandang yang agak keliru di sini: perangkat di jaringan lokal sebenarnya dilindungi dari situs web sembarangan berkat CORS. Memang tidak sempurna, tetapi cukup efektif. Masalahnya, CORS hanya bergantung pada persetujuan dari server target. Server harus mengizinkan akses situs web tersebut lewat header tertentu. Usulan kali ini bertujuan memperketat itu: walaupun server dan situs web sama-sama ingin berkomunikasi, tetap harus ada persetujuan pengguna yang eksplisit. Dulu kita menganggap kesepakatan server-situs web saja sudah cukup, tetapi kasus-kasus terbaru seperti Facebook yang diam-diam mengakses aplikasi di ponsel telah merusak prinsip itu. Artinya, kini situs web dan server jaringan lokal bisa bekerja dengan cara yang bertentangan dengan kepentingan pengguna.

  • Soal pendapat "pengguna biasa tinggal pilih izinkan/tolak di popup", MacOS saat ini sudah meminta izin seperti ini per aplikasi, tetapi kebanyakan pengguna menekan 'Allow' tanpa banyak berpikir. Dugaan saya, kalau dibuat per situs pun kewaspadaan mereka tidak akan meningkat terlalu signifikan.

  • Saya tidak paham mengapa situs web perlu mengakses jaringan lokal. Ini hanya menciptakan model ancaman keamanan yang sepenuhnya baru. Saya juga ragu ada kasus yang benar-benar tidak punya solusi yang lebih baik.

• Saya berharap Apple, Microsoft, Google, dan lainnya juga mengambil pendekatan serupa untuk USB dan Bluetooth. Hampir setiap aplikasi yang saya pasang belakangan ini meminta izin akses Bluetooth, dan itu sangat mengganggu. Saya ingin ID perangkat Bluetooth yang boleh diakses aplikasi dicantumkan di manifest, lalu OS membatasi akses hanya ke perangkat tersebut. Misalnya, aplikasi Bose seharusnya hanya bisa melihat perangkat Bose. Saya pernah menolak aplikasi karena entah izin apa yang mereka minta. Akan bagus jika, seperti kamera atau GPS, ada pendaftaran ID perangkat dan prompt ke pengguna. Untuk Bose, misalnya, prefix bisa didaftarkan sebagai bose.xxx dan di manifest hanya meminta akses ke bose.*, lalu OS hanya mengizinkan aturan itu. Saya juga mengusulkan skema ID serupa untuk USB dan perangkat jaringan lokal. Saya ingin OS mencegah aplikasi melakukan pencarian bebas di jaringan, USB, dan Bluetooth.

  • Saya berharap suatu hari nanti Apple setidaknya memberi aplikasi opsi "izin palsu". Misalnya, saat aplikasi mengklaim benar-benar membutuhkan daftar kontak saya, sistem justru memberikan daftar acak yang tak bisa dibedakan dari yang asli. Hal serupa juga bisa diterapkan pada GPS. Saya juga pernah dengar WhatsApp tidak memungkinkan Anda memberi nama kontak jika Anda tidak membagikan daftar kontak.

  • Seperti integrasi aplikasi pihak ketiga di Github, saya lebih suka model pilihan yang terperinci seperti, "ABC ingin melihat repo saya. Repo mana yang ingin dibagikan?"

• Ada pendapat bahwa Internet Explorer dulu menyelesaikan masalah seperti ini dengan sistem zone. Untuk detailnya, lihat dokumentasi MS.

  • Ironisnya, Chrome di Windows juga sebagian memakai skema keamanan zone milik IE, tetapi hampir tidak ada dokumentasi resmi tentang itu.

  • Ketiadaan alternatif modern seperti ini terasa konyol. Akses jaringan lokal juga seharusnya hanya diizinkan sebagai permission khusus, seperti kamera dan mikrofon.

• Sulit dipercaya browser web sejak awal membiarkan perilaku seperti ini. Kalau situs web publik bisa diam-diam mengakses seluruh file system saya, itu jelas dianggap celah keamanan yang mengerikan; tetapi untuk layanan jaringan lokal, XHR bisa langsung dipakai begitu saja, dan keamanan diserahkan hanya pada konfigurasi server. Sebagai developer, saat Anda menjalankan web app internal di PC pengembangan sendiri untuk testing (dengan keamanan sangat longgar atau tidak ada sama sekali), facebook.com atau google.com bisa langsung mengaksesnya. Di rumah pun banyak orang menjalankan layanan tanpa autentikasi karena percaya pada firewall router; saya tidak yakin mereka semua sudah mengonfigurasi CORS dengan benar.

  • Saya sangat ragu semua orang benar-benar sudah mengatur CORS dengan benar; kenyataannya mungkin mendekati 0% yang melakukannya.

• Ada harapan usulan ini bisa membantu menghentikan trik berbasis localhost yang dipakai Meta untuk berbagi kode identifikasi antara aplikasi native dan situs web lewat SDK mereka, terutama di Android; lihat detail lebih lanjut.

• Memberi situs web permission umum untuk mengakses jaringan lokal adalah izin yang terlalu kasar dan terlalu luas. Kebanyakan situs yang benar-benar butuh permission ini sebenarnya hanya perlu mengakses satu server lokal saja. Mengizinkan semua akses lokal melanggar prinsip least privilege. Sebagian besar pengguna juga tidak tahu apa yang berjalan di localhost atau di jaringan mereka, jadi mereka tidak benar-benar memahami risikonya.

  • Karena kebanyakan orang tidak tahu ada apa di localhost atau jaringan mereka, jika browser menampilkan pesan seperti mengizinkan akses ke http://localhost:3146 atau http://localhost:8089, mereka bahkan tidak bisa menebak artinya. Menurut saya, pesan yang lebih intuitif seperti "Situs ini mencoba mengakses resource jaringan lokal" akan lebih baik daripada istilah teknis.

  • Jika ingin diimplementasikan dengan benar, ini pada dasarnya membutuhkan akses setingkat firewall di dalam browser. Akan bagus jika ada API yang bisa mengontrol secara rinci hal-hal seperti CIDR dan port. Saya juga berharap extension browser bisa memakai API firewall seperti ini, atau ada UI bawaan yang bisa membedakan secara jelas cakupan seperti mesin tertentu (misalnya router), LAN, VPN, atau private network di Windows, lalu meminta permission terpisah untuk masing-masing.

• Dulu, setelah plugin NPAPI menghilang, banyak situs web publik yang perlu terintegrasi dengan software lokal akhirnya tidak punya pilihan selain menjalankan server HTTP di localhost. Jika kegunaan ini juga dibuat rumit, dampaknya akan sangat tidak nyaman. Browser seharusnya sudah menyiapkan teknologi pengganti setelah era NPAPI, tetapi sekarang rasanya sudah terlambat.

  • Kebanyakan software lebih memilih mendaftarkan protocol handler di level OS, sehingga misalnya situs web mengirimkan tautan seperti zoommtg://, lalu browser meneruskannya ke Zoom atau aplikasi lain. Hal-hal seperti Jupyter Notebook yang dipakai lokal tanpa cross-origin request tidak akan terdampak, dan pengiriman ke URL localhost setelah login OAuth2 juga seharusnya aman karena itu hanya redirect biasa.

  • Jika cara seperti ini (komunikasi dengan aplikasi lokal lewat server HTTP) benar-benar hilang, saya malah menganggap itu lebih baik. Selama ini ia menjadi sumber berbagai celah keamanan.

  • Teknologi seperti Mozilla Native messaging sebenarnya sudah ada. Memang perlu memasang extension, tetapi dibanding NPAPI ini terasa lebih adil.

  • Jika software lokal bekerja dengan cara 'pull' (aplikasi secara berkala meminta ke luar), maka tidak perlu menjalankan server sama sekali, dan sebagai bonus situs web juga tidak akan bisa sembarangan memindai jaringan lokal orang lain.

• Di JavaScript, saat Anda mengirim fetch atau permintaan POST tanpa opsi cors, CORS hanya mencegah pembacaan respons; browser tetap mengirim permintaannya. Jika aplikasi lokal dibuat menambahkan header CORS dari server lewat proxy, situs mana pun bisa mengaksesnya dengan JS fetch/XMLHttpRequest. Extension juga bisa mengubah header untuk melewati CORS. Sangat mudah membuat bypass seperti ini hanya dengan mengutak-atik header, sedangkan CSP (Content Security Policy) sangat sulit atau nyaris mustahil dilewati. Aplikasi Facebook bahkan sekarang menjalankan server proxy cors mereka sendiri untuk struktur seperti ini. Ada juga WebSocket, jadi walaupun Chrome punya flag untuk memblokir akses localhost, itu tetap tidak banyak membantu. Memblokir localhost sepenuhnya justru akan lebih merugikan. Banyak pengguna memakai server lokal untuk self-hosted bookmark, catatan, password manager, dan sebagainya, jadi memblokir kasus seperti itu terasa tidak masuk akal.

• Ada kekhawatiran soal lingkungan IPv6. Saya penasaran apakah benar ada cara membedakan apakah sebuah alamat IPv6 itu sebagian bersifat lokal. Jika tidak, usulan ini tampaknya akan bermasalah di jaringan IPv6-only. Saya pernah mengalami persoalan seperti ini pada aplikasi IoT: sulit mengidentifikasi apakah alamat IPv6 itu lokal, jadi akhirnya saya mengalihkan semua IPv6 ke lokal IPv4. Bahkan IPv6 link-local pada praktiknya tidak terlalu berguna untuk aplikasi biasa. Mengakui domain .local sebagai server lokal juga rumit karena interpretasinya berbeda-beda di tiap OS, sehingga implementasinya tidak konsisten. Contoh: di Raspberry Pi OS, some_address di-resolve lewat mDNS tetapi someaddress.local tidak; di Ubuntu 24.04 justru someaddress.local yang bekerja, sedangkan someaddress tidak; someaddress.local. juga tidak berfungsi. Terakhir, saya juga frustrasi karena sertifikat private tidak bisa dipakai untuk alamat jaringan lokal, sehingga masalah "membatasi https pada alamat lokal" juga harus diselesaikan.

  • IPv6 tetap memiliki konsep 'routable', jadi secara logis status site-local bisa didefinisikan berdasarkan routing table. Dulu pada IPv4 lama ada struktur site di oktet kedua dan VLAN di oktet ketiga, sedangkan IPv6 punya lebih banyak opsi. Semua perangkat IPv6 memiliki alamat link-local (untuk VLAN lokal), dan .local adalah istilah terkait pemetaan nama-ke-alamat di Apple, DNS, dan sebagainya, bukan hal yang langsung berkaitan dengan alamat IP. Sertifikat https di jaringan lokal tetap dimungkinkan lewat verifikasi DNS-01 milik Let's Encrypt, CNAME, dan sejenisnya. Memang cukup merepotkan, tetapi ada cara gratis, dan alat seperti acme.sh juga layak direkomendasikan. Konsep IPv4, IPv6, DNS, mDNS, Bonjour, dan lainnya memang perlu dijelaskan lebih rapi. Saya jadi teringat masa ketika bahkan packet capture pun berbayar; sekarang kondisinya jauh lebih baik.

  • Saya ingin memperjelas pendapat bahwa tidak ada cara di endpoint untuk menentukan apakah sebuah alamat IPv6 itu "lokal". Itulah prinsip dasar IPv6 karena ia dirancang untuk routing global. Bahkan di artikel itu Google sempat membahas arti "local" lalu di tengah jalan mengubahnya menjadi definisi 'private', yang menunjukkan kebingungan. Membuat batas keamanan berbasis CIDR yang tidak standar lewat ekstensi HTTP adalah pendekatan yang absurd. Aplikasi seharusnya dirancang dengan model keamanan yang menganggap dirinya sebagai layanan publik. .local memang ada dalam spesifikasi mDNS, tetapi dalam praktiknya hampir selalu diabaikan.

• Saya sungguh berharap pendekatan seperti ini segera terwujud, terutama jika domain HTTPS tetap bisa mengakses situs lokal HTTP. Ada banyak use case menarik untuk smart home, media/entertainment, dan sebagainya.