Halaman ini diterjemahkan oleh Cloud Translation API.

Isolasi Situs untuk developer web

Mathias Bynens

Chrome 67 di desktop memiliki fitur baru bernama Isolasi Situs yang diaktifkan secara default. Ini yang menjelaskan apa itu Isolasi Situs, mengapa hal ini diperlukan, dan mengapa developer web harus mewaspadainya.

Apa itu Isolasi Situs?

Internet digunakan untuk menonton video kucing dan mengelola dompet mata uang kripto, serta banyak hal lainnya — tetapi Anda tidak ingin fluffycats.example memiliki akses ke kriptokoin Anda yang berharga. Untungnya, situs web biasanya tidak dapat mengakses data satu sama lain di dalam browser berkat Kebijakan. Namun, situs web berbahaya mungkin mencoba mengakali kebijakan ini untuk menyerang situs web lain, dan terkadang, bug keamanan ditemukan di kode browser yang menerapkan Kebijakan Asal yang Sama. Tujuan Tim Chrome bertujuan untuk memperbaiki bug tersebut secepat mungkin.

Isolasi Situs adalah fitur keamanan di Chrome yang menawarkan lini pertahanan tambahan untuk serangan semacam itu cenderung tidak berhasil. Cara ini memastikan bahwa laman dari situs web yang berbeda selalu ditempatkan ke dalam proses yang berbeda, masing-masing berjalan dalam {i>sandbox<i} yang membatasi apa yang boleh dilakukan oleh proses tersebut. Tindakan ini juga memblokir proses agar tidak menerima jenis data sensitif tertentu dari situs lain. Sebagai seorang situs web berbahaya, dengan Isolasi Situs, akan jauh lebih sulit bagi situs web berbahaya untuk menggunakan serangan {i>side-channel<i} seperti Spectre untuk mencuri data dari situs lain. Saat tim Chrome selesai penegakan tambahan, Isolasi Situs juga akan membantu meskipun halaman penyerang dapat aturan dalam prosesnya sendiri.

Isolasi Situs secara efektif mempersulit situs yang tidak tepercaya untuk mengakses atau mencuri informasi dari akun Anda di situs lain. {i>Firewall<i} ini menawarkan perlindungan tambahan terhadap berbagai jenis {i>bug<i} keamanan, seperti serangan channel samping Meltdown dan Spectre baru-baru ini.

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

Pemblokiran Baca Lintas Asal

Meskipun semua halaman lintas situs dimasukkan ke dalam proses terpisah, halaman masih dapat meminta secara sah beberapa subresource lintas situs, seperti gambar dan JavaScript. Laman web berbahaya dapat menggunakan <img> untuk memuat file JSON dengan 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 sampai ke memori perender proses, saat perender melihat bahwa itu bukan format gambar yang valid dan tidak dirender gambar. Tapi, penyerang kemudian dapat mengeksploitasi kerentanan seperti Spectre untuk membaca bagian memori.

Sebagai ganti 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 agar tidak memasukkan memori proses perender berdasarkan jenis MIME-nya.

Mari kita uraikan cara kerja CORB. Situs web dapat meminta dua jenis sumber daya dari server:

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

Situs dapat menerima resource data dari asalnya sendiri atau dari origin lain dengan header CORS permisif seperti Access-Control-Allow-Origin: *. Di sisi lain, resource media dapat disertakan dari origin, 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 asal belum menetapkan header X-Content-Type-Options: nosniff, CORB mencoba mengendus isi respons untuk menentukan apakah itu HTML, XML, atau JSON. Ini adalah diperlukan karena beberapa server web salah dikonfigurasi dan menyajikan gambar sebagai text/html, misalnya.

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

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

Tandai respons dengan header Content-Type yang benar. (Misalnya, sumber daya HTML harus berfungsi sebagai text/html, resource JSON dengan jenis MIME JSON dan resource XML dengan jenis MIME XML).
Pilih untuk tidak mengendus dengan menggunakan header X-Content-Type-Options: nosniff. Tanpa {i>header<i} ini, Chrome melakukan analisis konten cepat untuk mencoba mengkonfirmasi bahwa jenisnya sudah benar, tetapi karena tidak mengizinkan respons untuk menghindari pemblokiran hal-hal seperti sebaiknya Anda tegaskan sendiri bahwa Anda melakukan hal yang benar.

Untuk detail selengkapnya, lihat Artikel CORB untuk developer web atau penjelasan CORB yang mendalam.

Mengapa developer web harus memperhatikan Isolasi Situs?

Untuk sebagian besar, Isolasi Situs adalah fitur browser di balik layar yang tidak secara langsung diperkenalkan kepada pengembang web. Misalnya, tidak ada API baru yang terekspos web untuk dipelajari. Secara umum, web halaman tidak dapat membedakan saat dijalankan dengan atau tanpa Isolasi Situs.

Namun, ada beberapa pengecualian untuk aturan ini. Mengaktifkan Isolasi Situs memberikan beberapa yang mungkin memengaruhi situs web Anda. Kami mempertahankan daftar masalah Isolasi Situs yang diketahui, dan kami menguraikan yang paling penting di bawah ini.

