Isolasi Situs untuk developer web

Mathias Bynens

Chrome 67 di desktop memiliki fitur baru bernama Isolasi Situs yang diaktifkan secara default. Artikel ini menjelaskan apa itu Isolasi Situs, alasan diperlukannya, dan alasan developer web harus mengetahuinya.

Apa itu Isolasi Situs?

Internet ditujukan untuk menonton video kucing dan mengelola dompet mata uang kripto, dan masih banyak lagi. Namun, Anda tidak ingin fluffycats.example memiliki akses ke koin kripto berharga Anda. Untungnya, situs biasanya tidak dapat mengakses data satu sama lain di dalam browser berkat Kebijakan Asal yang Sama. Namun, situs berbahaya dapat mencoba mengabaikan kebijakan ini untuk menyerang situs lain, dan terkadang, bug keamanan ditemukan di kode browser yang menerapkan Kebijakan Asal yang Sama. Tim Chrome bertujuan untuk memperbaiki bug tersebut secepat mungkin.

Isolasi Situs adalah fitur keamanan di Chrome yang menawarkan baris pertahanan tambahan agar serangan tersebut cenderung tidak berhasil. Smart Bidding memastikan bahwa halaman dari situs yang berbeda selalu dimasukkan ke dalam proses yang berbeda, masing-masing berjalan di sandbox yang membatasi tindakan yang boleh dilakukan proses tersebut. Tindakan ini juga memblokir proses agar tidak menerima jenis data sensitif tertentu dari situs lain. Akibatnya, dengan Isolasi Situs, situs berbahaya akan jauh lebih sulit menggunakan serangan sisi saluran spekulatif seperti Spectre untuk mencuri data dari situs lain. Setelah tim Chrome menyelesaikan penerapan tambahan, Isolasi Situs juga akan membantu meskipun halaman penyerang dapat melanggar beberapa aturan dalam prosesnya sendiri.

Isolasi situs secara efektif mempersulit situs yang tidak tepercaya untuk mengakses atau mencuri informasi dari akun Anda di situs lain. Layanan ini menawarkan perlindungan tambahan terhadap berbagai jenis bug keamanan, seperti serangan side-channel Meltdown dan Spectre baru-baru ini.

Untuk mengetahui detail selengkapnya tentang Isolasi Situs, lihat artikel kami di blog Keamanan Google.

Pemblokiran Bacaan Lintas Asal

Meskipun semua halaman lintas situs dimasukkan ke dalam proses terpisah, halaman masih dapat meminta beberapa subresource lintas situs secara sah, seperti gambar dan JavaScript. Halaman web berbahaya dapat menggunakan elemen <img> untuk memuat file JSON yang berisi data sensitif, seperti saldo bank Anda:

<img src="https://your-bank.example/balance.json" />
<!-- Note: the attacker refused to add an `alt` attribute, for extra evil points. -->

Tanpa Isolasi Situs, konten file JSON akan masuk ke memori proses perender, saat perender melihat bahwa ini bukan format gambar yang valid dan tidak merender gambar. Namun, penyerang dapat mengeksploitasi kerentanan seperti Spectre untuk berpotensi membaca potongan memori tersebut.

Selain menggunakan <img>, penyerang juga dapat menggunakan <script> untuk meng-commit data sensitif ke memori:

<script src="https://your-bank.example/balance.json"></script>

Cross-Origin Read Blocking, atau CORB, adalah fitur keamanan baru yang mencegah konten balance.json memasuki memori memori proses perender berdasarkan jenis MIME-nya.

Mari kita uraikan cara kerja CORB. Situs dapat meminta dua jenis resource dari server:

  1. resource data seperti dokumen HTML, XML, atau JSON
  2. resource media seperti gambar, JavaScript, CSS, atau font

Situs dapat menerima resource data dari originnya sendiri atau dari origin lain dengan header CORS permisif seperti Access-Control-Allow-Origin: *. Di sisi lain, resource media dapat disertakan dari origin mana pun, meskipun tanpa header CORS yang permisif.

CORB mencegah proses perender menerima resource data lintas origin (yaitu HTML, XML, atau JSON) jika:

  • resource memiliki header X-Content-Type-Options: nosniff
  • CORS tidak secara eksplisit mengizinkan akses ke resource

