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:
- resource data seperti dokumen HTML, XML, atau JSON
- 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 sebagaitext/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.