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: Pembaruan pengumuman linimasa.
• 7 Maret 2022: Mengumumkan rollback setelah ada masalah di Chrome 98.

Pengantar

Chrome menghentikan akses langsung ke endpoint jaringan pribadi dari situs publik sebagai bagian dari spesifikasi Akses Jaringan Pribadi (PNA).

Chrome akan mulai mengirimkan permintaan preflight CORS sebelum permintaan jaringan pribadi untuk subresource, yang meminta izin eksplisit dari server target. Permintaan preflight ini akan membawa header baru, Access-Control-Request-Private-Network: true, dan responsnya harus membawa header yang sesuai, Access-Control-Allow-Private-Network: true.

Tujuannya adalah untuk melindungi pengguna dari serangan pemalsuan permintaan lintas situs (CSRF) yang menargetkan router dan perangkat lain di jaringan pribadi. Serangan ini telah memengaruhi ratusan ribu pengguna, sehingga penyerang dapat mengalihkannya ke server berbahaya.

Rencana peluncuran

Chrome akan meluncurkan perubahan ini dalam dua fase untuk memberi situs waktu guna mengetahui perubahan tersebut dan melakukan penyesuaian.

1. Di Chrome 104:

   • Chrome bereksperimen dengan mengirimkan permintaan preflight sebelum permintaan subresource jaringan pribadi.
   • Kegagalan preflight hanya menampilkan peringatan di DevTools, tanpa memengaruhi permintaan jaringan pribadi.
   • Chrome mengumpulkan data kompatibilitas dan menghubungi situs terbesar yang terpengaruh.
   • Kami berharap fitur ini kompatibel secara luas dengan situs yang sudah ada.
   Peringatan: Untuk membatasi efek pada situs yang belum mendukung preflight, waktu tunggu dibatasi hingga 200 milidetik di Chrome 104. Pembatasan hanya diterapkan dalam mode peringatan. Batas waktu tunggu khusus akan dihapus setelah mengaktifkan mode penerapan dengan mengalihkan "Menghormati hasil preflight Akses Jaringan Pribadi" ke "Diaktifkan" dalam chrome://flags dan batas default-nya adalah 5 detik.

2. Paling awal di Chrome 113:

   • Ini akan dimulai hanya jika dan ketika data kompatibilitas menunjukkan bahwa perubahan tersebut cukup aman dan kami telah menghubungi secara langsung bila diperlukan.
   • Chrome memberlakukan bahwa permintaan preflight harus berhasil, jika tidak, permintaan akan gagal.
   • Uji coba penghentian penggunaan dimulai secara bersamaan agar situs yang terpengaruh oleh fase ini dapat meminta perpanjangan waktu. Uji coba ini akan berlangsung setidaknya selama 6 bulan.

Catatan: Upaya sebelumnya telah dilakukan untuk meluncurkan peringatan di Chrome 98 dan Chrome 102, yang sebelumnya diumumkan dalam postingan blog ini. Ini di-roll back setelah ditemukan masalah stabilitas dan kompatibilitas selama peluncuran. Masalah yang teridentifikasi telah diperbaiki untuk Chrome 104.

Apa itu Akses Jaringan Pribadi (PNA)

Akses Jaringan Pribadi (sebelumnya dikenal sebagai CORS-RFC1918) membatasi kemampuan situs untuk mengirim permintaan ke server di jaringan pribadi.

Chrome telah menerapkan sebagian spesifikasi: mulai Chrome 96, hanya konteks aman yang diizinkan untuk membuat permintaan jaringan pribadi. Lihat postingan blog sebelumnya kami untuk mengetahui detailnya.

Spesifikasi ini juga memperluas protokol Cross-Origin Resource Sharing (CORS) sehingga situs kini harus secara eksplisit meminta pemberian dari server di jaringan pribadi sebelum diizinkan untuk mengirim permintaan arbitrer.