Jika resource data lintas origin belum menetapkan header X-Content-Type-Options: nosniff, CORB akan mencoba mengendus isi respons untuk menentukan apakah berupa HTML, XML, atau JSON. Hal ini diperlukan karena beberapa server web salah dikonfigurasi dan menampilkan gambar sebagai, misalnya text/html.

Resource data yang diblokir oleh kebijakan CORB ditampilkan ke proses sebagai kosong, meskipun permintaan masih terjadi di latar belakang. Akibatnya, halaman web berbahaya kesulitan menarik data lintas situs ke dalam prosesnya untuk mencurinya.

Untuk keamanan optimal dan mendapatkan manfaat dari CORB, sebaiknya lakukan hal berikut:

  • Tandai respons dengan header Content-Type yang benar. (Misalnya, resource HTML harus ditayangkan sebagai text/html, resource JSON dengan jenis MIME JSON, dan resource XML dengan jenis MIME XML).
  • Pilih untuk tidak melakukan sniffing menggunakan header X-Content-Type-Options: nosniff. Tanpa header ini, Chrome akan melakukan analisis konten cepat untuk mencoba mengonfirmasi bahwa jenisnya sudah benar. Namun, karena ini bukan berarti mengizinkan respons melalui untuk menghindari pemblokiran hal-hal seperti file JavaScript, sebaiknya Anda melakukan sendiri hal yang benar.

Untuk mengetahui detail selengkapnya, lihat artikel CORB untuk developer web atau penjelasan CORB mendalam kami.

Mengapa developer web harus peduli dengan Isolasi Situs?

Biasanya, Isolasi Situs adalah fitur browser di balik layar yang tidak langsung diekspos kepada developer web. Misalnya, tidak ada API eksposur web baru yang perlu dipelajari. Secara umum, halaman web seharusnya tidak dapat membedakannya saat dijalankan dengan atau tanpa Isolasi Situs.

Namun, ada beberapa pengecualian untuk aturan ini. Mengaktifkan Isolasi Situs disertai dengan beberapa efek samping halus yang dapat memengaruhi situs Anda. Kami menyimpan daftar masalah umum Isolasi Situs, dan menguraikan masalah yang paling penting di bawah ini.

Tata letak halaman penuh tidak lagi sinkron

Dengan Isolasi Situs, tata letak halaman penuh tidak lagi dijamin sinkron, karena frame halaman sekarang dapat tersebar di beberapa proses. Perubahan ini mungkin memengaruhi halaman jika halaman tersebut menganggap perubahan tata letak langsung disebarkan ke semua frame di halaman.

Sebagai contoh, mari kita perhatikan situs bernama fluffykittens.example yang berkomunikasi dengan widget sosial yang dihosting di social-widget.example:

<!-- https://fluffykittens.example/ -->
<iframe src="https://social-widget.example/" width="123"></iframe>
<script>
  const iframe = document.querySelector('iframe');
  iframe.width = 456;
  iframe.contentWindow.postMessage(
    // The message to send:
    'Meow!',
    // The target origin:
    'https://social-widget.example'
  );
</script>

Pada awalnya, lebar <iframe> widget sosial adalah 123 piksel. Namun, halaman FluffyKittens akan mengubah lebarnya menjadi 456 piksel (memicu tata letak) dan mengirim pesan ke widget sosial, yang memiliki kode berikut:

<!-- https://social-widget.example/ -->
<script>
  self.onmessage = () => {
    console.log(document.documentElement.clientWidth);
  };
</script>

Setiap kali widget sosial menerima pesan melalui postMessage API, widget tersebut akan mencatat lebar elemen <html> root-nya.

Nilai lebar mana yang dicatat? Sebelum Chrome mengaktifkan Isolasi Situs, jawabannya adalah 456. Mengakses document.documentElement.clientWidth akan memaksa tata letak, yang sebelumnya bersifat sinkron sebelum Chrome mengaktifkan Isolasi Situs. Namun, dengan mengaktifkan Isolasi Situs, tata letak ulang widget sosial lintas origin kini terjadi secara asinkron dalam proses terpisah. Dengan demikian, jawabannya sekarang juga bisa berupa 123, yaitu nilai width lama.

Jika halaman mengubah ukuran <iframe> lintas origin, lalu mengirimkan postMessage ke halaman tersebut, dengan Isolasi Situs, frame penerima mungkin belum mengetahui ukuran barunya saat menerima pesan. Secara umumnya, hal ini dapat merusak halaman jika halaman menganggap perubahan tata letak langsung disebarkan ke semua frame di halaman.

