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 sebagaitext/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
.
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.
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';
});
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.