Tata letak halaman penuh tidak lagi sinkron

Dengan Isolasi Situs, tata letak laman penuh tidak lagi dijamin akan sinkron, karena bingkai sebuah laman sekarang dapat tersebar di beberapa proses. Hal ini dapat memengaruhi laman jika mereka menganggap bahwa perubahan tata letak segera disebarkan ke semua {i>frame<i} pada laman.

Sebagai contoh, mari kita pertimbangkan 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. Tapi kemudian, laman FluffyKittens mengubah lebar menjadi 456 piksel (tata letak pemicu) 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 memaksa tata letak, yang sebelumnya sinkron sebelum Chrome mengaktifkan Isolasi Situs. Namun, dengan Isolasi Situs diaktifkan, widget sosial lintas asal tata letak ulang sekarang terjadi secara asinkron dalam proses terpisah. Dengan demikian, jawabannya sekarang juga 123, yaitu nilai width lama.

Jika halaman mengubah ukuran <iframe> lintas origin lalu mengirim postMessage ke sana, dengan Isolasi Situs ketika bingkai penerima mungkin belum mengetahui ukuran barunya saat menerima pesan. Selengkapnya umumnya, hal ini bisa merusak laman jika mereka menganggap perubahan tata letak langsung disebarkan ke semua {i>frame <i}pada laman.

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

Catatan: Secara umum, hindari membuat asumsi implisit tentang perilaku tata letak browser. Halaman penuh yang melibatkan <iframe> lintas origin tidak pernah secara eksplisit ditentukan sebagai sinkron, sehingga sebaiknya jangan menulis kode yang mengandalkannya.

Pengendali penghapusan muatan mungkin lebih sering kehabisan waktu

Saat sebuah {i>frame<i} dinavigasi atau ditutup, dokumen lama serta dokumen sub-bingkai apa pun yang disematkan di dalamnya semuanya menjalankan pengendali unload mereka. Jika navigasi baru terjadi dalam proses perender yang sama (mis. untuk navigasi asal yang sama), pengendali unload dari dokumen lama dan subframenya dapat berjalan untuk waktu yang lama sebelum mengizinkan navigasi baru untuk melakukan commit.

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

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

Namun, bahkan tanpa Isolasi Situs, beberapa navigasi frame utama merupakan proses silang, yang berdampak perilaku pengendali penghapusan muatan. Misalnya, jika Anda menavigasi dari old.example ke new.example dengan mengetik URL di kolom URL, navigasi new.example terjadi dalam proses baru. Penghapusan muatan untuk old.example dan subframenya berjalan dalam proses old.example di latar belakang, setelah halaman new.example ditampilkan, dan pengendali penghapusan muatan yang lama dihentikan jika tidak selesai dalam waktu tunggu tertentu. Karena pengendali penghapus muatan mungkin tidak selesai sebelum waktu tunggu, perilaku penghapusan muatan kurang dapat diandalkan.

Catatan: Saat ini, dukungan DevTools untuk pengendali penghapusan muatan sebagian besar tidak ada. Misalnya, titik henti sementara di dalam pengendali penghapusan muatan tidak berfungsi, permintaan apa pun yang dibuat selama pengendali penghapusan muatan tidak muncul di Panel jaringan, semua panggilan console.log yang dilakukan selama pengendali penghapusan muatan mungkin tidak muncul, dll. Bintang Masalah Chromium #851882 untuk terima info terbaru.

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

Perbedaan lain yang dihasilkan dari Isolasi Situs adalah pengurutan paralel baru untuk pengendali penghapusan muatan: tanpa Isolasi Situs, pengendali penghapusan muatan berjalan dalam urutan top-down yang ketat di seluruh frame. Namun dengan Site Pengendali isolasi, penghapusan muatan berjalan secara paralel di berbagai proses.

Hal ini adalah konsekuensi mendasar dalam mengaktifkan Isolasi Situs. Tim Chrome sedang mengerjakan meningkatkan keandalan pengendali penghapusan muatan untuk kasus penggunaan umum, jika memungkinkan. Kami juga mengetahui bug di mana pengendali penghapusan muatan subframe belum dapat memanfaatkan fitur tertentu dan yang berupaya menyelesaikannya.

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

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

Catatan: Kami menyarankan untuk gunakan peristiwa pagehide selama beforeunload atau unload, untuk alasan yang tidak terkait dengan Isolasi Situs.

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

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

Jika memerlukan kontrol lebih besar atas permintaan, Anda dapat menggunakan opsi keepalive 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 web lain dengan mengisolasi setiap situs ke dalam prosesnya sendiri. Sebagai bagian dari upaya ini, CORB mencoba untuk menjaga sumber daya data sensitif dari proses perender. Rekomendasi kami di atas memastikan Anda mendapatkan manfaat maksimal dari fitur keamanan baru ini.

Berkat Alex Moshchuk Charlie Reis Jason Miller, Nasko Oskov Philip Walton Shubhie Panicker, dan Thomas Steiner untuk membaca versi draf artikel ini dan memberikan masukan.