Dalam contoh khusus ini, solusi yang lebih andal akan menetapkan width di frame induk, dan mendeteksi perubahan tersebut di <iframe> dengan memproses peristiwa resize.

Pengendali penghapusan muatan mungkin lebih sering kehabisan waktu

Saat frame menavigasi atau menutup, dokumen lama serta dokumen subframe yang disematkan di dalamnya semuanya menjalankan pengendali unload. Jika navigasi baru terjadi dalam proses perender yang sama (misalnya, untuk navigasi asal yang sama), pengendali unload dokumen lama dan subframe-nya dapat berjalan untuk waktu yang lama sebelum mengizinkan navigasi baru dilakukan.

addEventListener('unload', () => {
  doSomethingThatMightTakeALongTime();
});

Dalam situasi ini, pengendali unload di semua frame sangat andal.

Namun, meskipun tanpa Isolasi Situs, beberapa navigasi frame utama bersifat lintas proses, yang memengaruhi perilaku pengendali penghapusan muatan. Misalnya, jika Anda menavigasi dari old.example ke new.example dengan mengetik URL di kolom URL, navigasi new.example akan terjadi dalam proses baru. Pengendali penghapusan muatan untuk old.example dan subframe-nya berjalan dalam proses old.example di latar belakang, setelah halaman new.example ditampilkan, dan pengendali penghapusan muatan lama dihentikan jika tidak selesai dalam waktu tunggu tertentu. Karena pengendali penghapusan muatan mungkin tidak selesai sebelum waktu tunggu habis, perilaku penghapusan muatan kurang dapat diandalkan.

Dengan Isolasi Situs, semua navigasi lintas situs menjadi lintas proses, sehingga dokumen dari situs yang berbeda tidak saling berbagi proses. Akibatnya, situasi di atas berlaku dalam lebih banyak kasus, dan pengendali penghapusan muatan di <iframe> sering kali memiliki perilaku latar belakang dan waktu tunggu seperti yang dijelaskan di atas.

Perbedaan lain yang dihasilkan dari Isolasi Situs adalah pengurutan paralel baru dari pengendali penghapusan muatan: tanpa Isolasi Situs, pengendali penghapusan muatan berjalan dalam urutan dari atas ke bawah yang ketat di seluruh frame. Namun, dengan Isolasi Situs, pengendali penghapusan muatan berjalan secara paralel di berbagai proses.

Ini adalah konsekuensi mendasar saat mengaktifkan Isolasi Situs. Tim Chrome sedang berupaya meningkatkan keandalan pengendali penghapusan muatan untuk kasus penggunaan umum, jika memungkinkan. Kami juga mengetahui bug saat pengendali penghapusan muatan subframe belum dapat menggunakan fitur tertentu dan sedang mencoba mengatasinya.

Kasus penting untuk pengendali penghapusan muatan adalah mengirim ping akhir sesi. Tindakan ini biasanya dilakukan sebagai berikut:

addEventListener('pagehide', () => {
  const image = new Image();
  img.src = '/end-of-session';
});

Pendekatan yang lebih baik dan lebih andal sehubungan dengan perubahan ini adalah dengan menggunakan navigator.sendBeacon sebagai gantinya:

addEventListener('pagehide', () => {
  navigator.sendBeacon('/end-of-session');
});

Jika memerlukan kontrol lebih besar atas permintaan, Anda dapat menggunakan opsi keepalive pada Fetch API:

addEventListener('pagehide', () => {
  fetch('/end-of-session', {keepalive: true});
});

Kesimpulan

Isolasi Situs mempersulit situs yang tidak tepercaya untuk mengakses atau mencuri informasi dari akun Anda di situs lain dengan mengisolasi setiap situs ke dalam prosesnya sendiri. Sebagai bagian dari hal tersebut, CORB mencoba untuk menjauhkan resource data sensitif dari proses perender. Rekomendasi kami di atas memastikan Anda mendapatkan manfaat maksimal dari fitur keamanan baru ini.

Terima kasih kepada Alex Moshchuk, Charlie Reis, Jason Miller, Nasko Oskov, Philip Walton, Shubhie Panicker, dan Thomas Steiner telah membaca versi draf artikel ini dan memberikan masukannya.