Istilah penting: Permintaan jaringan pribadi adalah permintaan yang alamat IP server targetnya lebih pribadi daripada permintaan yang digunakan inisiator permintaan tersebut. Misalnya, permintaan dari situs publik (https://example.com) ke situs pribadi (http://router.local), atau permintaan dari situs pribadi ke localhost.

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 alamat loopback IPv4 (127.0.0.0/8) yang didefinisikan dalam bagian 3.2.1.3 dari alamat loopback RFC1122 atau IPv6 (::1/128) yang ditentukan dalam bagian 2.5.3 pada 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 yang didefinisikan dalam RFC1918, alamat link-local 169.254.0.0/16 yang didefinisikan dalam RFC3927, alamat unicast IPv6 lokal unik fc00::/7 yang ditentukan di RFC4193, link-local-local address fe80::/10 dipetakan di bagian link-local6 unicast fe80::/10.RFC4291

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.

Hubungan antara jaringan publik, pribadi, dan lokal dalam Akses Jaringan Pribadi (CORS-RFC1918)

Pelajari lebih lanjut di bagian Masukan yang diinginkan: 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 target sebelum mengirimkan permintaan HTTP yang mungkin memiliki efek samping. Hal ini memastikan bahwa server target memahami protokol CORS dan secara signifikan mengurangi risiko serangan CSRF.

Permintaan izin dikirim sebagai permintaan HTTP OPTIONS dengan header permintaan CORS spesifik yang menjelaskan permintaan HTTP mendatang. Respons harus membawa header respons CORS spesifik yang secara eksplisit menyetujui permintaan mendatang.

Yang baru di Akses Jaringan Pribadi

Sepasang header permintaan dan respons baru diperkenalkan ke permintaan preflight:

• Access-Control-Request-Private-Network: true ditetapkan pada 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 dan mode permintaan. Metode ini dikirim sebelum permintaan dalam mode cors, serta no-cors dan semua mode lainnya. Hal ini karena semua permintaan jaringan pribadi dapat digunakan untuk serangan CSRF, terlepas dari mode permintaan dan apakah konten respons tersedia untuk inisiator atau tidak.

Catatan: Jika permintaan jaringan pribadi dibuat dalam mode cors, header CORS harus ditetapkan pada respons akhir, selain respons preflight.

Permintaan preflight untuk PNA juga dikirim untuk permintaan origin yang sama, jika alamat IP target lebih pribadi daripada inisiator. Hal ini tidak seperti CORS reguler, dengan permintaan preflight hanya untuk permintaan lintas origin. Permintaan preflight untuk permintaan origin yang sama melindungi dari serangan rebinding DNS.

Contoh

Perilaku yang dapat diobservasi bergantung pada mode permintaan.

Mode tanpa CORS

Misalnya, https://foo.example/index.html menyematkan <img src="https://bar.example/cat.gif" alt="dancing cat"/>, dan bar.example di-resolve menjadi 192.168.1.1, alamat IP pribadi sesuai dengan 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

Peringatan: Server dapat menyetel Access-Control-Allow-Origin: *, meskipun hal ini berbahaya dan tidak disarankan. Resource jaringan pribadi seharusnya jarang dapat diakses oleh semua origin, jadi pertimbangkan dengan cermat risiko yang ada dalam menetapkan header tersebut.

Kemudian, Chrome akan mengirim permintaan yang sebenarnya:

HTTP/1.1 GET /cat.gif
...

Yang dapat dilakukan server 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 me-resolve ke 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 mengirim permintaan yang sebenarnya:

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

Yang dapat direspons oleh 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, permintaan preflight akan dikirim terlebih dahulu. Jika permintaan preflight ini gagal, permintaan terakhir akan tetap dikirim, tetapi peringatan akan muncul di panel masalah DevTools.

Permintaan preflight yang terpengaruh juga dapat dilihat dan didiagnosis di panel jaringan:

Jika permintaan Anda memicu preflight CORS reguler tanpa aturan Akses Jaringan Pribadi, dua preflight dapat muncul di panel jaringan, dengan preflight pertama selalu tampak gagal. Ini adalah bug yang diketahui, dan Anda dapat mengabaikannya dengan aman.

Untuk meninjau hal 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 menyebabkan pengambilan yang gagal. Hal ini memungkinkan Anda menguji apakah situs Anda akan berfungsi setelah fase kedua dari rencana peluncuran kami. Error dapat didiagnosis dengan cara yang sama seperti peringatan menggunakan panel DevTools yang disebutkan di atas.

Tindakan yang harus dilakukan jika situs Anda terpengaruh

Saat diluncurkan di Chrome 104, perubahan ini tidak akan merusak situs apa pun. Namun, sebaiknya perbarui jalur permintaan yang terpengaruh untuk memastikan situs 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

Update server target dari pengambilan yang terpengaruh untuk menangani permintaan preflight PNA. Pertama, implementasikan dukungan untuk permintaan preflight CORS standar pada rute yang terpengaruh. Kemudian, tambahkan dukungan untuk dua header respons baru.

Saat server Anda menerima permintaan preflight (permintaan OPTIONS dengan header CORS), server harus memeriksa keberadaan header Access-Control-Request-Private-Network: true. Jika header ini ada pada permintaan, server harus memeriksa header Origin dan jalur permintaan beserta informasi relevan lainnya (seperti Access-Control-Request-Headers) untuk memastikan permintaan aman untuk diizinkan. Biasanya, Anda harus mengizinkan akses ke satu origin di bawah kendali Anda.

Peringatan: Waspadai origin yang tidak aman (non-https), karena tidak diautentikasi. Penyerang di jalur dapat menyamar sebagai asal yang seperti itu.

Setelah memutuskan untuk mengizinkan permintaan, server Anda harus merespons 204 No Content (atau 200 OK) dengan header CORS yang diperlukan dan header PNA baru. Header ini mencakup Access-Control-Allow-Origin dan Access-Control-Allow-Private-Network: true, serta elemen lainnya yang diperlukan.

Lihat contoh untuk skenario konkret.

Nonaktifkan pemeriksaan Akses Jaringan Pribadi menggunakan kebijakan perusahaan

Jika memiliki kontrol administratif atas pengguna, Anda dapat menonaktifkan pemeriksaan Akses Jaringan Pribadi menggunakan salah satu kebijakan berikut:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Untuk mengetahui informasi selengkapnya, baca Memahami pengelolaan kebijakan Chrome.

Berikan masukan Anda

Jika Anda menghosting situs dalam jaringan pribadi yang mengharapkan permintaan dari jaringan publik, tim Chrome ingin mendengar masukan dan kasus penggunaan Anda. Beri tahu kami dengan mengajukan masalah pada Chromium di crbug.com dan setel komponen ke Blink>SecurityFeature>CORS>PrivateNetworkAccess.

Langkah selanjutnya

Selanjutnya, Chrome akan memperluas pemeriksaan Akses Jaringan Pribadi untuk mencakup pekerja web: pekerja khusus, pekerja bersama, dan pekerja layanan. Untuk sementara, kami menargetkan Chrome 107 untuk 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 untuk mulai menampilkan peringatan.

Dalam kedua kasus tersebut, kami akan melanjutkan dengan peluncuran bertahap yang serupa dengan hati-hati, agar developer web memiliki waktu untuk menyesuaikan dan memperkirakan risiko kompatibilitas.

Ucapan terima kasih

Foto sampul oleh Mark Olsen di Unsplash.