Mendapatkan keamanan dan privasi dengan mempartisi cache

Eiji Kitamura
Eiji Kitamura

Secara umum, caching dapat meningkatkan performa dengan menyimpan data sehingga permintaan mendatang untuk data yang sama akan ditayangkan lebih cepat. Misalnya, resource yang di-cache dari jaringan dapat menghindari perjalanan dua arah ke server. Hasil komputasi yang di-cache dapat menghilangkan waktu untuk melakukan penghitungan yang sama.

Di Chrome, mekanisme cache digunakan dalam berbagai cara dan Cache HTTP adalah salah satu contohnya.

Cara kerja Cache HTTP Chrome saat ini

Mulai versi 85, Chrome meng-cache resource yang diambil dari jaringan, menggunakan URL resource masing-masing sebagai kunci cache. (Kunci cache digunakan untuk mengidentifikasi resource yang di-cache.)

Contoh berikut mengilustrasikan cara satu gambar di-cache dan diperlakukan dalam tiga konteks yang berbeda:

Kunci Cache: https://x.example/doge.png
Kunci Cache: { https://x.example/doge.png }

Pengguna mengunjungi halaman (https://a.example) yang meminta image (https://x.example/doge.png). Gambar diminta dari jaringan dan di-cache menggunakan https://x.example/doge.png sebagai kuncinya.

Kunci Cache: https://x.example/doge.png
Kunci Cache: { https://x.example/doge.png }

Pengguna yang sama mengunjungi halaman lain (https://b.example), yang meminta gambar yang sama (https://x.example/doge.png). Browser akan memeriksa Cache HTTP-nya untuk melihat apakah resource ini telah di-cache, menggunakan URL gambar sebagai kuncinya. Browser menemukan kecocokan dalam Cache-nya, sehingga menggunakan versi resource yang di-cache.

Kunci Cache: https://x.example/doge.png
Kunci Cache: { https://x.example/doge.png }

Tidak masalah jika gambar dimuat dari dalam iframe. Jika pengguna mengunjungi situs lain (https://c.example) dengan iframe (https://d.example) dan iframe meminta gambar yang sama (https://x.example/doge.png), browser tetap dapat memuat gambar dari cache-nya karena kunci cache sama di semua halaman.

Mekanisme ini telah bekerja dengan baik dari perspektif performa untuk waktu yang lama. Namun, waktu yang diperlukan situs untuk merespons permintaan HTTP dapat mengungkapkan bahwa browser telah mengakses resource yang sama sebelumnya, sehingga membuat browser rentan terhadap serangan keamanan dan privasi, seperti berikut ini:

  • Mendeteksi apakah pengguna telah mengunjungi situs tertentu: Lawan dapat mendeteksi histori penjelajahan pengguna dengan memeriksa apakah cache memiliki resource yang mungkin khusus untuk situs atau kelompok situs tertentu.
  • Serangan penelusuran lintas situs: Serangan penelusuran lintas situs dapat mendeteksi apakah string arbitrer ada di hasil penelusuran pengguna dengan memeriksa apakah gambar 'tidak ada hasil penelusuran' yang digunakan oleh situs tertentu berada di cache browser atau tidak.
  • Pelacakan lintas situs: Cache dapat digunakan untuk menyimpan ID yang mirip cookie sebagai mekanisme pelacakan lintas situs.

Untuk mengurangi risiko ini, Chrome akan mempartisi cache HTTP-nya mulai Chrome 86.

Bagaimana partisi cache akan memengaruhi Cache HTTP Chrome?

Dengan partisi cache, resource yang di-cache akan dikunci menggunakan "Kunci Isolasi Jaringan" yang baru selain URL resource. Kunci Isolasi Jaringan terdiri dari situs tingkat atas dan situs saat ini.

Lihat kembali contoh sebelumnya untuk melihat cara kerja partisi cache dalam konteks yang berbeda:

Kunci Cache { https://a.example, https://a.example, https://x.example/doge.png}
Kunci Cache: { https://a.example, https://a.example, https://x.example/doge.png }

Pengguna mengunjungi halaman (https://a.example) yang meminta gambar (https://x.example/doge.png). Dalam hal ini, gambar diminta dari jaringan dan di-cache menggunakan tuple yang terdiri dari https://a.example (situs tingkat atas), https://a.example (situs saat ini frame), dan https://x.example/doge.png (URL resource) sebagai kuncinya. (Perhatikan bahwa jika permintaan resource berasal dari frame tingkat atas, situs tingkat atas dan situs frame saat ini di Kunci Isolasi Jaringan akan menjadi sama.)

Kunci Cache { https://a.example, https://a.example, https://x.example/doge.png}
Kunci Cache: { https://b.example, https://b.example, https://x.example/doge.png }

Pengguna yang sama mengunjungi halaman berbeda (https://b.example) yang meminta gambar yang sama (https://x.example/doge.png). Meskipun gambar yang sama dimuat dalam contoh sebelumnya, karena kunci tidak cocok, cache tidak akan ditemukan.

Image diminta dari jaringan dan di-cache menggunakan tuple yang terdiri dari https://b.example, https://b.example, dan https://x.example/doge.png sebagai kuncinya.

Kunci Cache { https://a.example, https://a.example, https://x.example/doge.png}
Kunci Cache: { https://a.example, https://a.example, https://x.example/doge.png }

Sekarang pengguna kembali ke https://a.example, tetapi kali ini gambar (https://x.example/doge.png) disematkan dalam iframe. Dalam hal ini, kunci adalah tuple yang berisi https://a.example, https://a.example, dan https://x.example/doge.png, lalu terjadi cache ditemukan. (Perhatikan bahwa jika situs tingkat atas dan iframe adalah situs yang sama, resource yang di-cache dengan frame tingkat atas dapat digunakan.

Kunci Cache { https://a.example, https://a.example, https://x.example/doge.png}
Kunci Cache: { https://a.example, https://c.example, https://x.example/doge.png }

Pengguna kembali ke https://a.example, tetapi kali ini gambar dihosting di iframe dari https://c.example.

Dalam hal ini, gambar didownload dari jaringan karena tidak ada resource dalam cache yang cocok dengan kunci yang terdiri dari https://a.example, https://c.example, dan https://x.example/doge.png.

Kunci Cache { https://a.example, https://a.example, https://x.example/doge.png}
Kunci Cache: { https://a.example, https://c.example, https://x.example/doge.png }

Bagaimana jika domain berisi subdomain atau nomor port? Pengguna membuka https://subdomain.a.example, yang menyematkan iframe (https://c.example:8080), yang meminta gambar.

Karena kunci dibuat berdasarkan "skema://eTLD+1", subdomain dan nomor port akan diabaikan. Oleh karena itu, cache ditemukan.

Kunci Cache { https://a.example, https://a.example, https://x.example/doge.png}
Kunci Cache: { https://a.example, https://c.example, https://x.example/doge.png }

Bagaimana jika iframe disarangkan beberapa kali? Pengguna mengunjungi https://a.example, yang menyematkan iframe (https://b.example), yang masih menyematkan iframe lain (https://c.example), yang akhirnya meminta gambar tersebut.

Karena kunci diambil dari frame teratas (https://a.example) dan frame langsung yang memuat resource (https://c.example), cache ditemukan terjadi.

FAQ

Apakah sudah diaktifkan di Chrome? Bagaimana cara memeriksanya?

Fitur ini diluncurkan hingga akhir tahun 2020. Untuk memeriksa apakah instance Chrome Anda sudah mendukungnya:

  1. Buka chrome://net-export/, lalu tekan Start Logging to Disk.
  2. Tentukan lokasi penyimpanan file log di komputer.
  3. Jelajahi web di Chrome selama satu menit.
  4. Kembali ke chrome://net-export/, lalu tekan Stop Logging.
  5. Buka https://netlog-viewer.appspot.com/#import
  6. Tekan Choose File dan teruskan file log yang disimpan.

Anda akan melihat output file log.

Pada halaman yang sama, temukan SplitCacheByNetworkIsolationKey. Jika diikuti dengan Experiment_[****], partisi Cache HTTP akan diaktifkan di Chrome. Jika diikuti dengan Control_[****] atau Default_[****], tindakan ini tidak akan diaktifkan.

Bagaimana cara menguji partisi Cache HTTP di Chrome?

Untuk menguji partisi Cache HTTP di Chrome, Anda harus meluncurkan Chrome dengan tanda command line: --enable-features=SplitCacheByNetworkIsolationKey. Ikuti petunjuk dalam artikel Menjalankan Chromium dengan tanda untuk mempelajari cara meluncurkan Chrome dengan tanda command line di platform Anda.

Sebagai developer web, apakah ada tindakan yang harus saya lakukan untuk menanggapi perubahan ini?

Perubahan ini tidak dapat menyebabkan gangguan, tetapi dapat menerapkan pertimbangan performa untuk beberapa layanan web.

Misalnya, situs yang menyalurkan resource dalam jumlah besar dan sangat mudah di-cache di banyak situs (seperti font dan skrip populer) mungkin mengalami peningkatan traffic. Selain itu, pengguna yang menggunakan layanan tersebut mungkin lebih bergantung pada layanan tersebut.

(Ada proposal untuk mengaktifkan library bersama dengan cara yang menjaga privasi yang disebut Pustaka Bersama Web (video presentasi), tetapi masih dipertimbangkan.)

Apa dampak dari perubahan perilaku ini?

Rasio kehilangan cache secara keseluruhan meningkat sekitar 3,6%, perubahan pada FCP (First Contentful Paint) cukup rendah (~0,3%), dan fraksi keseluruhan byte yang dimuat dari jaringan meningkat sekitar 4%. Anda dapat mempelajari dampaknya terhadap performa lebih lanjut di penjelasan partisi cache HTTP.

Apakah ini terstandardisasi? Apakah browser lain berperilaku berbeda?

"Partisi cache HTTP" distandarkan dalam spesifikasi pengambilan meskipun browser berperilaku berbeda:

Bagaimana perlakuan pengambilan dari pekerja?

Pekerja khusus menggunakan kunci yang sama dengan frame mereka saat ini. Pekerja layanan dan pekerja bersama lebih rumit karena dapat dibagikan di antara beberapa situs tingkat atas. Solusi untuk mereka saat ini sedang dalam diskusi.

Referensi